【51CTO.com快譯】

引言

從管理學上說，治理的定義是：“將人員、流程和技術聯系起來，為利益相關者創造價值。”如下圖所示，IT治理的流程會與企業IT生態系統中的三個主要部分持續進行交互。

IT治理的組成

人員

這包括具有各種技能的角色，如：開發人員、架構師、業務分析師、CXO、以及參與IT服務交付過程的利益相關者。從需求識別到通過IT生態系統最終交付業務功能，這些不同的角色都會與基礎流程及技術進行交互，并通過不同的權限集，來實現治理模型，進而維持穩定性、完整性和問責制。

流程

流程包括策略、標準、最佳實踐、以及角色管理等。在利用技術來交付IT服務時，人員必須遵守各種流程。在微服務的語境中，流程是以單個團隊為中心，通過集中式控制平臺來進行控制的。

技術

主要涉及到開發、測試、部署和交付服務等實際工作。人員使用技術組件，在流程的管理下，為關鍵利益相關者帶來價值。

可見，適當的治理模型就是要：通過問責制和透明性，向利益相關者(如：消費者、合作伙伴)交付價值。如果我們分析大多數失敗的IT項目，就會發現：其中最常見的失敗原因之一便是缺乏治理。

微服務與治理

從概念上說，微服務架構是指：由團隊獨立開發、部署和管理的軟件開發實踐。此類服務具有獨立性，并且能夠滿足特定的業務目的。而微服務治理則是一個過程。它可以幫助人員管理微服務的開發，并將關鍵性成果交付給業務方。也就是說，它可以幫助企業通過既定的策略和標準，使其業務目標與微服務計劃保持一致。

人們往往錯誤地認為：讓微服務開發團隊遵守各種流程和策略，可能會阻礙整體的創新和交付速度。但實際上，它是通過集中式控制平臺的分布式治理，引入適當的流程順序。而且，當組織規模不斷壯大，并且需要交付100多種不同的微服務時，流程和策略的作用就更加顯著了。

微服務治理和業務目標

上圖展示了微服務團隊、治理和業務需求三者的關鍵特征，以及在為微服務構建治理框架時的相互聯系。

微服務團隊

微服務架構允許團隊在開發和交付服務時擁有自主權。他們可以選擇自己的運行時、語言、工具和流程。不過，我們在確定服務需求的過程中，需要分拆現有的團隊，以便他們能夠獨立工作。同時，這也是微服務治理的起點。通過團隊的拆分，業務分析師、架構師和一些開發人員將會組成集中式的管理團隊。

圖片來源：https://medium.com/ibm-garage/microservices-technical-governance-f5aed10189d1

一旦確立了微服務團隊，并提交了要實施的規范，他們就需要準備合適的工具、流程和技術，以滿足預期的交付結果。而且，這些都需要與總體業務目標保持一致。

業務目標

微服務團隊與治理控制平臺的交互

不同的業務往往有著不同的目標，其中包括：企業愿景、上市時間(交付速度)、投資回報、總體擁有成本等方面。如上圖所示，假設我們的企業在不同時間擁有四個不同的微服務團隊，他們提供著不同類型的服務，并通過與治理控制平臺的交互，確保其行為符合業務的標準和需求。也就是說，他們在開發各種服務功能時，可以根據最高質量服務的需要，針對如下方面采用不同的方法，來執行各種任務。

• 編程語言/運行時。
• 發布策略。
• 交付生命周期。
• 源代碼管理工具。
• 團隊成員數。
• 服務類別。

他們在與治理控制平臺的交互過程中，持續驗證方法的有效性，并通過記錄以備將來的參考，進而在組織內廣泛共享。

同時，治理控制平臺需要通過公開API，提供用戶界面，實現對如下方面的治理：

