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

• 缺乏適當的機制來監控與衡量現有的產品性能，進而失去新產品的創新力。
• 由于缺少合適的平臺，企業將無法從整體上獲得洞見，也無法與IT團隊進行規劃與整體設計。
• 各種過期的文檔將會嚴重影響產品交付的敏捷性。
• 自治團隊與系統無法通過平臺進行相互操作與協作，企業會因為喪失敏捷性而無法遵循聯合開發(federated development)的原則。

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

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

基于域

微服務體系架構的關鍵原理之一是：遵循域驅動設計(domain-driven design，DDD)。也就是說，我們的治理策略應當將“域”視為重點，其中各項業務或域專家應當根據DDD來定義信息模型。同時，企業還應該能夠根據信息模型，為每個域定義相應的業務能力。

以產品為中心

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

平臺思想

借助平臺思想，企業應該能夠為業務和IT提供自助化的服務治理平臺，以便兩者進行相互協調和協作。企業應該能夠通過模板定義全局策略、標準和準則。團隊可以根據他們為自己的領域所確定的工具、以及技術，來構建開發人員的模板。各種技術工件(artifact)應當通過模板來自動生成，并通過CI/CD管道被部署到相應的運行時(run-time)環境中，從而使得策略、標準和指南能夠得到自動化的實現。

下圖描述了一種業務體系架構。在整個開發生命周期中，它屬于一種嵌入式的自助治理服務平臺。

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

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

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

那些帶有CI/CD管道的模板、以及線性集成點上的元數據，會使得我們能夠將集成的邏輯匯總到可以獨立控制與更新的管道中。此舉不但能夠支持聯合開發，還可以進一步提高產品“面市的速度”。

通過模板自動生成的技術工件

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

總結

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

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

通過采用上述三種微服務的治理方法，您的企業將能夠實現設計時間和運行時的獨立性，先進的聯合開發模式，以及在不影響治理的情況下，加快體系架構的不斷迭代。

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

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