一文了解金融行業服務治理

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

引言：

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

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

目錄：

1、服務治理原則
2、服務治理體系
3、服務治理平臺

1、服務治理原則

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



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

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

完善的管理流程和後面的幾個原則有必定的關聯性，好比流程的參與者是「專業的人員」、流程環節中的相關操做，須要由平臺和工具提供支撐。

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



在「移動互聯」和「互聯網+」的時代，服務調用的次數更高，時間響應的要求更短。統一的技術標準能夠減小開發時間，減小沒必要要的協議轉換、消息轉換，提升響應速度，服務治理更關注於過程管理自己。

服務治理過程當中統一技術標準的意義相似於古代「車同軌，書同文」。也就是服務調用過程當中涉及到諸多技術標準：接口原則、編碼規範、服務規範等要統一，而且隨着技術和爲了提升服務開發效率和響應速度，須要制定統一的技術標準，服務治理的重點從早期的協議轉換演進爲服務管理。

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



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

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

強大的平臺要求主要體如今：高性能、可靠性、擴展性等非功能性方面！

平臺工具：

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

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

系統：先解耦、再整合



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

企業爲了適應業務的發展，IT系統必須敏捷。敏捷的前提是對現有的「大餅」系統須要解耦，解耦以後業務系統由多個小系統組成，系統間邊界清晰、系統間交互明瞭。經過解耦減低了系統演進的複雜度、提升業務創新和業務融合的速度。

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

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

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



在系統解耦和服務發現的過程當中涉及到兩種服務梳理方法， 「自上而下」和「自下而上」兩種方式各有利弊，項目實施時須要根據實際狀況選擇合適的服務梳理方法。只有適合實際系統改造的方法纔是最好的。

多維度的服務拆分：

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

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



服務治理的過程很複雜，主要由於以下方面的緣由：

首先，涉及到的人員多：服務提供方、服務消費者、服務管理員等角色；
而後，涉及到的環節多：服務定義、服務註冊與部署、服務運行監控、服務優化等環節；
最後，涉及到的流程多：服務註冊、服務註銷、服務變動、服務調用等流程；

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

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

工具：完備的管理手段



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

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

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

審計：創建獨立第三方稽覈



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

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

服務治理項目實施成功的關鍵因素是項目團隊可以保持中立的立場，提供公平、公正的稽覈管理。

過程：持續化的服務管理



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

2、服務治理體系

服務建模

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

Step1： 業務需求的收集和整理。
包含特定的場景、用戶羣、業務目標等硬性指標，還能夠包含如用戶體驗、較之競爭對手的一些特點等的軟性指標。

Step2：業務分析。
可視化業務建模。與業務領域專家一塊兒使用通用語言文檔化整個業務過程。

Step3：識別候選業務過程須要的全部服務。
這些服務有些是新實現的，有些是已有的。有些多是在微服務架構體系下經過API 網關調用實現的，有些多是經過ESB調用實現的。包含：
原子的（單步的）；
組合好的（多步的，操做類流程，有無工做流皆可）
已有的虛擬服務流程（如：承保、覈保、風險指標或登記的計算）
基礎設施（如：郵件通知、短信通知、在系統中生成一條代辦事項）

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

Step5：服務識別過程成果基於服務模型等規範的落地實現
服務識別成果與對於服務模型、元數據的對應概括、分類和具體實現設計、編碼、複用等工做

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

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

元數據模型

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

元數據模型-靜態



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

元數據模型-運行態



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

模型之間的關係



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

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

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



模型按照「平臺-系統-應用-服務」這樣的層級創建關係。

依賴關係的梳理



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

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



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

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

服務生命週期數據流



服務的生命週期咱們定義爲規劃、設計/開發、測試、運行是個階段，數據流的規範是指各種對象屬性在生命週期各階段中，哪些被賦值和初始化，哪些值會有更新。就像上面提到的人的一輩子的標籤。

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

在設計/開發階段，系統、應用和服務將被具體實現，因此這三類的幾乎全部屬性都將被初始化。
在測試階段，應用和服務將被實例化，實例將從定義對象中繼承大部分屬性，而且動態更新本身的運行態屬性。
在運行階段，應用和服務實例只是換到了生產環境運行，一樣實例將從定義對象中繼承大部分屬性，而且動態更新本身的運行態屬性。

服務生命週期控制流規範



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

控制流的抽象模型-RACI

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

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

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

角色定義

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

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

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

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

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

服務新增審批流程



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

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

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

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

服務變動審批流程



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

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

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

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

服務調用審批流程



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

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

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

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

服務上線審批流程



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

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

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

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

服務銷燬審批流程



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

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

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

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

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



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

3、服務治理平臺演進

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



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

定義階段



定義階段主要打通網關，收集創建基本的服務治理模型數據。

量化階段



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

優化階段



優化階段經過分析度量數據持續優化服務治理平臺。

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



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

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


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！