1. 首頁 > 生活百科 > >

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

小知識架構體系


“服務化”是實現“快”的一個非常重要的手段 。 把大量通用功能下沉為服務 ， 并對服務不斷進行拆分 ， 再根據不同的業務形態 ， 快速組裝出前端應用 ， 通過服務組裝和聚合的方式實現更快的開發速度 ， 前端也能變得更輕 。 把服務拆得越細 ， 服務的粒度越小 ， 可組裝性就越好 。 只有這樣 ， 我們才能在業務有需求的時候 ， 利用大量的“小服務”快速構建出一個前端業務應用 ， 支持業務的快速試錯 。
隨著近幾年容器技術的快速發展 ， 服務封裝及部署的成本越來越低 。 一方面 ， 服務被拆的越來越小 ， 成了“微服務” ， 另外一方面 ， 隨著業務的發展 ， 平臺規模越來越大 。 “大平臺、微服務”已經成了我們這個時代的一個典型技術特征 。 量變導致質變 ， 我們的開發模式、測試模式、運維模式都會受到沖擊 。
這就很有意思了 ， 業務的發展決定了我們一定會走上微服務之路 ， 根據康威定律 ， 我們的組織架構、管理策略、研發模式都要做出相應的調整 ， 才能保證微服務架構的平穩落地 。

這一階段的服務治理不再局限于線上的治理 ， 也要同步延伸到線下領域 ， 實現線上線下一體化及立體化的治理 。 面對越來越復雜的環境 ， 我們不僅要實現治理自動化 ， 更要實現治理智能化 ， 大量的算法被利用于服務質量及服務關系的洞察及服務管控上 ， 只有這樣 ， 才能應對層出不窮的新的問題 。

【微服務治理整體架構：三位一體的體系】這里直接給出微服務治理的整體架構圖 ， 微服務的治理既要進行線上的治理 ， 也要進行線下的治理 ， 通過線上線下兩大維度進行治理指標的采集 ， 并把它匯總到數據倉庫中 ， 進行統一的度量和分析 。
這些度量指標中 ， 有相當一部分線上的性能及異常指標會被轉化為運維事件 ， 一旦觸發我們預先設置的閾值 ， 就會被進一步轉化成“管控指令” ， 并通過調度中心下發 ， 進行服務的彈性伸縮、擴容縮容操作 ， 或者進行服務的限流、降級、容錯、路由調整等管控操作 。
另外一部分度量指標 ， 包括架構、開發、測試、運維、過程協作效率等指標會通過治理委員會（泛指 ， 治理成員的集合）進行人為的深入分析 ， 并制定出治理決策 ， 這些治理決策會通過相關的管理措施進行落地 。
這樣 ， 我們就通過服務的度量、管控、管理這三大舉措 ， 構建起一個三位一體、圍繞服務治理的閉環體系 。
從前面的介紹可以看到 ， 微服務治理體系中 ， 針對微服務的度量是進行微服務管理和管控的前提和基礎 ， “只有看得到 ， 才能管得到” ， 接下來 ， 我們就來重點介紹如何構建微服務的度量及分析體系 。
管理學大師彼得.德魯克說過“如果你不能度量它 ， 你就無法改進它” ， 強調的就是度量的重要性 。
【微服務全生命周期度量指標采集】
度量的第一步 ， 就是度量指標的采集 。
前面介紹了 ， 微服務的治理囊括了線上及線下體系 ， 同樣的 ， 服務治理度量指標的采集也要線上線下同步進行 。
在線上 ， 可以通過服務注冊中心獲取到服務的注冊信息及服務的管控指令信息 ， 通過各個微服務主機節點上的主機日志、應用及服務日志、APM監控的調用鏈日志 ， 可以獲取到相關的性能及異常指標信息 。
線下的指標就更多了 ， 通過需求管理系統 ， 可以采集到UserStory及各類需求的基本信息；通過項目管理系統可以采集到開發人員、開發團隊、開發任務的基礎信息；通過測試相關的管理系統可以采集到測試用例及測試bug的相關定義信息及過程指標信息；通過源碼倉庫及軟件版本倉庫可以采集到最終研發產出物的基本信息 。
軟件研發是一個強調協同的群體行為 ， 產品、開發、測試、運維需要緊密合作 。 為了達到更高效的配合 ， 我們經常會采用一些協作模式 ， 比如針對開發和測試之間的配合 ， 會采用持續集成（CI）；針對產品、開發、測試的協作 ， 會采用敏捷協作模式；另外 ， 我們可能還會使用一些DevOps的Pipeline 。 不管我們采用何種協作模式 ， 都可以從其相關的過程管理系統中抽取出相關的過程指標事件 ， 比如一個任務什么時候完成設計、什么時候開始進入開發、什么時候完成開發…等等 ， 這也是一大類很重要的治理度量指標 。
有了以上這些線上線下指標 ， 就可以將它們統一匯總到數據倉庫 ， 進行進一步的深度度量和分析 。
我們介紹的指標已經很多了 ， 也很全了 ， 但是不是有了這些就足夠了呢？總感覺還少了些什么…

推薦閱讀