說明： 內容主要裁剪自《乾貨：36頁PPT詳解餘額寶背後的服務治理架構》--作者簡介： 天弘基金移動平臺團隊任技術總監兼首席架構師，主要負責天弘移動直銷平臺的整體技術架構和技術團隊管理。查看原文
感悟： 通過用心學習大神分享的經驗和實踐，基本可以對餘額寶背後的服務治理架構有比較深入的瞭解，裏面提到的一些最佳實踐可以借鑑到我們自己實際的項目中。大道至簡，學以致用，纔是王道。
目錄
一. 服務化架構演變
二. 業務中臺是什麼？
三. 服務化的衝擊及挑戰
四. 三位一體服務治理
五. 服務度量體系
1. 全生命週期度量指標獲取
2. 服務治理度量及分析體系
六. 服務線上治理
1. 服務限流
2. 集羣容錯
3. 服務降級，熔斷
4. 容量規劃
5. 故障定界定位
6. 服務生命週期管理
7. 服務整體架構治理
七. 研發協同治理
2. 協同度量及治理
3. 開發治理
4. 測試質量治理
5. 分佈式調試能力構建
服務化架構演變
前後經歷了3個階段：
- 典型的單體+豎井架構，複用性及可擴展性都差。
- 隨着業務的快速發展及多端適配需求增多，兩層架構下的前臺業務服務層還是太重，無法支撐業務的快速變更，這時候將其繼續拆分，將業務域的通用服務繼續下層出新的業務中臺層，這就形成了現在的三層服務化分層架構。
- 在目前的三層服務分層架構下，通用服務被不斷下沉，所以越底層的服務被抽象度越高，也更通用、更靜態，不會經常改變；越靠近前端的服務越貼近業務，越不穩定，會隨着業務的快速變化而不斷改變，客觀上也必須保持更輕的體態。
【關鍵詞：單體，煙囪，服務分層，前臺，業務中臺，通用後臺】
業務中臺是什麼？
爲什麼會形成業務中臺這樣一個服務層呢？
本質上還是和業務的發展息息相關，業務的快速發展會驅使你不斷的對服務進行拆分，並將通用服務不斷下沉，只有這樣，才能將服務拆的更小，而服務粒度越小，可組裝性越好。只有這樣，我們纔可以根據不同的業務形態，通過服務組裝和聚合的方式快速構建出前端應用，從而實現更快的開發速度，以支持業務的快速迭代及試錯。
- 服務化架構的分層質量對業務中臺的形成就有很重要的意義。如何進行更好、邊界更清晰的服務分層，會直接影響到能否成功長出業務中臺這個分層形態。
- 康威定律：組織的協同及管理模式必須與所採用的系統架構相匹配。
- 要最終推動業務中臺這樣的服務分層的誕生，業務驅動、服務分層、通用服務下沉、組織拆分都是必不可少的因素。
啓示：如果你的業務形態比較單一，發展相對靜態的話，就不會有那麼強烈的服務分層和拆分的需求，自然就長不出所謂的“業務中臺”的服務分層。所以，業務中臺的建設要順其自然，強扭的瓜不甜，企業需要根據自己的業務特徵來判斷是否需要建設業務中臺。
【關鍵詞：業務驅動，服務分層，快速試錯，組織架構匹配】
服務化的衝擊及挑戰
架構的變更帶來的影響是全方位的，影響的絕不僅僅只是應用系統，它會對整個研發體系，包括開發、運維、團隊組織、協同都帶來衝擊，你必須構建起一整套從線下到線上的新的能力體系來支撐這套新的架構。
啓示：很多團隊沒能構建起這套能力體系，直接在服務化的“反噬”下，倒在了路上，看不到服務化帶來的“曙光”。
思考：集羣環境中故障的定界定位：你如何快速定位問題出在哪？整個集羣的調用關係是什麼樣的，如何梳理？合理不合理？整個集羣的性能瓶頸在哪？這些都是運維要直面的問題。對研發來說，挑戰也不少。團隊被拆分了，團隊之間如何高效的協作？系統被拆分了，功能被分散到遠程節點，如何做調試？分佈式架構下的數據一致性如何保障？等等…
【關鍵詞：運維困局，開發困局】
分佈式事務
啓示：最終一致性的保障一定是“對賬、對賬、對賬”！這是最傳統，也是最可靠的最終防線，這也是金融公司的基礎能力。
三位一體服務治理
【管理-度量-管控】在這套體系中，針對服務的度量是進行服務管控和管理的前提和基礎，只有看得到，才能管得到，必須先解決“看”的問題，才能解決“管”的問題。
服務度量體系
全生命週期度量指標獲取
不管採用何種協作模式，都可以從其相關的過程管理系統中抽取出相關的過程指標事件，比如一個任務什麼時候完成設計、什麼時候開始進入開發、什麼時候完成開發…等等，這也是一大類很重要的治理度量指標。
【關鍵詞：持續交付，DevOps, 敏捷持續集成，線下+線上】
服務治理度量及分析體系
治理決策和管控指令就是微服務度量及分析體系的最終產出物。
服務線上治理
服務限流
構建服務限流能力的難點，一是標準化，二是體系化。
大公司往往就是依靠體系的力量去構建起護城河，從而去碾壓沒有體系能力的小公司。
啓示： 限流一大原則是限流動作儘量前置，畢竟被限制的流量註定要被“拋棄”，越早處理越好，免得無謂的消耗資源。
【關鍵詞： 單機限流，集羣限流，標準化，體系化】
集羣容錯
不管你決定使用哪種集羣容錯策略，一定要注意控制重試的次數，尤其是線上負載已經很高的時候，如果重試次數太多，一方面會推高服務被調用方的負載及併發，另外一方面會導致服務調用方的調用延時增長，雙重因素疊加之下，最終極可能導致“服務雪崩”、集羣被“擊穿”。
啓示：在使用集羣容錯的時候，一定要設置最大重試次數。
服務降級，熔斷
一般在線上動用服務降級手段時，都是線上比較危急的時候，生死存亡了，這時候留給你思考和反應的時間不多，所以在使用服務降級之前一定要做好預案，提前梳理出核心業務鏈路和非核心業務鏈路，然後通過降級開關一鍵把部分或所有非核心鏈路降級，這樣才能“救命”。
服務降級也有很多手段可以使用，包括：
- 容錯降級
- 靜態返回值降級
- Mock降級
- 備用服務降級
構建服務降級能力也和限流機制類似，同樣需要堅持標準化和體系化。
【關鍵詞：標準化，體系化，預案】
容量規劃
容量規劃有兩種形式：一種是容量預估，另一種是性能壓測。
- 全鏈路壓測的前提是單點壓測，需要先把單點壓測能力做好，才能做全鏈路壓測。
- 在壓測的時候，由於流量是模擬的，數據也是“僞造”的，所以一定要做好隔離，各種各樣的隔離，尤其是數據的隔離。
- 在線性能壓測是個“苦活”，需要提前發公告、全員戒備、時刻關注監控指標、有時候還要通宵搞，總結起來就是：智力密集型+勞動密集型+人肉密集型。
【關鍵詞：容量預估，依賴關係，數據準備，數據隔離，支持體系】
故障定界定位
分佈式環境下的故障定界定位，最有效的工具就是動態調用鏈路跟蹤。使用開源的Zipkin，SkyWalking、PinPoint、CAT，還是使用商用的聽雲、AppDynamic或NewRelic等等。
動態調用鏈要用的好一定是需要和監控大盤相結合：
- 我們有一個單位時間段內異常最多服務的TopN排序列表，點擊列表上的任何一個服務，會打開這個服務這個時間段內所有異常的列表，再點擊列表上的每一個異常，就會打開這個異常所屬調用鏈，進行故障分析。
- 可以利用監控大盤，監控大盤上有很多“毛刺”，這些都是系統的一些異常點，點擊任何一個“毛刺”，會將“毛刺”所在時間段內的請求以“散點”的形式列出（可能會基於請求數量做抽樣），“散點”的顏色代表了不同的狀態，有的成功，有的失敗。點擊任何一個“散點”，就可以進入這個請求對應的調用鏈。
- 針對核心服務的異常有專門的監控表格，會列出最近發生的核心鏈路服務上的異常，點擊這上面的任何一個異常，也可以進入對應的調用鏈。
【關鍵詞：可視化，局部和全局，2/8原則】
服務生命週期管理
目前使用螞蟻金融雲提供的SOFA分佈式服務框架，針對服務的線上生命週期管控的能力也是基於螞蟻金融雲的能力來構建的，螞蟻金融雲在它的雲上彈性計算資源的基礎上，通過整合資源編排及資源調度的能力，構建了微服務的綜合管控平臺。，通過這個平臺，可以比較方便的進行服務的上線、下線、擴容、縮容等操作。
服務整體架構治理
服務是分層的，好的服務調用關係一定也是分層的，層層往下推進，最終形成一個有向無環圖（DAG）。
- 對調用關係圖進行閉環檢測，如果檢測到如圖上G點到B點這樣的迴環調用的話，說明調用關係有問題，需要進行優化。這種迴環調用也許現在無感，但難保未來哪天就會由於一條旁路邏輯導致死循環。
- 從調用關係上來說，它是被依賴最多的節點，自然是最重要的節點，作爲樞紐節點，在運維等級上需要重點保障。當然，實際應用中，我們還會加上調用量這個權重來綜合判定服務節點的重要性。
- 可能有些服務節點再也不會有調用關係了，比如圖上綠色的L節點，這些節點再不會去調用別的服務節點，別的服務節點也不會來調用它。這類被找出來的“孤零零”的節點，可以考慮對它進行下線處理，以釋放資源。
研發協同治理
服務化背景下的團隊協同最佳實踐
- 在每期工作量評估時，一般會預留一些工作量buffer，以應對臨時性的需求，這類需求不受版本約束，按需發佈。如果這個迭代週期內沒有緊急需求，我們會從backlog中撈一些架構優化的需求來填補這些buffer。
- 爲什麼會持續有一些架構優化的活呢？因爲經常有一些緊急需求，使用正常開發方案可能無法如期上線，但業務又要的比較急，必須用一些應急性的臨時方案先上線使用。
協同度量及治理
每個迭代持續的進行精益看板的數據分析和度量，並通過治理策略進行不斷的改進優化，可以讓我們的研發協同越來越順暢。
【關鍵詞：精益看板，指標度量，持續優化】
開發治理
- 針對代碼質量的管理，常規的做法除了代碼的codereview外，一般還會使用Checkstyle，FindBugs，Jtest這類靜態代碼掃描工具來做代碼的缺陷掃描。
- 彙總個人的質量綜合評估報告，可以獲得針對團隊的開發質量綜合評估報告。這兩個報告本質上就是個人及團隊的研發質量“畫像”，完全可以作爲個人及團隊KPI考覈的重要參考。
測試質量治理
兩大核心訴求：一是提高測試的覆蓋度，具體說就是提高需求覆蓋度、代碼覆蓋度、頁面覆蓋度；二是降低測試用例的維護成本。
- 需求覆蓋度：可以通過服務這個維度來對需求及測試用例進行關聯，找出每個需求所對應的單元測試用例、自動化測試用例、手工測試用例，還可以把多個開發迭代週期的這些指標進行時間維度的縱比，以得出需求覆蓋度的變化趨勢。
- 代碼覆蓋度：有很多的工具幫我們來做，比如contest或者JaCoCo這類的工具，這裏不再贅述。
- 頁面覆蓋度：可以將每次集成測試中調用的頁面以日誌的形式記錄下來，再通過日誌的聚合分析，結合工程源碼的掃描，兩廂一比較，就可以統計出哪些頁面是沒有被覆蓋到的。
- 測試用例的維護成本分兩塊，一塊是新增用例的維護成本，這個比較好度量；比較麻煩的是存量測試用例的變更度度量，我們採用相似度匹配算法，先算出存量測試用例前後兩個版本代碼的相似度，再換算成變更度。
【關鍵詞：覆蓋度，用例維護成本】
分佈式調試能力構建
- 利用分佈式服務框架提供的過濾器機制，開發了一個Mock過濾器，通過Mock數據文件來詳細定義要被mock的服務的名稱、入參及出參。這樣，當請求過來時，將服務名及入參和mock數據中的定義進行比對，結果吻合，就直接將mock數據文件中的出參反序列化後作爲服務的調用結果直接返回，同時遠程調用的所有後續操作被終止。
- 基於服務框架的過濾器機制開發了“在線數據抓取過濾器”，它可以將指定的服務請求的入參和返回結果都抓取下來，直接寫成mock數據文件。通過抓取方式獲得的mock數據文件，往往有更好的數據質量，畢竟反映的是更加真實的業務場景。不過，這裏還有一個合規性的問題，一定要做好數據脫敏的處理工作。對於我們，目前只在測試環境中進行數據抓取操作。
- 綜合調測能力是綜合P2P直連和Mock兩種方式來共同構建的。在項目迭代的早期，前端團隊和服務端團隊，中臺開發團隊和後臺開發團隊會先定義接口，再基於接口直接生成mock文件，這樣大家就可以並行開發。開始時，服務都沒有開發出來，mock比例是最高的；隨着迭代的進行，服務被不斷開發出來，並部署到線上，這時，P2P直連調測的比例會上升，Mock的比例會下降；一直到集成測試時，只剩下P2P直連的模式，沒有mock了。
【關鍵詞：調試能力，Mock，綜合調試】