【51CTO.com快譯】眾所周知，在一些中大型應(yīng)用中，企業(yè)通常會擁有數(shù)千個微服務(wù)。同時，每個團隊在選擇自己的技術(shù)堆棧時也擁有著一定的自主權(quán)。那么，企業(yè)不可避免地需要通過微服務(wù)的治理機制，來避免構(gòu)建出那些難以管理且不穩(wěn)定的架構(gòu)。而如果缺乏強有力的微服務(wù)治理策略，企業(yè)將會面臨如下的挑戰(zhàn)：

• 缺乏適當?shù)臋C制來監(jiān)控與衡量現(xiàn)有的產(chǎn)品性能，進而失去新產(chǎn)品的創(chuàng)新力。
• 由于缺少合適的平臺，企業(yè)將無法從整體上獲得洞見，也無法與IT團隊進行規(guī)劃與整體設(shè)計。
• 各種過期的文檔將會嚴重影響產(chǎn)品交付的敏捷性。
• 自治團隊與系統(tǒng)無法通過平臺進行相互操作與協(xié)作，企業(yè)會因為喪失敏捷性而無法遵循聯(lián)合開發(fā)(federated development)的原則。

雖然每個團隊都應(yīng)當具有標準化的策略可供遵循，但是任何集中式的治理方式都可能會違背微服務(wù)架構(gòu)的核心原則，即：“為團隊提供自治性和敏捷性”。因此，在面對具有多個系統(tǒng)和復(fù)雜操作的企業(yè)級集成環(huán)境時，我們需要解決的問題是：如何才能有效地提供分散式的治理方案?

在實施微服務(wù)治理策略時，我們往往需要在思維上進行范式的轉(zhuǎn)變。也就是說，各種治理策略應(yīng)當符合微服務(wù)的核心原則，即：各種獨立且自包含的服務(wù)、單一的職責、以及跨職能的團隊，需要與業(yè)務(wù)、策略、以及優(yōu)秀實踐保持一致。在此，我們提出三個實現(xiàn)高效的企業(yè)級微服務(wù)治理的方法，它們分別是：基于域(domain-based)，以產(chǎn)品為中心(product-centric)、平臺思想(platform thinking)。根據(jù)這三種方法，我們將能夠為企業(yè)提供一個與微服務(wù)原則相一致的治理平臺，以便企業(yè)能夠自動化地整合各項全局策略、標準和指南。下面，我們將逐一展開討論。

基于域

微服務(wù)體系架構(gòu)的關(guān)鍵原理之一是：遵循域驅(qū)動設(shè)計(domain-driven design，DDD)。也就是說，我們的治理策略應(yīng)當將“域”視為重點，其中各項業(yè)務(wù)或域?qū)＜覒?yīng)當根據(jù)DDD來定義信息模型。同時，企業(yè)還應(yīng)該能夠根據(jù)信息模型，為每個域定義相應(yīng)的業(yè)務(wù)能力。

以產(chǎn)品為中心

企業(yè)應(yīng)該能夠根據(jù)現(xiàn)有的信息模型和業(yè)務(wù)功能，來輕松定義各種產(chǎn)品，并且能夠為產(chǎn)品定義相應(yīng)的業(yè)務(wù)KPI。在治理方面，我們還應(yīng)當注意為企業(yè)提供有關(guān)現(xiàn)有產(chǎn)品、API、服務(wù)和實際KPI的整體視圖。這些將能夠幫助企業(yè)保持業(yè)務(wù)能力與最終客戶在預(yù)期上的一致性，快速識別和評估創(chuàng)新產(chǎn)品的有效性。

平臺思想

借助平臺思想，企業(yè)應(yīng)該能夠為業(yè)務(wù)和IT提供自助化的服務(wù)治理平臺，以便兩者進行相互協(xié)調(diào)和協(xié)作。企業(yè)應(yīng)該能夠通過模板定義全局策略、標準和準則。團隊可以根據(jù)他們?yōu)樽约旱念I(lǐng)域所確定的工具、以及技術(shù)，來構(gòu)建開發(fā)人員的模板。各種技術(shù)工件(artifact)應(yīng)當通過模板來自動生成，并通過CI/CD管道被部署到相應(yīng)的運行時(run-time)環(huán)境中，從而使得策略、標準和指南能夠得到自動化的實現(xiàn)。

下圖描述了一種業(yè)務(wù)體系架構(gòu)。在整個開發(fā)生命周期中，它屬于一種嵌入式的自助治理服務(wù)平臺。

