轉載本文需註明出處：微信公眾號EAWorld，違者必究。

引言：

微服務等新技術在解決系統敏捷性的同時，也帶來了新的問題，眾多的服務被識別出來後需要有效的管理起來，內部系統與外部系統通過服務方式進行雙向整合，既有服務“引進來”，也有服務“走出去”。數量和種類繁多的服務如何管理？如何在複雜的微服務系統中實現問題快速定位與恢復？

從業界發展經驗和眾多實際案例來看，這一系列問題都需要建立企業服務治理體系來解決，通過服務治理體系支援金融行業基礎架構向微服務架構轉型。

目錄：

一、服務治理原則
二、服務治理體系
三、服務治理平臺

一、服務治理原則

組織：建立專業的人員保障



服務治理是諮詢+實施類專案，不僅僅是部署一套平臺工具。為了實現服務治理的效果，需要由專業的人員參與。各個角色的職能如下：

治理小組，推動和實施服務治理活動，確保管理體系和平臺工具的執行，監控服務介面的執行情況，評估服務治理的績效，保證服務治理最終實現業務目標和需求。
服務管理員，在服務治理系統中完成應用系統名稱的註冊和登出；完成對服務介面註冊申請審批、變更審批、登出審批，定期檢查和審計服務介面使用情況和狀態。
服務介面提供者的應用系統開發部，內部服務介面的提供方責任人，負責提供服務介面，保障服務介面執行穩定、可靠。
服務介面提供者的外部系統管理人，在業務支撐系統中有可能呼叫的外部服務，比如天氣預報、航班資訊等。
服務介面消費者的外部系統管理人，外部系統使用業務支撐系統開放出來的介面，比如：話費查詢、餘額查詢等。
服務介面消費者的應用系統開發部，業務支撐系統內部各個系統之間的呼叫通過整合平臺進行，服務消費者按照管理規範進行服務介面呼叫。

完善的管理流程和後面的幾個原則有一定的關聯性，比如流程的參與者是“專業的人員”、流程環節中的相關操作，需要由平臺和工具提供支撐。

技術：建立統一的技術標準

在“移動互聯”和“網際網路+”的時代，服務呼叫的次數更高，時間響應的要求更短。統一的技術標準可以減少開發時間，減少不必要的協議轉換、訊息轉換，提高響應速度，服務治理更關注於過程管理本身。

服務治理過程中統一技術標準的意義類似於古代“車同軌，書同文”。也就是服務呼叫過程中涉及到諸多技術標準：介面原則、編碼規範、服務規範等要統一，並且隨著技術和為了提高服務開發效率和響應速度，需要制定統一的技術標準，服務治理的重點從早期的協議轉換演進為服務管理。

平臺：以平臺支撐服務治理



企業數字化時代，產業鏈控制力空前強大，企業間協作越來越頻繁。服務治理的平臺工具必須能夠承受更大的壓力。

企業數字化轉型之後，系統間整合越來越多，服務治理平臺處於核心的樞紐位置，平臺的穩定性和效能是業務運營的基礎。

強大的平臺要求主要體現在：高效能、可靠性、擴充套件性等非功能性方面！

平臺工具：

設計期
登記平臺：負責微服務全生命週期管理，包括 域、業務系統、應用、微服務、微服務版本、API；
交付平臺：即DevOps，負責服務的開發、測試、構建、釋出等能力；
服務定義庫：負責存放服務定義資訊，包含已釋出和未釋出的各個版本的服務描述資訊；

執行期
註冊中心：負責應用例項和服務例項的元資訊管起來，並推送給消費者，定期從提供者更新配置；
配置中心：負責微服務配置管理，更新服務標識，調整服務配置，設定服務策略多層；
監控中心：執行期微服務監控、閘道器管理與監控、應用配置管理等;全面實現可管，可優；

系統：先解耦、再整合



現有大而全的系統猶如一張大網，錯綜複雜，系統邊界不清晰、系統部署架構和功能架構不清晰。牽一髮而動全身，專案改造難度極大、成本極高。

