當我們談重構的時候我們想談什麼？

鄭昀 20180411

如果你在繁忙的業務迭代中開始系統重構，恭喜你，說明你的業務已經完成了從0到1，正在從1走向10，或者從10走向100。

至於重構後的技術棧是 Spring MVC+Dubbo，還是 Spring Boot+Spring Cloud？

是 Vue+ElementUI，是 React，還是 Ant.design，抑或就是上古時代的 JQuery+Bootstrap？

是 k8s，還是 mesos+marathon？是 Thrift，還是 Hessian，抑或 Protobuf？我並不在意。

我並不 care 這些東西，每個技術團隊都可以有自己的技術選型思路。

我在意的是兩個「是否有利於」：

一，是否有利於發布部署。

二，是否有利於排除故障（是否有利於快速定位線上問題和解決問題）。

為什麼要強調它倆？

因為我們在過去六七年間，經歷了太多的生死折磨。如履薄冰如臨深淵。

我們曾是做本地生活服務電商的，餐飲/電影/酒店/景點門票/美容美髮……

節假日往往也是本地生活服務的峰值日，飯點兒就相當於秒殺。

太多次在假期被召回。

太多次打電話給各個 TeamLeader，有時電腦不在身邊，有時深山老林無法上網，有時無人接聽，有時 VPN 連不進去～

多少次翹首期盼 DBA、SA、QA、DevManager 們給我回報到底出啥事兒了。

請先閱讀一下我寫的《經歷不可抗力是一種什麼體驗》，了解一下什麼是 too young too naive。

以至於我有兩個怨念：

怨念一，Centreon 爛到渣，Zabbix 也不咋的，基礎運維的那些神兵利器，都不考慮做業務的人，尤其是業務集群規模龐大的人，到底是怎麼排查問題排除故障的。

SA 是怎麼工作的？

一旦出現連接數暴漲，Web/App 服務長時間無響應，應用內存飆升，SA 拍馬趕到，一定是先重啟相關應用（不管是容器還是虛擬機），如果還不管用，就立即將相關應用悉數回滾到上一個穩定版本上，爭取以最短時間恢復。

等研發介入時，現場已經不復存在。

六七年前，事發後，我們登入 Centreon 和 ELK，按機器組、按機器、按指標，用肉眼，用大腦，結合各個業務集群里的日誌，結合 Nagios 報警簡訊，理出來一個因果證據鏈。

你可能需要打開幾百個監控頁面，你還需要精通業務集群的分組、調用關係和IP（那時候還沒有 Docker 容器，都是虛擬機）。

這也就是為什麼我定下我司研發哲學第一條：Dont make me think……

怨念二，開源軟體的開發者是好人也往往是性情中人，不太考慮排除故障成本低、可視化、高可用、可伸縮、監控報警等商業系統必備的運維屬性，拿來主義必死無葬身之地。

舉個例子吧，ActiveMQ 和 RabbitMQ 有生產者流量控制，如果你沒有聽說過，沒有遇到過，恭喜你，但也表明你的業務量還是太小。

你可能會說，遇到了生產者流量控制，說明下游消費者消費得太慢，加快速度不就完了？

在電商服務中，非同步消息隊列的消費者往往是與第三方系統網路通訊，第三方系統可就不在你控制範圍之內了，一個第三方系統掛了，或者突然擁塞，就會憋住你的消費者集群的所有線程，造成消息積壓。因此就將上游生產者掛起？開玩笑呢吧？！咋想的這都是？讓災難從下游蔓延到上游？！

那麼我們應該怎麼思考系統重構呢？

隨著業務規模越來越大，隨著應用越來越多，隨著 Docker 容器集群的引入，隨著前後端分離導致內部介面越來越多，隨著 API 網關的引入，我們越來越難以在5分鐘之內斷定系統出了什麼事兒。

因此，我要求：