如上圖所示，企業(yè)可以通過定義或上傳現(xiàn)有的信息模型，來建立各種業(yè)務(wù)能力，并快速定義新產(chǎn)品、及其預(yù)期的KPI。而團隊通過設(shè)計和創(chuàng)建API的定義，為微服務(wù)和業(yè)務(wù)事件定義那些消費者(consumer-driven)驅(qū)動的合約，以及各種非功能性的需求，以實現(xiàn)業(yè)務(wù)所定義的產(chǎn)品。同時，他們應(yīng)該能夠定義各種策略、優(yōu)秀實踐、訪問規(guī)則、數(shù)據(jù)質(zhì)量規(guī)則，上載相關(guān)的舊資產(chǎn)、數(shù)據(jù)源和集成點的各種元數(shù)據(jù)(meta-data)信息。這些實務(wù)都有助于團隊在設(shè)計時定義好從消費者到API與微服務(wù)的業(yè)務(wù)能力，SOAP服務(wù)之類的舊資產(chǎn)，甚至是數(shù)據(jù)源的端到端線性關(guān)系。

我曾經(jīng)有個客戶，它的企業(yè)擁有4,000至5,000個微服務(wù)，甚至有10至20個相同的微服務(wù)版本映射到不同的消費者處。他們所面臨的挑戰(zhàn)是：必須依靠運行時的各種指標，來識別消費者正在使用的版本，并通過開展影響分析，以改善當前的敏捷性問題。在實踐中，他們發(fā)現(xiàn)上述三種自助服務(wù)平臺，就可以幫助他們建立端到端的線性關(guān)系。

此類平臺具有的另一項重要功能是：使團隊能夠定義各種開發(fā)者模板，以便映射諸如：API定義、消費者驅(qū)動合約、集成點、策略、訪問規(guī)則、數(shù)據(jù)質(zhì)量規(guī)則等受控的元數(shù)據(jù)值。這些模板應(yīng)當通過源代碼管理(source control management，SCM)來進行版本控制，并與CI/CD的管道相集成，進而自動生成技術(shù)工件(如下圖所示)。此處的技術(shù)工件包括：API代理、微服務(wù)和業(yè)務(wù)事件的框架、各層之間的映射、單元測試用例、集成測試用例、來自消費者驅(qū)動的合約stub，以及API文檔等。這些將有助于企業(yè)根據(jù)各種受控制的元數(shù)據(jù)值產(chǎn)生一致性的輸出，允許自己的團隊更專注于業(yè)務(wù)邏輯，以及促進IT部門不斷交付業(yè)務(wù)價值。此外，通過各種數(shù)據(jù)質(zhì)量規(guī)則、以及自動化管理策略，我們還應(yīng)當將測試、基本安全性、以及認證等方面內(nèi)置到CI/CD的流程中。

那些帶有CI/CD管道的模板、以及線性集成點上的元數(shù)據(jù)，會使得我們能夠?qū)⒓傻倪壿媴R總到可以獨立控制與更新的管道中。此舉不但能夠支持聯(lián)合開發(fā)，還可以進一步提高產(chǎn)品“面市的速度”。

通過模板自動生成的技術(shù)工件

就像管理大師彼得·德魯克(Peter Drucker)所說：“我們無法改善和管理那些無法衡量的內(nèi)容。”可見，衡量性能是另一個值得關(guān)注的要點。如上圖所示，我們應(yīng)該將運行時環(huán)境中的各項指標及時反饋到平臺上，以計算實際的KPI和NFR(非功能性需求)，進而幫助企業(yè)和團隊比較實際狀態(tài)與計劃上的差異，以便團隊盡早獲悉變化，并根據(jù)實際情況做出正確的決策。

總結(jié)

可見，為了擁有一套有效的機制來實施微服務(wù)的治理，企業(yè)的主要推進方向應(yīng)當是：通過具有基于域和以產(chǎn)品為中心的模型，來搭建自助服務(wù)的治理平臺。通過平臺提供的治理方法和一致性的微服務(wù)原則，企業(yè)將能夠快速地交付出具有創(chuàng)新特質(zhì)的新產(chǎn)品。

與此同時，自助服務(wù)平臺為業(yè)務(wù)和IT部門提供了協(xié)作和協(xié)調(diào)的橋梁，它可以促進各個團隊更加專注于交付出真正的業(yè)務(wù)價值。而那些經(jīng)過治理的策略、標準和指南模板，也會在實施過程中產(chǎn)生可重復(fù)性的技術(shù)輸出。

通過采用上述三種微服務(wù)的治理方法，您的企業(yè)將能夠?qū)崿F(xiàn)設(shè)計時間和運行時的獨立性，先進的聯(lián)合開發(fā)模式，以及在不影響治理的情況下，加快體系架構(gòu)的不斷迭代。

原文標題：3 Keys to Efficient Enterprise Microservices Governance，作者：Asok Jacob Payyapilly

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