• 生命周期管理 — 每個團隊可以有自己的不同生命周期階段(stages)、過渡(transitions)、以及各自的角色。這些細節將通過治理控制平臺被捕獲和治理。同時，此類交互既可以是手動的，也可以通過治理層所公開的API來實現。
• 服務存儲庫和可重用性 — 當團隊使用基于域的設計，來開發新的微服務時，需要仔細研究現有的微服務集，以避免在功能上的重疊，以及重復分配資源。治理層的服務存儲庫可以實現可重用性，并提高系統的整體效率。
• 標準/政策 - 盡管每個團隊都可以決定技術、發布模型、生命周期，但是我們應當采用一種通用的機制，來通過標準和政策，去定義開發過程的各個方面。例如：如果需要在組織級別上獲得諸如HIPPA、FEDRAMP之類的認證，那么所有不同的團隊都必須遵守該標準。
• 最佳實踐 - 在生命周期中，團隊有責任根據自己的技術選擇，在治理級別上發布這些最佳實踐，以切合業務目標。
• 依賴關系分析 — 隨著業務的持續蓬勃發展，企業會將越來越多的微服務添加到其生態系統中。在此，依賴關系分析可以幫助我們可視化各種資產類型之間的復雜依賴關系，其中包括：微服務團隊、服務URL、角色、以及其他資源等。
• 監控/審計 — 微服務團隊需要通過治理平臺的審核和監控機制，來對失敗的項目進行回顧，進而從錯誤中總結學習。

微服務治理的兩種生命周期

上圖是常見的兩種生命周期。左側常被用于將一個想法轉化為概念，然后從一個微服務團隊中分離出來，將其作為新的服務予以開發，并最終交付給使用者(consumer)。該生命周期可以用來證明微服務團隊的某個想法的可行性和價值，以便團隊無論使用何種技術，都能拿去重用。

右側是一個典型的軟件生命周期，其中涉及到：設計、實施、測試階段、以及外部使用者能夠訪問到的開發者門戶(作為托管API進行部署和發布)。據此，微服務團隊可以實現CI/CD管道，并自動遍歷整個生命周期。通過API與治理平臺的集成，微服務能夠確保在進入生產環境之前，及時跟蹤每個發行版，并實時傳遞各種所需的管理要求。

不同的團隊也許會在其開發生命周期中表現出不同的特征與階段。但是，憑借著集中式控制平臺，架構師可以持續比較不同的生命周期，并根據每個團隊的經驗，提出相應的改進建議。

微服務治理的參考架構

有了前面的基礎知識，下面我們來討論微服務治理的參考架構。

微服務治理的參考架構

技術組成

在上圖中，上半部分是一個生產環境，其中部署了具有多個副本的各種微服務。為了簡單起見，上圖省略了諸如：安全令牌、服務網格、消息代理等組件。圖中也展示了一個“歷史遺留”服務，這往往是企業架構中不容忽視的部分。圖中下半部分則展示了微服務在開發和測試階段、以及運行時，所使用到的各種基礎技術組件。在治理過程中，我們往往需要在“信任但驗證(trust but verify)”模型中管理各種技術組件。

人員

上圖也展示了人員在基于微服務的開發過程中，所扮演的具有不同權限的不同角色。例如：開發人員需要獲得測試人員的批準，方可將其代碼移至生產環境。因此，從最初的設計階段，到最終的退役階段，各個團隊成員需持續與治理平臺進行交互，以提供與業務目標相一致的服務，并給用戶提供最佳體驗。

存儲與編錄

一個具有多層架構的典型企業部署往往包含：后端、中間件、API、以及前端等不同類型的服務。通常，開發者門戶只能將API的詳細信息提供給使用者，卻無法存儲其他類型的服務。治理平臺的主要功能就是將諸如：搜索、瀏覽、發現、分類、依賴關系分析之類的功能與服務，予以保存并實現復用。

服務發現

運行時的服務發現是基于微服務的自包含(self-contained)與面向服務(service-oriented)的多層架構模型中的重要部分。我們在不同的環境中，部署不同的功能服務時，往往需要更改服務的實際URL。因此，我們可以使用通用參考作為“鍵(key)”，通過服務發現功能，將其映射為“值(value)”，進而降低環境中服務管理的復雜性。

