微服務(wù)的主要目的是將原本獨(dú)立的系統(tǒng)拆分成多個(gè)小的，有獨(dú)自進(jìn)程運(yùn)行的，同時(shí)這些小的服務(wù)單元之間通過(guò)RPC或者HTTP協(xié)議來(lái)相互通訊協(xié)作。每個(gè)獨(dú)立的服務(wù)單元內(nèi)部都有自己的數(shù)據(jù)存儲(chǔ)、業(yè)務(wù)邏輯開發(fā)和自己的運(yùn)維部署機(jī)制。我們?cè)谙硎苤⒎?wù)化后帶來(lái)的靈活性便利的同時(shí)，對(duì)我們的運(yùn)維和服務(wù)治理也提出了新的挑戰(zhàn)。從早先單體應(yīng)用中的代碼依賴，變成了通信依賴。我們就不得不考慮以下問(wèn)題，比如網(wǎng)絡(luò)延遲、分布式事務(wù)、異步消息等等。

一、系統(tǒng)分類與演進(jìn)

1. 系統(tǒng)分類

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

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

第二類是網(wǎng)頁(yè)類系統(tǒng)，用戶直接使用網(wǎng)頁(yè)，那么網(wǎng)頁(yè)上的數(shù)據(jù)區(qū)域來(lái)源，就要分清楚，一張網(wǎng)頁(yè)上面的數(shù)據(jù)從好多個(gè)源頭過(guò)來(lái)，每個(gè)源頭下面都有多個(gè)系統(tǒng)來(lái)支撐，如果一份數(shù)據(jù)來(lái)自多個(gè)渠道，需不需合并，都是要考慮的。

第三類是任務(wù)類系統(tǒng)，比如我們常見(jiàn)的統(tǒng)計(jì)、數(shù)據(jù)同步等功能的系統(tǒng)。這類系統(tǒng)要考慮任務(wù)是熱備還是冷備，多數(shù)都是熱備，此種情況下就需要考慮好分布式是任務(wù)調(diào)度的問(wèn)題，資源分配，計(jì)算的準(zhǔn)確性等。

每種系統(tǒng)對(duì)應(yīng)的梳理方式又是不同的。

2. 系統(tǒng)演進(jìn)

系統(tǒng)架構(gòu)變化也是與時(shí)俱進(jìn)的，早期的單體系統(tǒng)跟現(xiàn)在大家踐行的微服務(wù)化系統(tǒng)，在系統(tǒng)梳理上以及治理上也是完全不同。上圖是一個(gè)系統(tǒng)架構(gòu)的演進(jìn)(圖參照：《分布式服務(wù)框架》1.5章節(jié))

二、梳理目的要搞清楚

每一年618和雙11之前，備戰(zhàn)開始，我們都要對(duì)所有的系統(tǒng)做一次梳理。那么每一次梳理的目的，就是要找出系統(tǒng)薄弱點(diǎn)。現(xiàn)在系統(tǒng)多了，系統(tǒng)里面的業(yè)務(wù)也變得復(fù)雜了。不過(guò)沒(méi)有關(guān)系，還是那句老話，打蛇打七寸，利用二八原理。集中精力到最重要的環(huán)節(jié)。另外80%不是說(shuō)就不管了，這里面的業(yè)務(wù)可以走限流或者降級(jí)處理，當(dāng)然也是要梳理的。只不過(guò)要有輕重之分。

三、如何做

我們要從大的方面梳理出一個(gè)系統(tǒng)包含哪些功能，這些功能里面哪些是核心功能也叫做黃金功能。同時(shí)從小的方面，對(duì)已經(jīng)梳理出的核心功能，我要再梳理出這些功能對(duì)應(yīng)的流程上包含的各個(gè)節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)要找出強(qiáng)依賴和弱依賴。強(qiáng)依賴，是說(shuō)少了這個(gè)依賴功能不能完成，那么就要準(zhǔn)備容災(zāi)方案，也就是比如依賴的DB掛了，那么我們可以用開關(guān)切到MQ里面。弱依賴，則是不影響功能使用的依賴，比如插入ES記錄日志，那么ES掛掉，我們直接降級(jí)就好。

1. 接口服務(wù)類系統(tǒng)

我們要梳理出提供的所有服務(wù)接口，找出其中的黃金接口，比如接口1是黃金接口，那么我們就要確保這個(gè)接口一定是可用的，如何保證，就是災(zāi)備。依賴資源比如redis集群，放兩個(gè)機(jī)房，一個(gè)機(jī)房?jī)商住？傊@個(gè)接口是不可降級(jí)的，在不能降級(jí)的情況下，就要準(zhǔn)備多套方案來(lái)確保接口1必須提供服務(wù)。

2. 網(wǎng)頁(yè)類系統(tǒng)

網(wǎng)頁(yè)類系統(tǒng)，比如首頁(yè)，類目、展示區(qū)、導(dǎo)航欄，廣告位，這些都不能掛，首頁(yè)是一個(gè)網(wǎng)站的臉，企業(yè)的臉，一定不能丟臉。每個(gè)功能區(qū)域?qū)?yīng)的信息都要有多級(jí)緩存，有托底數(shù)據(jù)，無(wú)論如何都要保證頁(yè)面上是有內(nèi)容的。

3. 任務(wù)類系統(tǒng)

對(duì)于任務(wù)類系統(tǒng)，一樣，要有分布式worker，切不可以單點(diǎn)。解決方案可以利用zookeeper+定時(shí)任務(wù)，自己實(shí)現(xiàn)，也可以采用開源的方案比如Elastic-Job,

上面的三類系統(tǒng)，在我們現(xiàn)有的結(jié)構(gòu)中均都已微服務(wù)化，我們開篇也突出了微服務(wù)治理的特點(diǎn)，網(wǎng)絡(luò)延遲、分布式事務(wù)、異步消息。因此我們針對(duì)微服務(wù)的梳理也是從這幾個(gè)方面入手。關(guān)鍵點(diǎn)，就是找出通訊依賴，確定是強(qiáng)依賴，還是弱依賴。

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

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

四、總結(jié)

上面描述的過(guò)程中，列舉了系統(tǒng)的分類，系統(tǒng)的演進(jìn)，流程的梳理。我們的最終目的就是要找出黃金功能，找出黃金流程，流程里面的強(qiáng)依賴和弱依賴。強(qiáng)依賴不可降級(jí)必須要有災(zāi)備方案。做到以上幾點(diǎn)，確保梳理沒(méi)有遺漏，無(wú)論系統(tǒng)如何演進(jìn)與變化，我們的服務(wù)治理，618和雙11的備戰(zhàn)都能很好的完成!

作者：王新棟，目前就職于京東，一直從事京麥平臺(tái)的架構(gòu)設(shè)計(jì)與開發(fā)工作，熟悉各種開源軟件架構(gòu)。在web開發(fā)，架構(gòu)優(yōu)化上有較豐富實(shí)戰(zhàn)經(jīng)歷。有多年在NIO領(lǐng)域的設(shè)計(jì)、開發(fā)經(jīng)驗(yàn)，對(duì)HTTP、TCP長(zhǎng)連接技術(shù)有深入研究與領(lǐng)悟，目前主要致力于移動(dòng)與PC平臺(tái)網(wǎng)關(guān)技術(shù)的優(yōu)化與實(shí)現(xiàn)。

【本文是51CTO專欄作者張開濤的原創(chuàng)文章，作者微信公眾號(hào)：開濤的博客( kaitao-1234567)】

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