今天談下微服務(wù)治理方面的內(nèi)容，對于微服務(wù)治理是整個企業(yè)微服務(wù)架構(gòu)轉(zhuǎn)型和微服務(wù)建設(shè)實施中一個關(guān)鍵內(nèi)容，很多企業(yè)在轉(zhuǎn)型過程中各自技術(shù)工具雖然采用了最新的微服務(wù)開發(fā)框架環(huán)境，治理平臺等，但是實際上微服務(wù)整個從需求，設(shè)計到上線運行全是一種混亂狀態(tài)，其中關(guān)鍵還是微服務(wù)治理出現(xiàn)了問題。

對于微服務(wù)治理，很多人一談這個這個最容易想到的就是類似SpringCLoud開發(fā)框架，類似Istio的微服務(wù)治理平臺，或者就是一堆的微服務(wù)標(biāo)準(zhǔn)規(guī)范，技術(shù)規(guī)范體系。實際上微服務(wù)治理的內(nèi)容卻是遠遠不止這么一點。

從IT治理和SOA治理談起

治理確定誰負責(zé)制定決策，需要制定什么決策，以及使決策制定保持一致的決策。治理不同于管理。治理規(guī)劃需要制定什么決策，而管理是制定和實施決策的過程。治理重在建立決策，而管理重在貫徹執(zhí)行決策。

IT治理

IT 治理是指針對 IT 的治理；即：針對 IT 組織及其人員、流程和信息應(yīng)用治理，以提供指導(dǎo)，使這些資產(chǎn)支持業(yè)務(wù)需求。IT治理是描述企業(yè)或政府是否采用有效的機制，使得IT的應(yīng)用能夠完成組織賦予它的使命，同時平衡信息化過程中的風(fēng)險，確保實現(xiàn)組織的戰(zhàn)略目標(biāo)的過程。

它的使命是：保持IT與業(yè)務(wù)目標(biāo)一致，推動業(yè)務(wù)發(fā)展，促使收益最大化，合理利用IT資源，適當(dāng)管理與IT相關(guān)的風(fēng)險。

下圖為山東省軟件評測中心總結(jié)的IT治理的總體框架，描述了IT治理的出發(fā)點、IT治理的關(guān)鍵要素、IT治理的對象、IT治理的最佳實踐。

IT治理的目的是使IT與組織業(yè)務(wù)有效融合，其出發(fā)點首先是組織的發(fā)展戰(zhàn)略，以組織發(fā)展戰(zhàn)略為起點，遵循組織的風(fēng)險與內(nèi)控體系，制定相應(yīng)的IT建設(shè)運行的管理機制。

IT治理的關(guān)鍵涵蓋IT組織、IT戰(zhàn)略、IT架構(gòu)、IT基礎(chǔ)設(shè)施、業(yè)務(wù)需求、IT投資、信息安全等，主要確定這些要素中“做什么決策？誰來決策？怎么來決策？如何監(jiān)督和評價決策？”。

整個IT建設(shè)生命周期都是IT治理的對象，包括IT組織與規(guī)劃、IT建設(shè)與交付、IT運行與維護、IT評估與優(yōu)化。IT治理的國際最佳實踐就是基于各個對象治理的成熟的方法論和工具，包括CobiT、ITIL、ISO27001、Prince2等。

對于Cobit是當(dāng)前采用的比較多的IT治理框架規(guī)范和企業(yè)IT治理水平評估標(biāo)準(zhǔn)。Cobit信息系統(tǒng)審計與控制協(xié)會在1996年公布，是在國際上公認的、權(quán)威的安全與信息技術(shù)管理和控制的標(biāo)準(zhǔn)，將IT過程，IT資源與企業(yè)的策略與目標(biāo)（準(zhǔn)則）聯(lián)系起來，形成一個三維的體系結(jié)構(gòu)。

在當(dāng)前Cobit5流程規(guī)范框架中，更加強調(diào)了企業(yè)組織，業(yè)務(wù)和技術(shù)之間的平衡，幫助企業(yè)更好的建設(shè)內(nèi)部IT創(chuàng)造更多的業(yè)務(wù)價值。Cobit5能夠為整個企業(yè)使IT在整體上得以治理和管理，并承擔(dān)整個端到端業(yè)務(wù)和IT功能區(qū)域的責(zé)任，同時兼顧內(nèi)外部利益相關(guān)者與IT相關(guān)的利益。