通過API進行交互

一些團隊可能會更喜歡通過編程的方式，去訪問治理的相關功能，以便自行構建自動化的管道和交付服務。對此，治理平臺需要通過預定義API的方式，來公開各種必需的功能，以便團隊使用基于客戶端能力的OAuth2、或基本的身份驗證機制，實現與平臺之間的安全交互。

通過WSO2來實施微服務治理

下面，我們來看看如何使用開源軟件棧--WSO2，讓前面討論的治理架構能夠憑借軟件工具實現“落地”。

通過WSO2來實施微服務治理

如上圖所示，我們可以使用多種技術來實現不同領域的微服務，其中包括：

• 前端應用程序 – Javascript、React、Angular
• API網關 — WSO2 API Manager、Microgateway
• 集成服務 — WSO2 Enterprise Integrator、Micro Integrator
• 后端業務服務 - Spring Boot、Golang、.Net
• API開發者門戶 — WSO2 API Manager開發者門戶

此外，前文提到了一些可能無法用微服務代替的“歷史遺留服務”(如：SOAP、XML、SAP、FIX、JMS等)，我們可以利用如下基礎工具和技術，與整個生態系統相集成，并為最終用戶提供價值。

• 基礎架構 – AWS、Azure、VM或物理硬件
• 容器運行時 – Docker、rkt
• 語言運行時 — JDK、.Net框架、Node
• 持續集成工具 – Jenkins、TravisCI，、CircleCI
• 源代碼管理工具 – GitHub、GitLab
• 測試自動化工具 – Selenium、Newman、SOAPUI
• 設計/實施工具 – IDE、VSCode

下面，我們將從設計時管理和運行時管理，兩個方面探討針對目標生態系統的治理。

設計時(Design Time)治理

如前所述，治理涉及到生命周期的管理、策略、標準、最佳實踐、以及可重用性。不同的微服務團隊可以擁有自己的生命周期定義、狀態轉移、以及用戶角色。WSO2數字資產治理方案，能夠讓團隊自定義生命周期，并將其添加到對應的服務中，以確保每個成員都會遵循那些業務所能夠接受的行業最佳實踐。例如，如果業界最佳實踐是將開放的API規范作用在API的定義上，那么每個微服務團隊都必須遵循此類標準。同時，團隊也應該有權選擇在開發中，將會用到的編程語言和庫。

設計時治理的另一個關鍵方面是可重用性。WSO2治理方案通過提供存儲庫，以便用戶檢索和瀏覽現有的服務，進而實現重用。據此，我們不但可以減少整體的上市時間，還能夠減少團隊在重復性工作上浪費的時間。

在管理服務的生命周期時，我們有時需要權衡是否需要棄用某種服務。WSO2治理方案可以幫助用戶分析給定的服務(或資產)對于其他類似對象的影響。

在API的開發方面，WSO2 API Manager附帶有API Publisher和Developer門戶，可提供對于API(和API代理)的生命周期管理和存儲庫功能。它能夠供那些在各自交付渠道(如：移動設備或Web應用程序方式)中用到該API的內、外部開發人員的調用。通過與WSO2 API Manager的集成，WSO2數字資產治理方案可以實現在治理平臺上完成API的設計，并將其推送到API的管理層。

運行時(Runtime)治理

運行時治理通過API來處理服務與治理平臺的運行時交互，以發現平臺上的目標資產。例如，在使用WSO2 EI開發的典型集成中，我們可以將端點的名稱指定為諸如“HospitalEP”之類的固定值。不過，該值的實際URL會根據不同環境(如：DEV、UAT、PROD)而有所差異。治理平臺可以實現端點名稱到URL的運行時映射，并解析URL的存儲值。此功能通常被稱為“服務發現”，也就是說，運行時通過調用管理平臺，來發現服務的實際URL。

