二、服務治理體系

服務建模

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

Step1：業務需求的收集和整理。

包含特定的場景、用戶群、業務目標等硬性指標，還可以包含如用戶體驗、較之競爭對手的一些特色等的軟性指標。

Step2：業務分析。

可視化業務建模。與業務領域專家一起使用通用語言文檔化整個業務過程。

Step3：識別候選業務過程需要的所有服務。

這些服務有些是新實現的，有些是已有的。有些可能是在微服務架構體系下通過API網關調用實現的，有些可能是通過ESB調用實現的。包含：

a. 原子的（單步的）；

b. 組合好的（多步的，操作類流程，有無工作流皆可）

c. 已有的虛擬服務流程（如：承保、核保、風險指標或登記的計算）

d. 基礎設施（如：郵件通知、短信通知、在系統中生成一條代辦事項）

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

Step5：服務識別過程成果基于服務模型等規范的落地實現

服務識別成果與對于服務模型、元數據的對應歸納、分類和具體實現設計、編碼、復用等工作

Step6：服務的發布

服務在開發、測試、生產環境中的部署、調試和上線

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

元數據模型

元數據模型分為靜態和運行態兩類

元數據模型－靜態

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

元數據模型－運行態

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

模型之間的關系

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

一個平臺包含多個系統，一個系統包含多個應用，一個應用包含多個服務。應用實例是應用定義對象的實例化。服務實例是服務定義對象的實例化。

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

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

依賴關系的梳理

依賴關系有歸屬關系、記錄依賴關系和調用依賴關系。

服務生命周期數據流和控制流

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

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

服務生命周期數據流

服務的生命周期我們定義為規劃、設計／開發、測試、運行四個階段，數據流的規范是指各類對象屬性在生命周期各階段中，哪些被賦值和初始化，哪些值會有更新。就像上面提到的人的一生的標簽。

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

2. 在設計／開發階段，系統、應用和服務將被具體實現，所以這三類的幾乎所有屬性都將被初始化。

3. 在測試階段，應用和服務將被實例化，實例將從定義對象中繼承大部分屬性，并且動態更新自己的運行態屬性。

4. 在運行階段，應用和服務實例只是換到了生產環境運行，同樣實例將從定義對象中繼承大部分屬性，并且動態更新自己的運行態屬性。

服務生命周期控制流規范

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

控制流的抽象模型-RACI

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

? 誰負責（R=Responsible），即負責執行任務的角色，他／她具體負責操控項目、解決問題

? 誰批準（A=Accountable），即對任務負全責的角色，只有經他／她同意或簽署之后，項目才能得以進行

? 咨詢誰（C=Consulted），擁有完成項目所需的信息或能力的人員

? 通知誰（I=Informed），即應及時被通知結果的人員，卻不必向他／她咨詢、征求意見

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

角色定義

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

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

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

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

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

服務新增審批流程

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

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

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

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

服務變更審批流程

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

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

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

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

服務調用審批流程

服務調用審批流程，由服務開發團隊提出申請，經架構團隊審核批準，審批通過后錄入服務治理平臺。

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

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

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

服務上線審批流程

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

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

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

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

服務銷毀審批流程

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

輸入為服務間依賴、服務實例運行態的數據以及服務流水數據。

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

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

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

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