說(shuō)明： 內(nèi)容主要裁剪自《干貨：36頁(yè)P(yáng)PT詳解余額寶背后的服務(wù)治理架構(gòu)》--作者簡(jiǎn)介： 天弘基金移動(dòng)平臺(tái)團(tuán)隊(duì)任技術(shù)總監(jiān)兼首席架構(gòu)師，主要負(fù)責(zé)天弘移動(dòng)直銷平臺(tái)的整體技術(shù)架構(gòu)和技術(shù)團(tuán)隊(duì)管理。查看原文

感悟： 通過(guò)用心學(xué)習(xí)大神分享的經(jīng)驗(yàn)和實(shí)踐，基本可以對(duì)余額寶背后的服務(wù)治理架構(gòu)有比較深入的了解，里面提到的一些最佳實(shí)踐可以借鑒到我們自己實(shí)際的項(xiàng)目中。大道至簡(jiǎn)，學(xué)以致用，才是王道。

目錄

一.?服務(wù)化架構(gòu)演變

二.?業(yè)務(wù)中臺(tái)是什么？

三.?服務(wù)化的沖擊及挑戰(zhàn)

分布式事務(wù)

四.?三位一體服務(wù)治理

五.?服務(wù)度量體系

1.?全生命周期度量指標(biāo)獲取

2.?服務(wù)治理度量及分析體系

六.?服務(wù)線上治理

1.?服務(wù)限流

2.?集群容錯(cuò)

3.?服務(wù)降級(jí)，熔斷

4.?容量規(guī)劃

5.?故障定界定位

6.?服務(wù)生命周期管理

7.?服務(wù)整體架構(gòu)治理

七.?研發(fā)協(xié)同治理

1.?服務(wù)化背景下的團(tuán)隊(duì)協(xié)同最佳實(shí)踐

2.?協(xié)同度量及治理

3.?開(kāi)發(fā)治理

4.?測(cè)試質(zhì)量治理

5.?分布式調(diào)試能力構(gòu)建

---

服務(wù)化架構(gòu)演變

前后經(jīng)歷了3個(gè)階段：

典型的單體+豎井架構(gòu)，復(fù)用性及可擴(kuò)展性都差。

隨著業(yè)務(wù)的快速發(fā)展及多端適配需求增多，兩層架構(gòu)下的前臺(tái)業(yè)務(wù)服務(wù)層還是太重，無(wú)法支撐業(yè)務(wù)的快速變更，這時(shí)候?qū)⑵淅^續(xù)拆分，將業(yè)務(wù)域的通用服務(wù)繼續(xù)下層出新的業(yè)務(wù)中臺(tái)層，這就形成了現(xiàn)在的三層服務(wù)化分層架構(gòu)。

在目前的三層服務(wù)分層架構(gòu)下，通用服務(wù)被不斷下沉，所以越底層的服務(wù)被抽象度越高，也更通用、更靜態(tài)，不會(huì)經(jīng)常改變；越靠近前端的服務(wù)越貼近業(yè)務(wù)，越不穩(wěn)定，會(huì)隨著業(yè)務(wù)的快速變化而不斷改變，客觀上也必須保持更輕的體態(tài)。

【關(guān)鍵詞：單體，煙囪，服務(wù)分層，前臺(tái)，業(yè)務(wù)中臺(tái)，通用后臺(tái)】

---

業(yè)務(wù)中臺(tái)是什么？

為什么會(huì)形成業(yè)務(wù)中臺(tái)這樣一個(gè)服務(wù)層呢？

本質(zhì)上還是和業(yè)務(wù)的發(fā)展息息相關(guān)，業(yè)務(wù)的快速發(fā)展會(huì)驅(qū)使你不斷的對(duì)服務(wù)進(jìn)行拆分，并將通用服務(wù)不斷下沉，只有這樣，才能將服務(wù)拆的更小，而服務(wù)粒度越小，可組裝性越好。只有這樣，我們才可以根據(jù)不同的業(yè)務(wù)形態(tài)，通過(guò)服務(wù)組裝和聚合的方式快速構(gòu)建出前端應(yīng)用，從而實(shí)現(xiàn)更快的開(kāi)發(fā)速度，以支持業(yè)務(wù)的快速迭代及試錯(cuò)。

