微服務的主要目的是將原本獨立的系統拆分成多個小的，有獨自進程運行的，同時這些小的服務單元之間通過RPC或者HTTP協議來相互通訊協作。每個獨立的服務單元內部都有自己的數據存儲、業務邏輯開發和自己的運維部署機制。我們在享受著微服務化后帶來的靈活性便利的同時，對我們的運維和服務治理也提出了新的挑戰。從早先單體應用中的代碼依賴，變成了通信依賴。我們就不得不考慮以下問題，比如網絡延遲、分布式事務、異步消息等等。

一、系統分類與演進

1. 統分類

我們的系統如果按照功能劃分的話，大概有如下三類系統。

第一類是接口服務系統，這類系統是提供外部接口比如JSF(京東自研RPC框架)、HTTP接口、hession接口等，這些接口有讀，有寫，尤其是寫接口，要考慮好寫的冪等性操作，讀天然是冪等的，做好防刷即可。

第二類是網頁類系統，用戶直接使用網頁，那么網頁上的數據區域來源，就要分清楚，一張網頁上面的數據從好多個源頭過來，每個源頭下面都有多個系統來支撐，如果一份數據來自多個渠道，需不需合并，都是要考慮的。

第三類是任務類系統，比如我們常見的統計、數據同步等功能的系統。這類系統要考慮任務是熱備還是冷備，多數都是熱備，此種情況下就需要考慮好分布式是任務調度的問題，資源分配，計算的準確性等。

每種系統對應的梳理方式又是不同的。

2. 系統演進

系統架構變化也是與時俱進的，早期的單體系統跟現在大家踐行的微服務化系統，在系統梳理上以及治理上也是完全不同。上圖是一個系統架構的演進(圖參照：《分布式服務框架》1.5章節)

二、梳理目的要搞清楚

每一年618和雙11之前，備戰開始，我們都要對所有的系統做一次梳理。那么每一次梳理的目的，就是要找出系統薄弱點。現在系統多了，系統里面的業務也變得復雜了。不過沒有關系，還是那句老話，打蛇打七寸，利用二八原理。集中精力到最重要的環節。另外80%不是說就不管了，這里面的業務可以走限流或者降級處理，當然也是要梳理的。只不過要有輕重之分。

三、如何做

我們要從大的方面梳理出一個系統包含哪些功能，這些功能里面哪些是核心功能也叫做黃金功能。同時從小的方面，對已經梳理出的核心功能，我要再梳理出這些功能對應的流程上包含的各個節點。每個節點要找出強依賴和弱依賴。強依賴，是說少了這個依賴功能不能完成，那么就要準備容災方案，也就是比如依賴的DB掛了，那么我們可以用開關切到MQ里面。弱依賴，則是不影響功能使用的依賴，比如插入ES記錄日志，那么ES掛掉，我們直接降級就好。

1. 接口服務類系統

我們要梳理出提供的所有服務接口，找出其中的黃金接口，比如接口1是黃金接口，那么我們就要確保這個接口一定是可用的，如何保證，就是災備。依賴資源比如redis集群，放兩個機房，一個機房兩套。總之這個接口是不可降級的，在不能降級的情況下，就要準備多套方案來確保接口1必須提供服務。

2. 網頁類系統

網頁類系統，比如首頁，類目、展示區、導航欄，廣告位，這些都不能掛，首頁是一個網站的臉，企業的臉，一定不能丟臉。每個功能區域對應的信息都要有多級緩存，有托底數據，無論如何都要保證頁面上是有內容的。

3. 任務類系統

對于任務類系統，一樣，要有分布式worker，切不可以單點。解決方案可以利用zookeeper+定時任務，自己實現，也可以采用開源的方案比如Elastic-Job。

上面的三類系統，在我們現有的結構中均都已微服務化，我們開篇也突出了微服務治理的特點，網絡延遲、分布式事務、異步消息。因此我們針對微服務的梳理也是從這幾個方面入手。關鍵點，就是找出通訊依賴，確定是強依賴，還是弱依賴。

4. 核心功能的核心流程梳理

梳理出核心功能以后，我們就要開始梳理核心流程，流程的梳理要找出關鍵節點，比如下面這張圖，只是作為舉例使用，一些類名和和字段都用XX代替。關鍵節點，就是我們重點對待的，強依賴哪些資源，弱依賴哪些資源。使用不同顏色標注，比如深黃色表示強依賴，淺綠色表示弱依賴。

四、總結

上面描述的過程中，列舉了系統的分類，系統的演進，流程的梳理。我們的最終目的就是要找出黃金功能，找出黃金流程，流程里面的強依賴和弱依賴。強依賴不可降級必須要有災備方案。做到以上幾點，確保梳理沒有遺漏，無論系統如何演進與變化，我們的服務治理，618和雙11的備戰都能很好的完成!

作者：王新棟，目前就職于京東，一直從事京麥平臺的架構設計與開發工作，熟悉各種開源軟件架構。在web開發，架構優化上有較豐富實戰經歷。有多年在NIO領域的設計、開發經驗，對HTTP、TCP長連接技術有深入研究與領悟，目前主要致力于移動與PC平臺網關技術的優化與實現。

【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】

戳這里，看該作者更多好文