【51CTO.com快譯】

引言

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

IT治理的組成

人員

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

流程

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

技術(shù)

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

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

微服務(wù)與治理

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

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

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

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

微服務(wù)團(tuán)隊(duì)

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

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

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

業(yè)務(wù)目標(biāo)

微服務(wù)團(tuán)隊(duì)與治理控制平臺的交互

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

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

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

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

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

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

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

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

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

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

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

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

技術(shù)組成

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

人員

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

存儲與編錄

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

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

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

通過API進(jìn)行交互

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

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

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

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

如上圖所示，我們可以使用多種技術(shù)來實(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ù)，與整個(gè)生態(tài)系統(tǒng)相集成，并為最終用戶提供價(jià)值。

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

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

設(shè)計(jì)時(shí)(Design Time)治理

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

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

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

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

運(yùn)行時(shí)(Runtime)治理

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

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

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

治理平臺的安全性

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

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)

• 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

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

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