微服務的主要目的是將原本獨立的系統拆分成多個小的，有獨自進程運行的，同時這些小的服務單元之間通過RPC或者HTTP協議來相互通訊協作。每個獨立的服務單元內部都有自己的數據存儲、業務邏輯開發和自己的運維部署機制。我們在享受著微服務化后帶來的靈活性便利的同時，對我們的運維和服務治理也提出了新的挑戰。從早先單體應用中的代碼依賴，變成了通信依賴。我們就不得不考慮以下問題，比如網絡延遲、分布式事務、異步消息等等。
1、系統分類與演進
1.1、系統分類
我們的系統如果按照功能劃分的話，大概有如下三類系統。
第一類是接口服務系統，這類系統是提供外部接口比如JSF(京東自研RPC框架)、HTTP接口、hession接口等，這些接口有讀，有寫，尤其是寫接口，要考慮好寫的冪等性操作，讀天然是冪等的，做好防刷即可。
第二類是網頁類系統，用戶直接使用網頁，那么網頁上的數據區域來源，就要分清楚，一張網頁上面的數據從好多個源頭過來，每個源頭下面都有多個系統來支撐，如果一份數據來自多個渠道，需不需合并，都是要考慮的。
第三類是任務類系統，比如我們常見的統計、數據同步等功能的系統。這類系統要考慮任務是熱備還是冷備，多數都是熱備，此種情況下就需要考慮好分布式是任務調度的問題，資源分配，計算的準確性等。
每種系統對應的梳理方式又是不同的。
1.2、系統演進
系統演進圖.png
系統架構變化也是與時俱進的，早期的單體系統跟現在大家踐行的微服務化系統，在系統梳理上以及治理上也是完全不同。上圖是一個系統架構的演進(圖參照：《分布式服務框架》1.5章節)
2、梳理目的要搞清楚
每一年618和雙11之前，備戰開始，我們都要對所有的系統做一次梳理。那么每一次梳理的目的，就是要找出系統薄弱點。現在系統多了，系統里面的業務也變得復雜了。不過沒有關系，還是那句老話，打蛇打七寸，利用二八原理。集中精力到最重要的環節。另外80%不是說就不管了，這里面的業務可以走限流或者降級處理，當然也是要梳理的。只不過要有輕重之分。
3、如何做
我們要從大的方面梳理出一個系統包含哪些功能，這些功能里面哪些是核心功能也叫做黃金功能。同時從小的方面，對已經梳理出的核心功能，我要再梳理出這些功能對應的流程上包含的各個節點。每個節點要找出強依賴和弱依賴。強依賴，是說少了這個依賴功能不能完成，那么就要準備容災方案，也就是比如依賴的DB掛了，那么我們可以用開關切到MQ里面。弱依賴，則是不影響功能使用的依賴，比如插入ES記錄日志，那么ES掛掉，我們直接降級就好。
3.1、接口服務類系統
接口服務類型系統.png
我們要梳理出提供的所有服務接口，找出其中的黃金接口，比如接口1是黃金接口，那么我們就要確保這個接口一定是可用的，如何保證，就是災備。依賴資源比如redis集群，放兩個機房，一個機房兩套。總之這個接口是不可降級的，在不能降級的情況下，就要準備多套方案來確保接口1必須提供服務。
3.2、網頁類系統
網頁類系統.png
網頁類系統，比如首頁，類目、展示區、導航欄，廣告位，這些都不能掛，首頁是一個網站的臉，企業的臉，一定不能丟臉。每個功能區域對應的信息都要有多級緩存，有托底數據，無論如何都要保證頁面上是有內容的。
3.3、任務類系統
任務類系統.png
對于任務類系統，一樣，要有分布式worker，切不可以單點。解決方案可以利用zookeeper+定時任務，自己實現，也可以采用開源的方案比如Elastic-Job,
上面的三類系統，在我們現有的結構中均都已微服務化，我們開篇也突出了微服務治理的特點，網絡延遲、分布式事務、異步消息。因此我們針對微服務的梳理也是從這幾個方面入手。關鍵點，就是找出通訊依賴，確定是強依賴，還是弱依賴。
3.4、核心功能的核心流程梳理
梳理出核心功能以后，我們就要開始梳理核心流程，流程的梳理要找出關鍵節點，比如下面這張圖，只是作為舉例使用，一些類名和和字段都用XX代替。關鍵節點，就是我們重點對待的，強依賴哪些資源，弱依賴哪些資源。使用不同顏色標注，比如深黃色表示強依賴，淺綠色表示弱依賴。
核心流程梳理參照圖.png
4、總結
上面描述的過程中，列舉了系統的分類，系統的演進，流程的梳理。我們的最終目的就是要找出黃金功能，找出黃金流程，流程里面的強依賴和弱依賴。強依賴不可降級必須要有災備方案。做到以上幾點，確保梳理沒有遺漏，無論系統如何演進與變化，我們的服務治理，618和雙11的備戰都能很好的完成!
京公網安備 11010502049343號