此外，治理平臺還會公開一組REST API，并以編程的方式執行各種由設計時治理所產生的功能。這些API能夠讓微服務團隊將自動化部署，與治理平臺的生命周期管理相集成。值得注意的是，在將特定的服務部署到生產環境之前，我們需要進行人工檢查，以確保符合“信任但驗證”的策略。

當服務發生更改時，運行時治理需要向相關各方發送實時通知(如：電子郵件等)。例如，如果服務從實現狀態過渡到了發布狀態，那么平臺就會自動通知用戶(或前一個版本的用戶)，以便用戶能夠立刻從中受益。同理，如果資產被刪除，此類通知也能讓相關人員及時采取安全措施。

治理平臺的安全性

治理的一個關鍵方面是：平臺上目標資產(或服務)的安全性。我們既可以將用戶信息保持在LDAP和AD之類的企業級用戶存儲庫中，也可以將其連接到治理平臺的自有數據庫上，并根據微服務團隊的需求和公司的整體要求，定義角色并分配相應的權限集。例如：具有開發者角色的用戶無法將服務的生命周期，從實現狀態更改為發布狀態，而必須由具有產品經理角色的用戶，在驗證了必要的詳細信息之后，方可執行此類操作。同樣，如果需要在邏輯上隔離不同業務部門之間的資產，那么我們也可以創建多個租戶，并賦權他們維護各自的資源庫，而不會受到其他團隊的干擾。

微服務治理和API管理

目前，業界在微服務治理方面的一個最大誤解是認為：API管理平臺可以通過其API發布工具和開發者門戶來治理微服務。而事實上，只有當某個后端微服務團隊決定利用API管理平臺，將其微服務公開給其他組件上時，平臺才會開始使用那些與API有關的生命周期、標準和策略，與微服務進行交互。也就是說，它無法提供在API開發之前所需的管理功能。對此，人們傾向于將平臺擴展到API生命周期之外，含括后端微服務的“設計”、“審閱”、“實施”等階段。

不過，即使在API平臺上公開了所有微服務，這些平臺也無法處理有關微服務開發的治理問題(API代理部分除外)。對此，最好的解決方案是：在微服務治理平臺和API管理平臺之間架起一座橋梁，讓API管理成為微服務治理的擴展。

微服務治理和API管理的集成

如上圖所示，微服務治理捕獲了獨立于API開發的周期過程。在一個瀑布式的開發模型中，微服務團隊會負責微服務的實現和API的開發。這樣很好地促進了兩者的“橋接”。

在大多數情況下，當定義了API接口后，微服務開發和API開發這兩項任務就可以并行開展，而無需相互等待了。這就是我們經常聽到的所謂“API優先(API first)”的開發方法。如上圖所示，架構師將定義API并作為生命周期的初始輸出，然后分拆給兩個微服務團隊，分別進行后端實現的開發，以及API創建等相關活動。

此外，API管理平臺通常會在微服務之外創建API代理，并向運行時架構添加另一個組件。當然，并非每個微服務都需要如此。微服務團隊使用諸如服務網格之類的技術，讓其微服務的內部已經具有了QoS，而且只需要將其元數據發布給其他用戶，因此無需在現有的服務上，引入任何其他的運行時。此外，API管理平臺也無法使用諸如依賴關系分析等功能，來識別給定服務與生態系統中其他部分的關系，畢竟它只關注特定的API及其相關的端點。

API管理和微服務治理

如上圖所示，API管理平臺在微服務開發流程上為治理平臺提供了補充，實現了對微服務架構的端到端治理，進而通過流程的管控優勢，為企業和使用者帶來實際價值。

參考文獻

• https://www.wipro.com/blogs/dr-gopala-krishna-behara/microservices-governance/
• https://www.leanix.net/cn/blog/microservices-governance
• https://dzone.com/articles/efficient-enterprise-microservice-governance
• https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/
• https://medium.com/ibm-garage/microservices-technical-governance-f5aed10189d1

【原標題】Microservices Governance and API Management (作者: Chanaka Fernando)

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】