【51CTO.com快譯】

引言

從管理學上說，治理的定義是：“將人員、流程和技術(shù)聯(lián)系起來，為利益相關(guān)者創(chuàng)造價值。”如下圖所示，IT治理的流程會與企業(yè)IT生態(tài)系統(tǒng)中的三個主要部分持續(xù)進行交互。

IT治理的組成

人員

這包括具有各種技能的角色，如：開發(fā)人員、架構(gòu)師、業(yè)務(wù)分析師、CXO、以及參與IT服務(wù)交付過程的利益相關(guān)者。從需求識別到通過IT生態(tài)系統(tǒng)最終交付業(yè)務(wù)功能，這些不同的角色都會與基礎(chǔ)流程及技術(shù)進行交互，并通過不同的權(quán)限集，來實現(xiàn)治理模型，進而維持穩(wěn)定性、完整性和問責制。

流程

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

技術(shù)

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

可見，適當?shù)闹卫砟Ｐ途褪且和ㄟ^問責制和透明性，向利益相關(guān)者(如：消費者、合作伙伴)交付價值。如果我們分析大多數(shù)失敗的IT項目，就會發(fā)現(xiàn)：其中最常見的失敗原因之一便是缺乏治理。

微服務(wù)與治理

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

人們往往錯誤地認為：讓微服務(wù)開發(fā)團隊遵守各種流程和策略，可能會阻礙整體的創(chuàng)新和交付速度。但實際上，它是通過集中式控制平臺的分布式治理，引入適當?shù)牧鞒添樞颉６遥斀M織規(guī)模不斷壯大，并且需要交付100多種不同的微服務(wù)時，流程和策略的作用就更加顯著了。

微服務(wù)治理和業(yè)務(wù)目標

上圖展示了微服務(wù)團隊、治理和業(yè)務(wù)需求三者的關(guān)鍵特征，以及在為微服務(wù)構(gòu)建治理框架時的相互聯(lián)系。

微服務(wù)團隊

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

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

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

業(yè)務(wù)目標

微服務(wù)團隊與治理控制平臺的交互

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

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

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

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

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

微服務(wù)治理的兩種生命周期

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

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

不同的團隊也許會在其開發(fā)生命周期中表現(xiàn)出不同的特征與階段。但是，憑借著集中式控制平臺，架構(gòu)師可以持續(xù)比較不同的生命周期，并根據(jù)每個團隊的經(jīng)驗，提出相應(yīng)的改進建議。

微服務(wù)治理的參考架構(gòu)

有了前面的基礎(chǔ)知識，下面我們來討論微服務(wù)治理的參考架構(gòu)。

微服務(wù)治理的參考架構(gòu)

技術(shù)組成

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

人員

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

存儲與編錄

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

服務(wù)發(fā)現(xiàn)

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

通過API進行交互

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

通過WSO2來實施微服務(wù)治理

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

通過WSO2來實施微服務(wù)治理

如上圖所示，我們可以使用多種技術(shù)來實現(xiàn)不同領(lǐng)域的微服務(wù)，其中包括：

• 前端應(yīng)用程序 – Javascript、React、Angular
• API網(wǎng)關(guān) — WSO2 API Manager、Microgateway
• 集成服務(wù) — WSO2 Enterprise Integrator、Micro Integrator
• 后端業(yè)務(wù)服務(wù) - Spring Boot、Golang、.Net
• API開發(fā)者門戶 — WSO2 API Manager開發(fā)者門戶

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

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

下面，我們將從設(shè)計時管理和運行時管理，兩個方面探討針對目標生態(tài)系統(tǒng)的治理。

設(shè)計時(Design Time)治理

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

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

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

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

運行時(Runtime)治理

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

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

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

治理平臺的安全性

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

微服務(wù)治理和API管理

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

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

微服務(wù)治理和API管理的集成

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

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

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

API管理和微服務(wù)治理

如上圖所示，API管理平臺在微服務(wù)開發(fā)流程上為治理平臺提供了補充，實現(xiàn)了對微服務(wù)架構(gòu)的端到端治理，進而通過流程的管控優(yōu)勢，為企業(yè)和使用者帶來實際價值。

參考文獻

• 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譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】