戒律一：凡是中間件，不管是自主研發的，還是以開源軟體為內核構建出來的，都必須自帶監控報警，否則不允許上線。

戒律二：本著 Dont make me think 的哲學思路，所有對排除故障有幫助的信息，都必須一站式展示在交互界面上，也就是在中間件的控制台上，或運維自動化平台上，或研發協作平台上。

下面舉一些具體的例子，幫助大家理解。

我司的技術支撐體系如下圖所示（或點擊查看原圖）：

其中：

1，定時任務管理與調度平台有運行情況展示，自帶監控報警：

2，非同步消息可靠推送系統有可視化的內部詳情展示，自帶監控報警：

3，分散式並行計算調度與管理平台一站式展示工作流下每一個任務在所有節點上的運行日誌，並自帶監控報警：

4，大數據協作平台自帶監控報警：

5，我們甚至要把所有 PC 客戶端，所有智能設備都監管起來：

6，研發協作平台一站式展示應用部署的方方面面：

可以說我們打造的每一個中間件、協作平台都體現了戒律一和戒律二。

不需要東奔西走，四處收集蛛絲馬跡。

不需要一次性點開幾百個指標頁面，腦補推演。

不需要精通集群部署結構。

不需要熟知應用日誌的路徑。

對，這就是為我這樣的「旁觀者」、「小白」準備的。

有了這些系統，即使大家都出去玩了，我一個人也能看出問題所在，同時也能有效應對鐵打營盤流水兵的情況。

當你完成了從0到1的跨越，正在從1走向10，走向100，請記住下面的忠言：

兩個「是否有利於」：

一，是否有利於發布部署。

二，是否有利於排除故障（是否有利於快速定位問題和解決問題）。

兩個戒律：

戒律一：凡是中間件，不管是自主開發的，還是以開源軟體為內核構建出來的，都必須自帶監控報警，否則不允許上線。

戒律二：本著 Dont make me think 的哲學思路，所有對排除故障有幫助的信息，都必須一站式展示在交互界面上，也就是中間件的控制台上，或運維自動化平台上，或研發協作平台上。

-EOF-

歡迎訂閱我的微信訂閱號『老兵筆記』

贈圖一枚：

生活和你～

語錄兩條：

1，

王志安：「這叫調查？這叫武漢理工大學好嗎！」於是評論紛紛打蛇隨棍上：「對，武理取鬧！」#新詞發現#

2，

有一種離職叫『棄船逃生』：

『2011年在百度瀏覽器團隊時，遇到幾件讓人印象深刻的事情。有一次開會，產品拿出Google某個產品的DEMO，裡面有一段很酷炫的 3D 效果，要求開發加上，只給2天時間。大家目瞪口呆。後續，開發為了趕節奏，導致非常多的bug，又為了修改bug，leader將所有的bug按照人員平均分配，導致不同模塊間的同學相互修改……實在難以想像，好比讓做花捲的廚子，去修改西湖醋魚的味道。

最初的現象是：bug下降得慢，進而bug反而增加，每個人都累得半死，代碼風格極其雜亂，為了趕工引入的臨時方案層出不窮。

到了中期：人員離職越來也多，代碼難以維護，新加的需求與之前的臨時方案衝突。

到了後期：想做一些修復，想調整架構，又要保證正常運行，其難度好比在一架飛行中的飛機上拆換零件。

然後我也急忙離職了……實在是看不到成功的可能性。

後來到了騰訊的團隊，感覺流程就規範多了。需求和bug有Tapd跟蹤，產品發布按照節奏，需求提出前會和開發反覆討論可行性，有專門的質量跟蹤，有專門的用戶反饋，每天知道要做什麼，也知道明天要做什麼。有產品需求，也有開發需求！這個非常重要。很多團隊，都是只有產品需求，開發好像牛一樣，耕完地就不管了？

流程其實沒那麼複雜，就是各司其責+節奏。』——

https://zhuanlan.zhihu.com/p/35076829

推薦閱讀：