企業為了適應業務的發展，IT系統必須敏捷。敏捷的前提是對現有的“大餅”系統需要解耦，解耦之後業務系統由多個小系統組成，系統間邊界清晰、系統間互動明瞭。通過解耦減低了系統演進的複雜度、提高業務創新和業務融合的速度。

需要從三個方面解決問題：

解耦：將現有大而全的系統採用服務架構和標準化技術進行功能和部署的解耦；
整合：因為業務的關聯性，解耦伴隨著需要解決整合問題，通過引入工具對服務進行管控；
管控：通過在服務整合基礎之上建設服務治理平臺，實現服務的全生命週期管理，全面提升IT整合能力。

服務：自上而下和自下而上區分對待



在系統解耦和服務發現的過程中涉及到兩種服務梳理方法， “自上而下”和“自下而上”兩種方式各有利弊，專案實施時需要根據實際情況選擇合適的服務梳理方法。只有適合實際系統改造的方法才是最好的。

多維度的服務拆分：

業務限界上下文
業務變更頻率
系統非功能性需求
組織結構
團隊規模
技術異構和現有系統複雜度

流程：結合企業IT管理需求設定合適的管理流程



服務治理的過程很複雜，主要因為如下方面的原因：

首先，涉及到的人員多：服務提供方、服務消費者、服務管理員等角色；
然後，涉及到的環節多：服務定義、服務註冊與部署、服務執行監控、服務優化等環節；
最後，涉及到的流程多：服務註冊、服務登出、服務變更、服務呼叫等流程；

服務治理實現了服務的全生命週期管理，專案實施時需要根據企業管理要求制定出可落地、可執行的管理流程。清晰的定義出什麼人（組織），在什麼地方（平臺），做什麼事情（工具）。

流程管理可以是線下的，也可以藉助專業的BPM平臺實現。兩種方案實施的成本和週期差異較大，實施方案需要根據實際情況而定。

工具：完備的管理手段



平臺提供服務呼叫、單個服務註冊、批量服務註冊、報文審計、呼叫審計、TopN查詢、報文檢索、統計分析查詢等功能。

通過完備的管理工具實現對服務的全生命週期管理。

服務治理平臺首先滿足服務整合的功能，在服務治理過程中還需要提供靈活易用的工具，實現對服務的全生命週期管理。

審計：建立獨立第三方稽核



建立獨立第三方稽核的含義是：

服務治理涉及到服務管理的各個階段和眾多的參與者，為了檢查技術標準和管理流程的執行情況，在關鍵環節需要對服務消費者和服務提供者進行實施稽核的人員必須中立，能夠提供專業、公平、公正的審計報告，並指導各方持續改進。
服務治理專案團隊需要制定出符合企業IT架構發展的技術標準和管理流程，並能夠提供相應的管理工具對關鍵環節進行稽核，對標準和流程的執行情況能夠及時度量。
同時兼顧服務提供者和服務消費者，真正做到“標準可落地，流程可執行”，因此，服務治理專案建議由獨立的第三方組織實施。

服務治理專案實施成功的關鍵因素是專案團隊能夠保持中立的立場，提供公平、公正的稽核管理。

過程：持續化的服務管理



服務上線僅僅是服務生命週期管理的開始，業務的連續性需要IT系統提供長期的穩定執行，服務治理是一個持續的工作，服務治理的過程需要專職、專業的人員，採用完善的流程，利用豐富的工具，不間斷的檢查技術標準和管理過程的合規性。

二、服務治理體系

服務建模

服務建模是一個收集、分析、識別的過程。

Step1： 業務需求的收集和整理。
包含特定的場景、使用者群、業務目標等硬性指標，還可以包含如使用者體驗、較之競爭對手的一些特色等的軟性指標。

Step2：業務分析。
視覺化業務建模。與業務領域專家一起使用通用語言文件化整個業務過程。

