1. 首頁 > 生活百科 > >

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

小知識架構體系



【通過代碼來“理解”代碼】不知道大家是如何使用你們的源代碼及源代碼倉庫的？做做codereview？或者用靜態代碼掃描工具掃掃代碼質量？其實 ， 我們完全可以做的更多 。
通過管理只能做到對過程的優化及規范化 ， 但你很難通過管理去提升軟件內在的架構設計質量及代碼質量 ， 因為它是和研發人員的能力及自我要求息息相關的 ， 并且需要進行長期的訓練 。
我之前在負責構建微服務治理體系的時候 ， 發現如果要對架構的質量及研發的質量進行深度的度量及治理的話 ， 是無論如何都繞不過源代碼的 ， 為什么這么說呢？軟件研發它是一項協作性的智力行為 ， 在研發過程中 ， 需求人員、設計人員、研發人員需要進行緊密的協同和配合 ， 這些人所有的思考、意圖、策略最終都會體現在代碼上 。 可以說 ， 一個系統的代碼就是一本“書” ， 你只要讀懂了這本“書” ， 你就知道這個系統的前世今生 。
但問題是 ， 你如何讀懂這本“書” ， 相信大家都對自己負責的系統的源代碼非常熟悉 ， 但是 ， 你們能否做到對你們整個服務集群中所有服務的源代碼都非常熟悉呢？這顯然不可能 ， 要讀懂這一堆的“書” ， 靠人力是顯然不行的 ， 我們需要借助一些自動化的手段 。
正是基于以上的思考 ， 我們開發了一套針對源碼倉庫中所有工程源碼進行統一掃描的工具 。 它的核心是eclipse中負責源碼解析的AST組件（Abstract Syntax Tree ， 中文為抽象語法樹） ， 通過AST ， 可以獲取到源碼工程中任何一個Java源碼文件中所調用的外部類、繼承或者實現的接口（父類）、類變量集合、類方法集合、方法邏輯塊（多層嵌套）、注釋等等基本信息 ， 有了這些基本信息之后 ， 通過對代碼的逐行掃描 ， 并基于一系列的正則及其它匹配 ， 就可以獲取到一個方法對其它方法的調用關系 ， 最終匯總之后 ， 就可以構建出一個跨工程、方法一級的非常龐大的調用關系矩陣 ， 微服務之間的調用關系則是這個調用矩陣的一個子集 。 這個調用關系矩陣和基于動態調用鏈路跟蹤所獲取到的調用鏈路非常類似 ， 我給它起了一個名字叫靜態調用鏈路 。 有了這個靜態調用鏈 ， 實際上 ， 我們就有了代碼內的邏輯關系 ， 在它基礎上 ， 就可以進行深度的架構關系及代碼質量的梳理 ， 這在后面的介紹中會有詳細的討論 。

【微服務度量及分析體系】有了以上所有這些度量指標 ， 包括前面重點介紹的代碼一級的靜態調用鏈路（矩陣） ， 就可以來看看最終針對微服務治理的度量及分析體系是個什么樣子 。
從下往上看 ， 首先通過各個指標來源渠道獲取到各類度量指標 ， 并把它們以ODS（操作型數據）的格式匯總到數據倉庫；通過數據模型抽取出主數據（MDM） ， 這些主數據包括了服務、需求、任務、人員、團隊等 ， 在此基礎上 ， 通過不同的數據主題（Topic）構建起一個多層的“數據集市” ， 這些數據主題包括了異常、性能、資源、調用關系、容量、系統、測試、開發、運維協同效率等；有了這個數據集市 ， 就可以在其基礎之上進行各類數據分析 ， 包括性能分析、容量分析、健康度分析、團隊及個人的質量報告、質量趨勢、動態調用鏈及靜態調用鏈的深度梳理、以及各維度的匯總報表 。
根據這些分析報告 ， 由治理委員會進行深度的分析并制定出各類的治理決策 ， 或者通過人為或自動化的機制發出各類管控指令 。
治理決策和管控指令就是微服務度量及分析體系的最終產出物 。
有了治理決策和管控指令 ， 就可以對微服務的線上及線下體系進行治理 ， 首先來看一下對線上體系如何進行治理 。
【服務限流】服務限流是微服務集群自我保護的一種常用機制 ， 我們對線上調用比較頻繁及資源占用較大的服務都加上了相應的限流舉措 ， 并構建了單機限流及集群限流兩套限流措施 。
首先來看一下單機限流 ， 它有多種限流算法可供選擇 ， 最主要的是兩種 ， 漏桶算法及令牌桶算法 。 它們之間有什么區別呢？打個比方 ， 比如有家酒吧已經客滿了 ， 保安開始限制客流 ， 一種舉措是酒吧中出來一個客人 ， 才放進去一個客人 ， 這樣就可以保證酒吧中的客人總數是固定的 ， 人人都有座位 ， 這就是漏桶算法---必須有出去的 ， 才能有進來的；另外一種舉措是不管有沒有客人出去 ， 保安固定每隔5分鐘就放一個客人進去 ， 這和春運火車站的波段式限流非常類似 ， 可以保證客流是比較均勻的 ， 但是這種策略也有一定的風險 ， 如果離開的客人不夠及時 ， 酒吧中的客人總數可能會升高 ， 導致一部分客人沒有座位 ， 這就是令牌桶算法 。 因此 ， 如果要對線上并發總數進行嚴格限定的話 ， 漏桶算法可能會更合適一些 ， 這是單機限流機制 。

推薦閱讀