1. 首頁 > 生活百科 > >

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

小知識架構體系

在QCon10周年的大會上 ， 我做了題為《微服務架構體系的深度治理》的分享 ， 現將PPT和演講文稿整理出來 ， 希望能夠給仍在（微）服務治理迷局中奪路狂奔的同學們一點啟發和指引 。
這次分享首先介紹了服務治理的發展歷史 ， 它的4個階段；接著重點介紹微服務度量及分析體系的構建；最后 ， 分別針對微服務線上及線下體系的治理進行深入探討 。
“治理”這個詞 ， 在漢語詞典中是“整治、修整”的意思 。 任何一個事物 ， 當它的復雜度達到一定程度時 ， 就可能出現問題 ， 我們需要對問題進行梳理、改進和優化 。 因此 ， 對事物的治理 ， 本質上是對事物復雜度的管理 。 同樣的 ， 服務治理就是對服務復雜度膨脹問題的管控及管理 。
【單體應用及其治理需求】在業務發展的早期 ， 我們也許用一臺機器就能扛住線上所有用戶的訪問 ， 所有的功能和模塊都被整合在一個單體應用中 ， 獨立部署 ， 這在企業應用中非常普遍 。 這個時期沒有什么“服務化”的概念 ， 也自然談不上服務治理 。 系統的復雜度更多來自于系統內部組件間相互調用及依賴關系 ， 很多企業都會維護一個龐大的組件庫 ， 力圖通過“搭積木”的方式來構建應用系統 。 由于組件之間存在版本和依賴性方面的問題 ， 所以需要進行組件治理 ， 這是單體應用治理方面的主要需求 。 我在從事企業級應用開發的時候 ， 做過一段時間組件治理 ， 組件庫的構建和維護比較復雜 ， 有一套自己的方法論體系 。
【企業級SOA及其治理】
隨著企業IT建設的不斷深入 ， 系統越建越多 ， 系統之間有了互聯互通及整合的需求 。 為了實現系統整合 ， 早期業界嘗試過很多技術 ， 一種是最簡單的點對點直連模式 ， 另一種是基于RMI、COBAR、DCOM這類中間件技術搞的星形連接模式 ， 但效果都不太好 ， 都沒辦法徹底解決標準化的問題 。
后來 ， IBM聯合一些大廠推出了面向服務的架構（SOA） ， 并制定了一系列的標準 。 SOA最核心的訴求就是構建一條企業服務總線（ESB） 。 通過SCA規范開發服務適配器 ， 將不同的異構系統接入服務總線 ， 通過SDO標準進行請求數據封裝 ， 服務之間通過WebService協議進行互相調用 ， 通過BPEL流程標準對服務進行流程化的編排 ， 創建出來的服務可以通過UDDI協議對外暴露 ， 以供第三方應用或服務調用 。 由于涉及的軟、硬件資源越來越多 ， “治理”的需求也就應運而生 。 事實上 ， 服務治理這個概念是隨著SOA技術的興起被同步提出來的 。
這個時期的服務治理規范基本上被IBM這些傳統IT大廠一手把持 ， 比如IBM的SOA Governance & Management Method(SGMM)標準 。 我們知道IBM做事有一個特點 ， 喜歡把簡單的事情復雜化 ， 它的這套SGMM標準全面覆蓋企業IT的管理流程、工具及基礎設施建設、甚至企業的組織架構 ， 定義了一堆的人員角色、規范、做事流程 ， 非常復雜 。 你得掏錢來讓他給你做咨詢才能把這套體系玩起來 ， 整個技術棧及流程太重了 ， 對人的要求也非常高 。 這嚴重制約了它的推廣和普及 ， 但它的一些思想還是很好的 ， 比如重視各個環節的指標采集和度量 ， 重視全生命周期的治理 ， 這些都可以給我們有益的啟發和參考 。
【互聯網服務化及其治理】
2010年之后 ， 伴隨著互聯網應用的大規模爆發 ， 又興起了一股由互聯網企業主導的所謂“輕量化SOA”的技術浪潮 ， 也就是我們常說的“分布式服務化”技術 。
這一階段 ， 服務化的目標不僅要解決系統間的整合問題 ， 還要解決系統的可伸縮性問題 。 大量互聯網公司開始對自己的系統進行“服務化”改造 ， 以期獲得橫向擴充的能力 ， 應對快速增長的業務和訪問量 。 這一時期使用的技術五花八門 ， 有使用代理網關模式 ， 也有采用RPC直連方式 ， 技術上沒有統一的標準 ， 也涌現出了像dubbo這樣的明星產品 。
這個時期的服務治理更多是聚焦在對服務的線上生命周期的管控及治理上 ， 包括服務的限流、降級、容錯 ， 以及服務的彈性伸縮、灰度發布等等 ， 線下的治理基本上不涉及 。
我們知道 ， 2C業務服務多、節點多 ， 由于涉及到大量的服務節點 ， 靠人肉的方式是肯定管不過來的 ， 因此這一時期的服務治理很強調自動化 ， 尤其是和自動化運維技術結合在一起 。
【微服務及其治理】互聯網發展到今天已經成了一種基礎資源 ， 越來越多的業務被搬到線上 ， 線上的競爭也越來越激烈 。 互聯網企業為了生存 ， 就要去競爭、去打仗 。 為了適應業務的快速發展 ， 在技術迭代上一定要“快” ， 所謂“天下武功、唯快不破” 。

推薦閱讀