Step3：識別候選業務過程需要的所有服務。
這些服務有些是新實現的，有些是已有的。有些可能是在微服務架構體系下通過API 閘道器呼叫實現的，有些可能是通過ESB呼叫實現的。包含：
原子的（單步的）；
組合好的（多步的，操作類流程，有無工作流皆可）
已有的虛擬服務流程（如：承保、核保、風險指標或登記的計算）
基礎設施（如：郵件通知、簡訊通知、在系統中生成一條代辦事項）

Step4：對上一步識別的服務所使用的物件確定並可視化其狀態和行為。

Step5：服務識別過程成果基於服務模型等規範的落地實現
服務識別成果與對於服務模型、元資料的對應歸納、分類和具體實現設計、編碼、複用等工作

Step6：服務的釋出
服務在開發、 測試、生產環境中的部署、除錯和上線

Step7：服務在執行態的監控、發現與治理

元資料模型

元資料模型分為靜態和執行態兩類

元資料模型-靜態



靜態包含：按層級劃分為：平臺定義、系統定義、應用定義和服務定義。根據業務變化，可以在對應分類中，擴充屬性。

元資料模型-執行態



執行態模型包含：應用例項、服務例項及服務流水。

模型之間的關係



我們看一下各模型之間的對應關係，首先從組織層面的隸屬關係來看，一個部門可以負責多個平臺，一個部門下的一個團隊可以負責一個或多個系統，一個團隊下的一個小組或個人可以負責一個應用和多個負責。

一個平臺包含多個系統，一個系統包含多個應用，一個應用包含多個服務。應用例項是從應用定義物件的例項化。服務例項是從服務定義物件的例項化。

一個應用例項，通常會支撐提供多個服務例項。服務之間的呼叫，產生服務流水。



模型按照“平臺-系統-應用-服務”這樣的層級建立關係。

依賴關係的梳理



依賴關係有歸屬關係、記錄依賴關係和呼叫依賴關係。

服務生命週期資料流和控制流



在控制流的干預下，資料流在不同的時點上呈現出不同的變化，例如嬰兒只有姓名標籤，沒有學號標籤，等他上學了才有學號。

服務生命週期中的服務治理模型的標籤亦是如此，會隨著所處的服務生命週期發生一些變化。

服務生命週期資料流



服務的生命週期我們定義為規劃、設計/開發、測試、執行是個階段，資料流的規範是指各類物件屬性在生命週期各階段中，哪些被賦值和初始化，哪些值會有更新。就像上面提到的人的一生的標籤。

在規劃階段根據業務需求，平臺、系統、應用和服務都將對劃分、歸口、相關定義類的資料進行初始化，對於平臺和系統，生命週期和分散式架構相關屬性也會有值。

在設計/開發階段，系統、應用和服務將被具體實現，所以這三類的幾乎所有屬性都將被初始化。
在測試階段，應用和服務將被例項化，例項將從定義物件中繼承大部分屬性，並且動態更新自己的執行態屬性。
在執行階段，應用和服務例項只是換到了生產環境執行，同樣例項將從定義物件中繼承大部分屬性，並且動態更新自己的執行態屬性。

服務生命週期控制流規範



服務在整個生命週期，它的生成、互動、變更、銷燬都會對周邊的系統、應用、服務造成影響，那如何來評估和控制影響帶來的成本壓力和風險，這需要我們在關鍵點上加必要的控制點，這就形成了我們的控制流規範。在規範中，控制點分為兩類：建議的必要流程和參考流程。必要流程即為必選，參考流程可以根據組織自身情況來選用，達成風險控制與效率的平衡。

控制流的抽象模型-RACI

RACI，是在流程應用中抽象出的業務模式，是用來明確組織過程中各個角色及其相關責任的方法，其中：

誰負責（R = Responsible）,即負責執行任務的角色，他/她具體負責操控專案、解決問題
誰批准（A = Accountable）,即對任務負全責的角色，只有經他/她同意或簽署之後，專案才能得以進行
諮詢誰（C = Consulted）,擁有完成專案所需的資訊或能力的人員
通知誰 (I =Informed),即擁有特權、應及時被通知結果的人員，卻不必向他/她諮詢、徵求意見