• 服務(wù)化架構(gòu)的分層質(zhì)量對(duì)業(yè)務(wù)中臺(tái)的形成就有很重要的意義。如何進(jìn)行更好、邊界更清晰的服務(wù)分層，會(huì)直接影響到能否成功長(zhǎng)出業(yè)務(wù)中臺(tái)這個(gè)分層形態(tài)。
• 康威定律：組織的協(xié)同及管理模式必須與所采用的系統(tǒng)架構(gòu)相匹配。
• 要最終推動(dòng)業(yè)務(wù)中臺(tái)這樣的服務(wù)分層的誕生，業(yè)務(wù)驅(qū)動(dòng)、服務(wù)分層、通用服務(wù)下沉、組織拆分都是必不可少的因素。

啟示：如果你的業(yè)務(wù)形態(tài)比較單一，發(fā)展相對(duì)靜態(tài)的話，就不會(huì)有那么強(qiáng)烈的服務(wù)分層和拆分的需求，自然就長(zhǎng)不出所謂的“業(yè)務(wù)中臺(tái)”的服務(wù)分層。所以，業(yè)務(wù)中臺(tái)的建設(shè)要順其自然，強(qiáng)扭的瓜不甜，企業(yè)需要根據(jù)自己的業(yè)務(wù)特征來(lái)判斷是否需要建設(shè)業(yè)務(wù)中臺(tái)。

【關(guān)鍵詞：業(yè)務(wù)驅(qū)動(dòng)，服務(wù)分層，快速試錯(cuò)，組織架構(gòu)匹配】

---

服務(wù)化的沖擊及挑戰(zhàn)

架構(gòu)的變更帶來(lái)的影響是全方位的，影響的絕不僅僅只是應(yīng)用系統(tǒng)，它會(huì)對(duì)整個(gè)研發(fā)體系，包括開(kāi)發(fā)、運(yùn)維、團(tuán)隊(duì)組織、協(xié)同都帶來(lái)沖擊，你必須構(gòu)建起一整套從線下到線上的新的能力體系來(lái)支撐這套新的架構(gòu)。

啟示：很多團(tuán)隊(duì)沒(méi)能構(gòu)建起這套能力體系，直接在服務(wù)化的“反噬”下，倒在了路上，看不到服務(wù)化帶來(lái)的“曙光”。

思考：集群環(huán)境中故障的定界定位：你如何快速定位問(wèn)題出在哪？整個(gè)集群的調(diào)用關(guān)系是什么樣的，如何梳理？合理不合理？整個(gè)集群的性能瓶頸在哪？這些都是運(yùn)維要直面的問(wèn)題。對(duì)研發(fā)來(lái)說(shuō)，挑戰(zhàn)也不少。團(tuán)隊(duì)被拆分了，團(tuán)隊(duì)之間如何高效的協(xié)作？系統(tǒng)被拆分了，功能被分散到遠(yuǎn)程節(jié)點(diǎn)，如何做調(diào)試？分布式架構(gòu)下的數(shù)據(jù)一致性如何保障？等等…

【關(guān)鍵詞：運(yùn)維困局，開(kāi)發(fā)困局】

---

分布式事務(wù)

啟示：最終一致性的保障一定是“對(duì)賬、對(duì)賬、對(duì)賬”！這是最傳統(tǒng)，也是最可靠的最終防線，這也是金融公司的基礎(chǔ)能力。

---

三位一體服務(wù)治理

【管理-度量-管控】在這套體系中，針對(duì)服務(wù)的度量是進(jìn)行服務(wù)管控和管理的前提和基礎(chǔ)，只有看得到，才能管得到，必須先解決“看”的問(wèn)題，才能解決“管”的問(wèn)題。

