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

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

1、系統分類與演進

1.1、系統分類

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

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

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

第三類是任務類系統，比如我們常見的統計、資料同步等功能的系統。這類系統要考慮任務是熱備還是冷備，多數都是熱備，此種情況下就需要考慮好分散式是任務排程的問題，資源分配，計算的準確性等。
每種系統對應的梳理方式又是不同的。

1.2、系統演進

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

2、梳理目的要搞清楚

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

3、如何做

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

3.1、介面服務類系統

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

3.2、網頁類系統

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

3.3、任務類系統

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

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

3.4、核心功能的核心流程梳理

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

4、總結

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