在以往的IT項目咨詢規(guī)劃中，我們基本也會借鑒Cobit標(biāo)準(zhǔn)框架來構(gòu)建企業(yè)內(nèi)部IT治理框架規(guī)范。

SOA治理

SOA 治理是 IT 治理的一種特殊化，其將關(guān)鍵 IT 治理決策置于服務(wù)組件、服務(wù)和業(yè)務(wù)流程的生命周期上下文中。SOA 治理對生命周期進行有效管理，生命周期是其關(guān)鍵目標(biāo)。SOA 治理重點關(guān)注服務(wù)生命周期的一些方面，例如：計劃、發(fā)布、發(fā)現(xiàn)、版本治理、管理和安全性。

對于SOA治理往往比IT治理更加重要，一個核心原因就是傳統(tǒng)的SOA架構(gòu)解決的是多個業(yè)務(wù)系統(tǒng)間的接口服務(wù)基礎(chǔ)和復(fù)用問題，往往涉及到多個開發(fā)商，多個業(yè)務(wù)部門，多個流程間的協(xié)同。這個更加需要制訂嚴格的標(biāo)準(zhǔn)規(guī)范去管理和執(zhí)行。

比如在SOA項目實施過程中，經(jīng)常聽到的接口管理混亂，接口實現(xiàn)標(biāo)準(zhǔn)不統(tǒng)一，接口版本混亂，接口無退出或下線機制，接口無法復(fù)用，無法分析某個接口究竟多少消費方在調(diào)用等都是屬于前期的SOA治理體系不完整導(dǎo)致。

對于SOA治理，IBM給出過一個完整生命周期，即：

IBM 的 SOA Governance and Management Method (SGMM) 是一個完整的流程，用于執(zhí)行 SOA 治理生命周期，將治理應(yīng)用于 SOA 生命周期。SGMM 包括四個階段：

• 計劃——確定治理的重點。
• 定義——定義 SOA 治理模型。
• 啟用——實現(xiàn) SOA 治理模型。
• 度量——改進 SOA 治理模型。

在該治理框架中核心還是圍繞服務(wù)全面生命周期管理，關(guān)鍵內(nèi)容包括：

• 服務(wù)定義（服務(wù)的范圍、接口和邊界）
• 服務(wù)部署生命周期（各個生命周期階段）
• 服務(wù)版本治理（包括兼容性）
• 服務(wù)遷移（啟用和退役）
• 服務(wù)注冊中心（依賴關(guān)系）
• 服務(wù)消息模型（規(guī)范數(shù)據(jù)模型）
• 服務(wù)監(jiān)視（進行問題確定）
• 服務(wù)所有權(quán)（企業(yè)組織）
• 服務(wù)測試（重復(fù)測試）
• 服務(wù)安全（包括可接受的保護范圍）

對于SOA治理本身，我實際上在前面很多文章都已經(jīng)談到過，應(yīng)該是包括了SOA建設(shè)前周期和SOA運維后周期兩個部分的內(nèi)容。前期覆蓋SOA實施全生命周期，后期覆蓋SOA運維監(jiān)控全流程。而從當(dāng)前主流的DevOps方法論來看，這兩個本身又應(yīng)該融為一體。

以下是我原來給出的一個SOA治理管控體系構(gòu)圖：

其中在縱向覆蓋了SOA從設(shè)計，開發(fā)，測試，部署，運維，監(jiān)控的全生命周期管理。同時在橫向又從業(yè)務(wù)，服務(wù)，支撐三個過程域進行展開。

即在有了SOA治理后，做任何一件事你都知道應(yīng)該遵循什么樣的規(guī)則來做，這是其一。其二在出現(xiàn)問題需要決策的時候，你都知道應(yīng)該遵循什么樣的決策流程來決策。在這里面一是涉及到業(yè)務(wù)系統(tǒng)，集成商，甲方信息化和業(yè)務(wù)部門組織；二是涉及到技術(shù)標(biāo)準(zhǔn)規(guī)范和流程，不僅僅是規(guī)范，同時包括了流程，例如服務(wù)接入流程，消費流程，接口問題的分析和解決流程等。