我們對於控制流的表述，是通過RACI的模型來進行的，簡單來說，就是針對這條流程誰來負責、需要誰批准，有問題可以諮詢誰，流程到達特定環節需要通知誰。

角色定義

服務開發團隊：負責需求分析，服務的設計、開發、測試、部署、運維等具體工作的角色團隊；

架構管理團隊：是關於系統、服務、業務以及IT相關事項的最終決策者。負責審批微服務體系戰略方向/架構、資源、成本等的管控/服務治理原則的把控等管理職能；

生產運維部：負責生產環境的部署、變更、運維、安全風險評估等工作的角色團隊；

風險管理委員會：負責重要業務系統的業務相關風險評估；

業務管理團隊：是關於業務需求提出、服務資金、激勵分配相關事項的最終決策者。 

服務新增審批流程



服務新增審批流程，由服務開發團隊提出申請，經架構團隊稽核批准，審批通過後錄入服務治理平臺。

輸入為業務流程分析的相關成果，服務識別相關成果，治理平臺中註冊的已有服務。

主要活動，評估是否有必要新增服務，並評估新增服務帶來的人員、資源等成本壓力。

輸出為：新增服務的相關屬性定義到治理平臺。

服務變更審批流程



服務變更審批流程，由服務開發團隊提出申請，經架構團隊稽核批准，審批通過後錄入服務治理平臺。

輸入為業務流程分析的相關成果，服務識別相關成果，治理平臺中註冊的已有服務，以及服務之間的依賴管理。

主要活動，評估是否有必要變更服務API，是否有必要進行服務的重構，評估變更和重構帶來的人員、資源等成本壓力。

輸出為：新增服務的相關屬性定義到治理平臺。

服務呼叫審批流程



服務呼叫審批流程，由服務開發團隊提出申請，經架構團隊稽核批准，審批通過後錄入服務治理平臺。

輸入為業務流程分析的相關成果，服務識別相關成果，治理平臺中註冊的已有服務。

主要活動，評估是否有必要跨系統進行服務呼叫，評估變更和重構帶來的人員、資源等成本壓力。

輸出為：新增服務的相關屬性定義到治理平臺。

服務上線審批流程



服務上線審批流程，由服務開發團隊提出申請，如系統等級為A、B則由風險管理委員會審批，其它等級經生產運維部稽核批准，審批通過後錄入服務治理平臺。

輸入為服務生成過程中的相關成果。

主要活動，評估是否具備上線條件。

輸出為：新增服務的相關屬性定義到治理平臺。

服務銷燬審批流程



服務銷燬審批流程，由服務開發團隊提出申請，經架構團隊審批，審批通過後錄入服務治理平臺。

輸入為服務間依賴、服務例項執行態的資料以及服務流水資料。

主要活動，評估是否具備銷燬的條件，以及銷燬帶來的人員和資源成本壓力。

輸出為：新增服務的相關屬性定義到治理平臺。

服務治理平臺與其他系統的關係



這個關係的梳理也是按生命週期這個維度來做的。

三、服務治理平臺演進

服務治理平臺演進階段劃分



我們參考CMMI能力成熟度模型來劃分服務治理平臺的演進階段。

定義階段



定義階段主要打通閘道器，收集建立基本的服務治理模型資料。

量化階段



量化階段全面打通各個應用系統，全面收集度量資料進行統計分析。

優化階段



優化階段通過分析度量資料持續優化服務治理平臺。

服務治理平臺架構藍圖規劃



服務治理平臺按照前面劃分的三個階段逐漸建立和完善。

關於作者：黃豆，數字化金融研究院研究員，擅長系統分析和架構設計、金融三級金鑰安全體系及資訊保安保障、虛擬化和雲端計算技術、JavaEE技術；參與研發的神州商橋電子商務平臺獲得“全國電子商務示範單位”稱號；帶領團隊研發的國電通雲終端系統在國網多個省公司推廣應用。


關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。長