---

服務(wù)度量體系

全生命周期度量指標(biāo)獲取

不管采用何種協(xié)作模式，都可以從其相關(guān)的過(guò)程管理系統(tǒng)中抽取出相關(guān)的過(guò)程指標(biāo)事件，比如一個(gè)任務(wù)什么時(shí)候完成設(shè)計(jì)、什么時(shí)候開(kāi)始進(jìn)入開(kāi)發(fā)、什么時(shí)候完成開(kāi)發(fā)…等等，這也是一大類很重要的治理度量指標(biāo)。

【關(guān)鍵詞：持續(xù)交付，DevOps, 敏捷持續(xù)集成，線下+線上】

---

服務(wù)治理度量及分析體系

治理決策和管控指令就是微服務(wù)度量及分析體系的最終產(chǎn)出物。

---

服務(wù)線上治理

服務(wù)限流

構(gòu)建服務(wù)限流能力的難點(diǎn)，一是標(biāo)準(zhǔn)化，二是體系化。

大公司往往就是依靠體系的力量去構(gòu)建起護(hù)城河，從而去碾壓沒(méi)有體系能力的小公司。

啟示： 限流一大原則是限流動(dòng)作盡量前置，畢竟被限制的流量注定要被“拋棄”，越早處理越好，免得無(wú)謂的消耗資源。

【關(guān)鍵詞： 單機(jī)限流，集群限流，標(biāo)準(zhǔn)化，體系化】

---

集群容錯(cuò)

不管你決定使用哪種集群容錯(cuò)策略，一定要注意控制重試的次數(shù)，尤其是線上負(fù)載已經(jīng)很高的時(shí)候，如果重試次數(shù)太多，一方面會(huì)推高服務(wù)被調(diào)用方的負(fù)載及并發(fā)，另外一方面會(huì)導(dǎo)致服務(wù)調(diào)用方的調(diào)用延時(shí)增長(zhǎng)，雙重因素疊加之下，最終極可能導(dǎo)致“服務(wù)雪崩”、集群被“擊穿”。

啟示：在使用集群容錯(cuò)的時(shí)候，一定要設(shè)置最大重試次數(shù)。

---

服務(wù)降級(jí)，熔斷

一般在線上動(dòng)用服務(wù)降級(jí)手段時(shí)，都是線上比較危急的時(shí)候，生死存亡了，這時(shí)候留給你思考和反應(yīng)的時(shí)間不多，所以在使用服務(wù)降級(jí)之前一定要做好預(yù)案，提前梳理出核心業(yè)務(wù)鏈路和非核心業(yè)務(wù)鏈路，然后通過(guò)降級(jí)開(kāi)關(guān)一鍵把部分或所有非核心鏈路降級(jí)，這樣才能“救命”。

服務(wù)降級(jí)也有很多手段可以使用，包括：

• 容錯(cuò)降級(jí)
• 靜態(tài)返回值降級(jí)
• Mock降級(jí)
• 備用服務(wù)降級(jí)

構(gòu)建服務(wù)降級(jí)能力也和限流機(jī)制類似，同樣需要堅(jiān)持標(biāo)準(zhǔn)化和體系化。

【關(guān)鍵詞：標(biāo)準(zhǔn)化，體系化，預(yù)案】

---

容量規(guī)劃

容量規(guī)劃有兩種形式：一種是容量預(yù)估，另一種是性能壓測(cè)。

• 全鏈路壓測(cè)的前提是單點(diǎn)壓測(cè)，需要先把單點(diǎn)壓測(cè)能力做好，才能做全鏈路壓測(cè)。
• 在壓測(cè)的時(shí)候，由于流量是模擬的，數(shù)據(jù)也是“偽造”的，所以一定要做好隔離，各種各樣的隔離，尤其是數(shù)據(jù)的隔離。
• 在線性能壓測(cè)是個(gè)“苦活”，需要提前發(fā)公告、全員戒備、時(shí)刻關(guān)注監(jiān)控指標(biāo)、有時(shí)候還要通宵搞，總結(jié)起來(lái)就是：智力密集型+勞動(dòng)密集型+人肉密集型。