在整個SOA服務(wù)全生命周期管理中，你所有執(zhí)行的內(nèi)容都有章可循，這就是SOA治理。

SOA治理不僅僅是后期的服務(wù)運維和SLA管理等，同時也包括了前面談到的SOA從服務(wù)識別，定義，設(shè)計，開發(fā)，測試，部署上線的全生命周期管理規(guī)范和流程。而在SOA運維階段，談SOA治理的時候首先你要看到對于常規(guī)的IT治理和ITIL的內(nèi)容，SOA實施和建設(shè)也需要完全去遵守。

而這里面最重要的幾點拿出來說就是：

其一就是服務(wù)變更和版本管理，上線后的服務(wù)如何變更，服務(wù)變更如何進行影響分析，變更究竟是升級大版本還是升級小版本，包括服務(wù)進行版本升級后如何對老的業(yè)務(wù)系統(tǒng)進行版本兼容等，這些都必須提前制定規(guī)范和流程，同時制定變更分析方法。否則就會導(dǎo)致后續(xù)服務(wù)上線版本混亂，無法管理的局面。

其二就是服務(wù)SLA管理，服務(wù)的SLA等級如何進行制定，當(dāng)出現(xiàn)資源約束的時候如何根據(jù)服務(wù)優(yōu)先級進行服務(wù)流量控制，對于高SLA等級的服務(wù)如何來保證更高的服務(wù)運行高可用性，高性能和冗余等。SOA的服務(wù)監(jiān)控，服務(wù)告警如何與服務(wù)運行實例，服務(wù)SLA等級密切結(jié)合，這些也需要在前期制定規(guī)范和標(biāo)準(zhǔn)。好的SLA管理和監(jiān)控運維體系，核心目標(biāo)就是確保SOA平臺的高可用和高性能，確保在資源約束情況下高SLA等級服務(wù)的高可用性。

其三就是服務(wù)的狀態(tài)管理，這個也相對重要，服務(wù)如何從定義設(shè)計狀態(tài)到上線運行，對于上線運行的服務(wù)如何進行下線處理等，這些應(yīng)該遵循什么樣的原則，對于服務(wù)下線如何進行影響分析，遵循什么樣的下線流程，如何進行例行檢查以分析潛在可能下線的服務(wù)等，這些也必須提前約定并制定規(guī)范流程。

最后還有一點就是服務(wù)的安全管理，如何保證服務(wù)運行的安全，服務(wù)如何進行訪問授權(quán)，對于有特別要求的服務(wù)如何進行傳輸安全，數(shù)據(jù)安全控制，如何進行數(shù)據(jù)加密處理那么具體的加密和解密規(guī)則約定是如何的。對于接入的服務(wù)，在哪些場景下必須啟用哪些類別的安全控制。這些也屬于我們必須考慮的問題。

微服務(wù)治理概述

在談微服務(wù)治理的時候，首先還是需要重新回顧下微服務(wù)的概念。

微服務(wù)是指可以在“自己的程序”中運行，并通過“輕量級設(shè)備與HTTP型API進行溝通”。

其中關(guān)鍵在于該服務(wù)可以在自己的程序中運行。通過這一點我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨立進程所限制。如果其中任何一個服務(wù)需要增加某種功能，那么就必須縮小進程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進程。

注意，當(dāng)我們經(jīng)常談服務(wù)的時候，很容易直接想到的就是類似WS，Rest API等服務(wù)接口，因為在SOA架構(gòu)概念里面服務(wù)即特指這些服務(wù)接口。

而在微服務(wù)架構(gòu)下，特別要注意微服務(wù)不是簡單的Http Rest API接口。也就是說微服務(wù)本身包括了拆分后的微服務(wù)模塊，微服務(wù)模塊提供的API兩個部分內(nèi)容。

即微服務(wù) = 微服務(wù)模塊 + 微服務(wù)API接口

也正是這個原因，我們才看到微服務(wù)治理不能簡單地和SOA治理做等同。比如將微服務(wù)治理簡單理解為類似SOA架構(gòu)下的Http Rest API接口或RPC接口的管控治理。一個完整的微服務(wù)治理應(yīng)該同時包括了傳統(tǒng)的軟件開發(fā)全生命周期管理+接口服務(wù)全生命周期管理的內(nèi)容。

