微服務架構體系的深度治理什么是架構體系？( 六 )

2026-05-10 小知識架構體系

以上就是針對微服務線上體系的治理，實際上，這些能力都是微服務的通用能力，很多微服務框架都具備，我這里只是重點介紹了我們的使用經驗及心得。接下來我們來討論一些更加硬核一點的內容，來看看微服務的線下體系的治理。

【微服務整體架構治理】首先看一下針對微服務的整體架構的治理。
先看第一個圖，這個圖是線上微服務集群服務間的調用關系總圖，這個圖可以通過動態調用鏈的匯總來獲取，目前大部分公司都是這么干的；除此之外，還可以基于我前面介紹的靜態調用鏈（調用矩陣）來獲得，這個圖只是靜態調用矩陣的一個子集，通過靜態調用鏈獲取到的這個圖中的調用關系會比動態調用鏈更多，有了這個微服務間的整體調用關系之后，我們就可以對微服務的調用質量進行深入的分析。
服務是分層的，好的服務調用關系一定也是分層的，層層往下推進，最終形成一個有向無環圖（DAG）。因此，可以對調用關系圖進行閉環檢測，如果檢測到如圖上G點到B點這樣的回環調用的話，說明調用關系是有問題的，需要進行優化，這種回環調用也許現在無感，但難保未來哪天就會由于一條旁路邏輯導致死循環。
還可以對整個調用網絡進行遍歷計算，找出所有調用深度最深的調用鏈，如圖上紅色標注出來的調用鏈，我們知道，對跨網絡的調用訪問，涉及到的網絡節點越多，它的穩定性越差，可以將所有調用鏈路最深的這些鏈路找出來，并按調用深度進行topN排序，重點對排在頭部的這些調用鏈分析它的必要性及合理性，看是否可以對調用深度進行縮減和優化。
還可以找出整個網絡中被調用最多的這些服務節點，比如圖上的F節點，從調用關系上來說，它是被依賴最多的節點，自然是最重要的節點，作為樞紐節點，在運維等級上需要重點保障。當然，實際應用中，我們還會加上調用量這個權重來綜合判定服務節點的重要性。
隨著架構的不斷演講，可能有些服務節點再不會有調用關系了，比如圖上綠色的L節點，這些節點再不會去調用別的服務節點，別的服務節點也不會來調用它。這類被找出來的“孤零零”的節點，可以考慮對它進行下線處理，以釋放資源。
以上所有的度量和治理都是在這個調用關系圖的基礎上進行的，所用的算法也是圖計算（圖論）中的常用算法，包括BFS、DFS、PageRank等等，大家如果嫌麻煩，可以找個圖數據庫，比如neo4j ，這些算法已經集成在它的基本查詢能力中。
【單個微服務架構治理】微服務之所以被稱為“微” ，一方面是它承載的業務比較單一，另外一方面，它在架構上也要盡量的做到自洽和內斂，也就是說，它的設計要盡量的遵循“迪米特法則” ，要盡量少的和外部的系統或者服務發生交互。
可以通過調用鏈對微服務的對外調用關系進行梳理和分析，如果對外調用關系過多，比如說，如(頁面中)上圖所示，它如果調用了3個外部的系統或者服務，可能是正常的，但如果它對外調用了30個服務，那就要好好分析一下它承載的業務是否太多，是否不夠純粹，是否需要對它進行拆分，拆成多個服務。
另外，既然同時具有動態調用鏈和靜態調用鏈，完全可以將這兩種調用鏈進行疊加，如(頁面中)下圖所示，紅色部分是被動態調用鏈覆蓋到的邏輯，非紅色部分則是沒有被觸發的代碼調用邏輯，這部分未觸發邏輯中，有一部分是異常處理邏輯和旁路邏輯，可能是正常的，另外一部分則可能是版本兼容代碼。比如說，線上APP有很多的版本，某個版本一旦下線，后臺服務中針對此版本的兼容代碼就成了冗余代碼，需要進行清理。通過動態調用鏈和靜態調用鏈的疊加，就可以相對方便的定期找出冗余代碼進行清理，這樣可以保證微服務的體量不會膨脹。

【微服務開發質量度量及治理】
針對代碼質量的管理，常規的做法除了代碼的codereview外，一般還會使用Checkstyle ， FindBugs ， Jtest這類靜態代碼掃描工具來做代碼的缺陷掃描。其實我們還可以做的更深入和更廣一些，基于前面介紹的自定義代碼掃描的技術，結合代碼的調用關系，我們完全可以做到對跨類和跨方法的調用缺陷進行掃描，比如跨方法的多層循環嵌套，這類缺陷通過常規的代碼掃描工具是掃不出來的，
除了代碼質量之外，還可以結合線上bug的種類和數量，來綜合評估開發人員的開發質量，因為，代碼是人寫的， bug也是人制造出來的，通過結合開發人員開發的代碼的質量，及他的產出物產生的異常等級（類型及數量），就可以對開發人員的開發質量進行綜合的度量。當然，實際中還會結合其它的指標，但這兩個是最主要的指標之一。通過這兩個核心指標，可以生成研發人員開發質量綜合評估報告。

推薦閱讀

上一篇：關于運營的問題存在什么叫運營？

下一篇：建數據分析框架的3個步驟如何搭建數據分析框架？