【關(guān)鍵詞：容量預(yù)估，依賴關(guān)系，數(shù)據(jù)準(zhǔn)備，數(shù)據(jù)隔離，支持體系】

---

故障定界定位

分布式環(huán)境下的故障定界定位，最有效的工具就是動(dòng)態(tài)調(diào)用鏈路跟蹤。使用開(kāi)源的Zipkin，SkyWalking、PinPoint、CAT，還是使用商用的聽(tīng)云、AppDynamic或NewRelic等等。

動(dòng)態(tài)調(diào)用鏈要用的好一定是需要和監(jiān)控大盤(pán)相結(jié)合：

• ?我們有一個(gè)單位時(shí)間段內(nèi)異常最多服務(wù)的TopN排序列表，點(diǎn)擊列表上的任何一個(gè)服務(wù)，會(huì)打開(kāi)這個(gè)服務(wù)這個(gè)時(shí)間段內(nèi)所有異常的列表，再點(diǎn)擊列表上的每一個(gè)異常，就會(huì)打開(kāi)這個(gè)異常所屬調(diào)用鏈，進(jìn)行故障分析。
• ?可以利用監(jiān)控大盤(pán)，監(jiān)控大盤(pán)上有很多“毛刺”，這些都是系統(tǒng)的一些異常點(diǎn)，點(diǎn)擊任何一個(gè)“毛刺”，會(huì)將“毛刺”所在時(shí)間段內(nèi)的請(qǐng)求以“散點(diǎn)”的形式列出（可能會(huì)基于請(qǐng)求數(shù)量做抽樣），“散點(diǎn)”的顏色代表了不同的狀態(tài)，有的成功，有的失敗。點(diǎn)擊任何一個(gè)“散點(diǎn)”，就可以進(jìn)入這個(gè)請(qǐng)求對(duì)應(yīng)的調(diào)用鏈。
• 針對(duì)核心服務(wù)的異常有專門(mén)的監(jiān)控表格，會(huì)列出最近發(fā)生的核心鏈路服務(wù)上的異常，點(diǎn)擊這上面的任何一個(gè)異常，也可以進(jìn)入對(duì)應(yīng)的調(diào)用鏈。

【關(guān)鍵詞：可視化，局部和全局，2/8原則】

---

服務(wù)生命周期管理

目前使用螞蟻金融云提供的SOFA分布式服務(wù)框架，針對(duì)服務(wù)的線上生命周期管控的能力也是基于螞蟻金融云的能力來(lái)構(gòu)建的，螞蟻金融云在它的云上彈性計(jì)算資源的基礎(chǔ)上，通過(guò)整合資源編排及資源調(diào)度的能力，構(gòu)建了微服務(wù)的綜合管控平臺(tái)。，通過(guò)這個(gè)平臺(tái)，可以比較方便的進(jìn)行服務(wù)的上線、下線、擴(kuò)容、縮容等操作。

---

服務(wù)整體架構(gòu)治理

服務(wù)是分層的，好的服務(wù)調(diào)用關(guān)系一定也是分層的，層層往下推進(jìn)，最終形成一個(gè)有向無(wú)環(huán)圖（DAG）。