只是原來的軟件系統(tǒng)開發(fā)變成了一個個拆分后的微服務(wù)模塊開發(fā)。

微服務(wù)治理框架

對于微服務(wù)治理，如果我們用這個關(guān)鍵字進行搜索，搜索到的內(nèi)容主要包括兩個部分。

• 類似Springcloud，Istio，治理平臺等軟件框架平臺內(nèi)容
• 類似服務(wù)限流熔斷，服務(wù)鏈監(jiān)控，安全，日志，SLA管理等內(nèi)容

當(dāng)然這兩個部分內(nèi)容本身沒有錯。但是現(xiàn)在容易造成的誤解的就是將對微服務(wù)架構(gòu)平臺上線后的微服務(wù)運行管控，監(jiān)控分析理解為完整的微服務(wù)治理內(nèi)容。而實際上我們看到微服務(wù)治理的范疇遠遠超過這個理解。

也就是說軟件治理框架僅僅是工具或平臺，是執(zhí)行你制定的策略用地。那么治理本身的關(guān)鍵是制訂策略，而不是策略究竟是人來執(zhí)行，還是軟件工具平臺來執(zhí)行。

我們舉一個簡單的例子來說明下。

對于治理平臺提供了服務(wù)限流熔斷的功能，比如并發(fā)數(shù)大于1萬次就進行限流，我們也很容易將該規(guī)則配置到治理平臺。但是實際治理的關(guān)鍵是制定一個策略，即我們針對不同的業(yè)務(wù)場景，服務(wù)類型，服務(wù)SLA重要性要求，應(yīng)該如何去制訂合理的限流策略。

不清楚基于什么規(guī)則制訂策略，在平臺上胡亂配置，反而是起到副作用。

再比如你的治理平臺同時提供了服務(wù)集成，消息集成和大文件集成能力，這個是治理平臺本身的功能。但是針對不同的業(yè)務(wù)集成需求，如何制訂服務(wù)集成類型，這就是典型的服務(wù)治理要考慮的內(nèi)容。否則服務(wù)實現(xiàn)類型不對，服務(wù)定義顆粒度不對，都導(dǎo)致服務(wù)運行效率，質(zhì)量出問題。

這也正是前面強調(diào)的，管理治理工具平臺不難，難得是基于什么原則去管理。

微服務(wù)治理體系架構(gòu)和實踐

上面這本書是我最近購買和閱讀的一本書，差不多讀到了一半，很多地方有啟發(fā)，而且里面很多做法實際和我們實施SOA集成大項目中的，SOA治理管控做法一致。

對于這本書的內(nèi)容，我后面還會單獨整理筆記。

從這本書，可以看到作者對微服務(wù)治理的理解包括了度量，管控，管理幾個關(guān)鍵方面，并基于三位一體的思路實現(xiàn)一個微服務(wù)治理的閉環(huán)。

而里面涉及到的關(guān)鍵就是微服務(wù)度量體系的建設(shè)，服務(wù)監(jiān)控管理（限流，熔斷，降級，安全）和服務(wù)鏈監(jiān)控。其中服務(wù)度量涉及到服務(wù)開發(fā)，測試，運維，上線運行各階段的度量；對于服務(wù)管控本書也涉及到微服務(wù)全生命周期的管控。

在該書給出了微服務(wù)治理和微服務(wù)管理之間的關(guān)系如下:

從中可以看到度量在整個微服務(wù)治理中起到要給關(guān)鍵作用，即通過度量來實現(xiàn)整個治理和管理過程的閉環(huán)，其次是實現(xiàn)治理規(guī)范和準(zhǔn)則的持續(xù)優(yōu)化和改進。

網(wǎng)上有一篇文章大家可以參考：

http://www.uml.org.cn/wfw/201908013.asp?artid=22256

在該書里面給出了一個治理，管理，度量三位一體的微服務(wù)治理整體架構(gòu)。