• 對(duì)調(diào)用關(guān)系圖進(jìn)行閉環(huán)檢測(cè)，如果檢測(cè)到如圖上G點(diǎn)到B點(diǎn)這樣的回環(huán)調(diào)用的話，說(shuō)明調(diào)用關(guān)系有問(wèn)題，需要進(jìn)行優(yōu)化。這種回環(huán)調(diào)用也許現(xiàn)在無(wú)感，但難保未來(lái)哪天就會(huì)由于一條旁路邏輯導(dǎo)致死循環(huán)。
• 從調(diào)用關(guān)系上來(lái)說(shuō)，它是被依賴最多的節(jié)點(diǎn)，自然是最重要的節(jié)點(diǎn)，作為樞紐節(jié)點(diǎn)，在運(yùn)維等級(jí)上需要重點(diǎn)保障。當(dāng)然，實(shí)際應(yīng)用中，我們還會(huì)加上調(diào)用量這個(gè)權(quán)重來(lái)綜合判定服務(wù)節(jié)點(diǎn)的重要性。
• 可能有些服務(wù)節(jié)點(diǎn)再也不會(huì)有調(diào)用關(guān)系了，比如圖上綠色的L節(jié)點(diǎn)，這些節(jié)點(diǎn)再不會(huì)去調(diào)用別的服務(wù)節(jié)點(diǎn)，別的服務(wù)節(jié)點(diǎn)也不會(huì)來(lái)調(diào)用它。這類被找出來(lái)的“孤零零”的節(jié)點(diǎn)，可以考慮對(duì)它進(jìn)行下線處理，以釋放資源。

研發(fā)協(xié)同治理

服務(wù)化背景下的團(tuán)隊(duì)協(xié)同最佳實(shí)踐

• 在每期工作量評(píng)估時(shí)，一般會(huì)預(yù)留一些工作量buffer，以應(yīng)對(duì)臨時(shí)性的需求，這類需求不受版本約束，按需發(fā)布。如果這個(gè)迭代周期內(nèi)沒(méi)有緊急需求，我們會(huì)從backlog中撈一些架構(gòu)優(yōu)化的需求來(lái)填補(bǔ)這些buffer。
• 為什么會(huì)持續(xù)有一些架構(gòu)優(yōu)化的活呢？因?yàn)榻?jīng)常有一些緊急需求，使用正常開(kāi)發(fā)方案可能無(wú)法如期上線，但業(yè)務(wù)又要的比較急，必須用一些應(yīng)急性的臨時(shí)方案先上線使用。

---

協(xié)同度量及治理

每個(gè)迭代持續(xù)的進(jìn)行精益看板的數(shù)據(jù)分析和度量，并通過(guò)治理策略進(jìn)行不斷的改進(jìn)優(yōu)化，可以讓我們的研發(fā)協(xié)同越來(lái)越順暢。

【關(guān)鍵詞：精益看板，指標(biāo)度量，持續(xù)優(yōu)化】

---

開(kāi)發(fā)治理

• 針對(duì)代碼質(zhì)量的管理，常規(guī)的做法除了代碼的codereview外，一般還會(huì)使用Checkstyle，FindBugs，Jtest這類靜態(tài)代碼掃描工具來(lái)做代碼的缺陷掃描。
• 匯總個(gè)人的質(zhì)量綜合評(píng)估報(bào)告，可以獲得針對(duì)團(tuán)隊(duì)的開(kāi)發(fā)質(zhì)量綜合評(píng)估報(bào)告。這兩個(gè)報(bào)告本質(zhì)上就是個(gè)人及團(tuán)隊(duì)的研發(fā)質(zhì)量“畫(huà)像”，完全可以作為個(gè)人及團(tuán)隊(duì)KPI考核的重要參考。

---

測(cè)試質(zhì)量治理

兩大核心訴求：一是提高測(cè)試的覆蓋度，具體說(shuō)就是提高需求覆蓋度、代碼覆蓋度、頁(yè)面覆蓋度；二是降低測(cè)試用例的維護(hù)成本。

• 需求覆蓋度：可以通過(guò)服務(wù)這個(gè)維度來(lái)對(duì)需求及測(cè)試用例進(jìn)行關(guān)聯(lián)，找出每個(gè)需求所對(duì)應(yīng)的單元測(cè)試用例、自動(dòng)化測(cè)試用例、手工測(cè)試用例，還可以把多個(gè)開(kāi)發(fā)迭代周期的這些指標(biāo)進(jìn)行時(shí)間維度的縱比，以得出需求覆蓋度的變化趨勢(shì)。
• 代碼覆蓋度：有很多的工具幫我們來(lái)做，比如contest或者JaCoCo這類的工具，這里不再贅述。
• 頁(yè)面覆蓋度：可以將每次集成測(cè)試中調(diào)用的頁(yè)面以日志的形式記錄下來(lái)，再通過(guò)日志的聚合分析，結(jié)合工程源碼的掃描，兩廂一比較，就可以統(tǒng)計(jì)出哪些頁(yè)面是沒(méi)有被覆蓋到的。
• 測(cè)試用例的維護(hù)成本分兩塊，一塊是新增用例的維護(hù)成本，這個(gè)比較好度量；比較麻煩的是存量測(cè)試用例的變更度度量，我們采用相似度匹配算法，先算出存量測(cè)試用例前后兩個(gè)版本代碼的相似度，再換算成變更度。

【關(guān)鍵詞：覆蓋度，用例維護(hù)成本】

---

分布式調(diào)試能力構(gòu)建

• 利用分布式服務(wù)框架提供的過(guò)濾器機(jī)制，開(kāi)發(fā)了一個(gè)Mock過(guò)濾器，通過(guò)Mock數(shù)據(jù)文件來(lái)詳細(xì)定義要被mock的服務(wù)的名稱、入?yún)⒓俺鰠ⅰ＿@樣，當(dāng)請(qǐng)求過(guò)來(lái)時(shí)，將服務(wù)名及入?yún)⒑蚼ock數(shù)據(jù)中的定義進(jìn)行比對(duì)，結(jié)果吻合，就直接將mock數(shù)據(jù)文件中的出參反序列化后作為服務(wù)的調(diào)用結(jié)果直接返回，同時(shí)遠(yuǎn)程調(diào)用的所有后續(xù)操作被終止。
• 基于服務(wù)框架的過(guò)濾器機(jī)制開(kāi)發(fā)了“在線數(shù)據(jù)抓取過(guò)濾器”，它可以將指定的服務(wù)請(qǐng)求的入?yún)⒑头祷亟Y(jié)果都抓取下來(lái)，直接寫(xiě)成mock數(shù)據(jù)文件。通過(guò)抓取方式獲得的mock數(shù)據(jù)文件，往往有更好的數(shù)據(jù)質(zhì)量，畢竟反映的是更加真實(shí)的業(yè)務(wù)場(chǎng)景。不過(guò)，這里還有一個(gè)合規(guī)性的問(wèn)題，一定要做好數(shù)據(jù)脫敏的處理工作。對(duì)于我們，目前只在測(cè)試環(huán)境中進(jìn)行數(shù)據(jù)抓取操作。
• 綜合調(diào)測(cè)能力是綜合P2P直連和Mock兩種方式來(lái)共同構(gòu)建的。在項(xiàng)目迭代的早期，前端團(tuán)隊(duì)和服務(wù)端團(tuán)隊(duì)，中臺(tái)開(kāi)發(fā)團(tuán)隊(duì)和后臺(tái)開(kāi)發(fā)團(tuán)隊(duì)會(huì)先定義接口，再基于接口直接生成mock文件，這樣大家就可以并行開(kāi)發(fā)。開(kāi)始時(shí)，服務(wù)都沒(méi)有開(kāi)發(fā)出來(lái)，mock比例是最高的；隨著迭代的進(jìn)行，服務(wù)被不斷開(kāi)發(fā)出來(lái)，并部署到線上，這時(shí)，P2P直連調(diào)測(cè)的比例會(huì)上升，Mock的比例會(huì)下降；一直到集成測(cè)試時(shí)，只剩下P2P直連的模式，沒(méi)有mock了。

【關(guān)鍵詞：調(diào)試能力，Mock，綜合調(diào)試】

?

與50位技術(shù)專家面對(duì)面20年技術(shù)見(jiàn)證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的【架构】学习余额宝背后的服务治理架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。