從圖中可以看到，微服務(wù)的治理既要進行線上的治理，也要進行線下的治理，通過線上線下兩大維度進行治理指標(biāo)的采集，并把它匯總到數(shù)據(jù)倉庫中，進行統(tǒng)一的度量和分析。

這些度量指標(biāo)中，有相當(dāng)一部分線上的性能及異常指標(biāo)會被轉(zhuǎn)化為運維事件，一旦觸發(fā)我們預(yù)先設(shè)置的閾值，就會被進一步轉(zhuǎn)化成“管控指令”，并通過調(diào)度中心下發(fā)，進行服務(wù)的彈性伸縮、擴容縮容操作，或者進行服務(wù)的限流、降級、容錯、路由調(diào)整等管控操作。

另外一部分度量指標(biāo)，包括架構(gòu)、開發(fā)、測試、運維、過程協(xié)作效率等指標(biāo)會通過治理委員會（泛指，治理成員的集合）進行人為的深入分析，并制定出治理決策，這些治理決策會通過相關(guān)的管理措施進行落地。

重新思考微服務(wù)治理框架

基于前面內(nèi)容，這兩天重新思考了下微服務(wù)治理和治理框架。

對于微服務(wù)治理在前面已經(jīng)談到了實際上包括了微服務(wù)模塊本書和微服務(wù)API接口治理兩個方面的內(nèi)容，而不能簡單理解為API接口的治理。因此微服務(wù)治理應(yīng)該進一步融入IT治理和SOA治理兩個部分的內(nèi)容。

如果重新給微服務(wù)治理一個定義，應(yīng)該如下：

微服務(wù)治理是針對企業(yè)組織和業(yè)務(wù)目標(biāo)，制訂一套標(biāo)準(zhǔn)的管理，業(yè)務(wù)，技術(shù)，過程規(guī)范體系，實現(xiàn)微服務(wù)從需求，設(shè)計，開發(fā)上線，運行，下線的全生命周期管理能力。同時構(gòu)建一套完整的度量指標(biāo)體系，通過實時的日志和性能數(shù)據(jù)采集，持續(xù)的監(jiān)控服務(wù)運行監(jiān)控狀態(tài)，并執(zhí)行相應(yīng)的限流，預(yù)警等管控策略，以確保微服務(wù)的持續(xù)健康，可靠和高效運行。

基于這個，可以理解為整個治理框架應(yīng)該包括三方面內(nèi)容：

• 設(shè)計態(tài)：如何進行微服務(wù)分析和設(shè)計，模塊拆分，接口設(shè)計
• 運行態(tài)：如何構(gòu)建度量分析體系，實現(xiàn)微服務(wù)監(jiān)控，確保微服務(wù)健康運行
• 規(guī)范類：構(gòu)建一套完整的覆蓋管理，業(yè)務(wù)，技術(shù)，過程支撐的規(guī)范體系
• 工具類：基于上面治理要求，選擇可行的技術(shù)平臺或工具進行支撐

以上就是一個微服務(wù)治理本書應(yīng)該包括的全面內(nèi)容。從這個里面也可以看到微服務(wù)治理平臺或開發(fā)框架實際上僅僅占了微服務(wù)治理的一部分內(nèi)容，而不是全部。

微服務(wù)治理概括來說，實際上關(guān)鍵包括兩個部分。

即在微服務(wù)需求和設(shè)計期是如何進行微服務(wù)拆分，接口顆粒度設(shè)計；在運行期是如何基于度量體系進行監(jiān)控并形成閉環(huán)持續(xù)優(yōu)化改進。

基于以上思考，對微服務(wù)治理整體框架進行重構(gòu)如下：

該圖基本圍繞微服務(wù)全生命周期管理和基于服務(wù)度量體系的持續(xù)運維監(jiān)控兩個方面展開，對于一些二級的內(nèi)容在該圖暫時無法展開，比如常說的服務(wù)版本管理，服務(wù)依賴分析是微服務(wù)治理的要給關(guān)鍵內(nèi)容，暫時在該圖沒有體現(xiàn)。

在運行期還有一個關(guān)鍵思維的轉(zhuǎn)變就是不是簡單的發(fā)生問題故障后的運維治理，而是應(yīng)該基于監(jiān)控預(yù)警分析下的主動的技術(shù)運營和SLA服務(wù)等級提升。