作者 | Bilgin Ibryam

譯者 | 王強

編輯 | Tina

為了讓微服務足以應對未來的挑戰，在設計微服務時需要加入數據流經的入站和出站 API，以及描述這些 API 的元 API。

分布式系統專家 Martin Kleppmann 在他的“由內至外的數據庫變革”的演講中提出了一個激進的想法：“從關系型數據庫轉向不可變事件和物化視圖的日志可以帶來顯著的收益。”他在演講中講解了關系型數據庫的內部工作原理，以及使用這種數據庫架構創建的應用程序所面臨的諸多局限，這些內容會徹底改變你對數據庫和事件日志的看法。

雖然我同意他列舉的各條數據庫局限，也認可他所提到的事件日志的好處，但我不認為用事件日志替換數據庫在實踐中是可行的。我認為用來徹底變革數據庫的那些設計原則應該應用在更高的服務設計級別，徹底改變微服務的流。

通過這種轉變，在服務中，我們可以繼續使用傳統數據庫做最適合它們的事情——高效處理可變狀態，并使事件日志以可靠的方式在服務之間傳播更改。

借助充當數據庫和事件日志之間連接組件的 Debezium 等框架，我們可以同時享受非常熟悉、久經考驗的數據庫技術以及現代化的事件日志（例如 Red Hat 的托管 Apache Kafka 服務）技術的便利。

這種變革性的思維需要有意識地在微服務中提供出站 API，以將所有相關的狀態更改和領域事件從服務內部傳輸到外部世界。

微服務運動與事件驅動的新興趨勢的融合，就是我所說的由內至外的微服務變革（turning microservices data inside-out）。

基于上述理念，我從微服務提供和消費的不同 API 類型的視角來研究微服務。

微服務的一種常見描述是“圍繞一個業務領域構建的許多獨立部署的組件，各自擁有自己的數據并通過 API 公開。”這很像是前文視頻中對數據庫的描述——有一個單個進出 API 的黑匣子。

數據從微服務的入站 API 流向出站 API

我認為微服務的一種更好的描述是，每個微服務都由數據流經的入站和出站 API 以及描述這些 API 的一個元 API 組成。雖然入站 API 在今天廣為人知，但出站 API 用到的地方并不多，而元 API 的職責分散在了各種工具和快速發展的微服務技術上。為了讓這種由內至外的方法發揮作用，我們需要讓出站和元 API 成為微服務的一等構造，并圍繞這些領域改進工具鏈和實踐。

如今所有微服務都有入站 API，它們以服務端點的形式存在。這些 API 是由外向內的，它們允許外部系統通過命令和查詢直接或通過事件間接與服務交互。

入站 API 是當今微服務的常態

在實現方面，這些 API 通常是基于 REST 的，它們為同步操作提供突變或只讀操作，以負載均衡網關作為前端。這些也可以實現為異步的、基于命令的交互隊列，或基于事件的交互的主題。這些 API 的職責和治理很容易理解，它們構成了當今微服務 API 領域的大部分內容。

我所說的出站 API 是源自服務內部并通向外部服務和系統的交互，其中大部分是由服務發起的查詢和命令，目標是其他實體擁有的相關服務。我把源自服務內部的出站事件也放在這個類別下面。出站事件不同于針對特定端點的查詢和命令，因為出站事件是由服務定義的，而沒有對現有和未來可能的接收者的具體知識。雖然這種 API 具有間接的性質，我們仍然期望對于服務中發生的任何重大更改（通常由入站交互引起），能夠可預測且可靠地生成這些事件。

今天，出站事件往往是在設計后期才會加上去的。它們要么是為依賴于它們的特定消費者的需求而創建的，要么是在服務生命周期的后期添加的——不是由服務所有者，而是由其他負責數據復制的團隊添加。在這兩種情況下，出站事件的可能用例都很狹窄，其潛力也被削弱了。

出站事件的一大挑戰是為服務中發生的任何更改實現一個統一且可靠的通知機制。為了在每一個微服務和所有類型的數據庫中統一應用這種方法，這里的工具必須是非侵入性的，并且對開發人員足夠友好。但現實中并不存在支持這種模式的良好框架，也沒有經過驗證的模式、實踐和標準，這些都阻礙了人們采用出站事件作為通行的頂級微服務構造。

通過更改數據捕獲實現的出站事件

要實現出站事件，你可以在應用程序代碼中加入更新數據庫和將事件發布到消息傳遞系統的邏輯，但這會引發眾所周知的雙重寫入問題?；蛘吣憧梢試L試用事件日志替換傳統數據庫，或使用專門的事件源平臺。但是，如果你認為項目中最有價值的資源是人才，以及他們久經戰陣的工具和實踐，那么用其他東西來替換數據庫等基本組件肯定會帶來重大影響。更好的方法是繼續使用關系型數據庫和圍繞它的所有歷經數十年風雨考驗的工具和實踐，并使用 Debezium 等連接組件來為你的數據庫做一個補充（免責聲明：我是 Red Hat 的 Debezium 產品經理，所以我肯定會偏愛它）。

我認為出站事件的最佳實現方法是發件箱模式，它使用單個事務來執行由服務邏輯指示的正常數據庫更新，并將消息插入到同一數據庫中的一個專用發件箱表中。將事務寫入數據庫的事務日志后，Debezium 從日志中提取發件箱消息并將其發送到 Apache Kafka。這種模式優點很多，例如“讀取你自己的寫入”語義，其中對服務的后續查詢會返回新存儲的記錄，同時我們還能通過 Apache Kafka 獲得可靠、異步的更改傳播。Debezium 可以有選擇地從數據庫事務日志中捕獲更改，以統一的方式將它們轉換并發布到 Kafka 中，充當服務的出站事件接口。Debezium 可以作為一個庫嵌入到 Java 應用程序運行時中，也可以解耦成一個邊車（sidecar）。它是即插即用的組件，無論是遺留服務還是從頭開始創建的新服務都可以把它加進去。這就是任何服務都需要的，基于配置的出站事件 API。

今天，元 API 負責描述入站和出站 API，并實現對它們的治理、發現和使用。它們是在圍繞特定技術的孤立工具中實現的。在我的定義中，發布到 API 門戶的 REST 端點的 OpenAPI 就是元 API 的一個示例。發布到模式注冊表的消息主題的 AsyncAPI 也是元 API 的一個示例。Debezium 發布數據庫模式更改事件（不同于數據更改事件）的模式更改主題是元 API 的又一個示例。其他工具中有各種描述數據結構的功能，服務它們的 API 都可以歸類為元 API。所以在我的定義中，元 API 是允許不同利益相關者使用服務并支持其他系統使用入站和出站 API 的工件。

元 API 的職責演變

微服務的一條基本設計原則是讓服務可獨立更新和部署。但是今天，服務所有者之間仍然需要大量協調才能完成涉及 API 更改的升級工作。服務所有者需要更好的元 API 工具來訂閱依賴服務的更新并實現及時更改。元 API 工具需要更深入地集成到開發和運營活動中，以提高敏捷性。今天的元 API 工具在整個技術棧中都是孤立的、被動的和不相關的。將來，元工具需要將服務交互的變化性質反映為事件驅動的方法，并在自動化開發和運營團隊的一些常規任務方面發揮更積極的作用。

出站事件已經成為大多數現代平臺的首選集成方法。大多數云服務都會發出事件。許多數據源（例如 Cockroach changefeeds、MongoDB 更改流）甚至文件系統（例如 Ceph通知）都可以發出狀態更改事件。定制的微服務在這里也不例外。發出狀態更改或域事件是現代微服務統一匹配它們所連接的事件驅動系統，以便從相同的工具鏈和實踐中受益的最自然方式。

出于多種原因，出站事件必然會成為頂級微服務設計構造。設計具有出站事件的服務有助于在應用程序現代化過程中復制數據。出站事件還能通過發件箱模式和使用非阻塞 Saga 實現跨越多個服務的復雜業務事務，來實現優雅的服務間交互。

出站事件非常適合分布式數據網格架構。在這種架構中，服務從設計之初就考慮了自己的數據消費者。數據網格聲稱，對于推動創新的數據，其所有權必須由負責將其數據作為產品提供的域數據所有者之間聯合承擔。簡而言之，與其讓一個中心化的數據工程團隊通過 ETL 流程從每個微服務復制數據，不如讓微服務與開發人員和數據工程師共同擁有，并在設計服務時一開始就讓數據可用。有什么比通過 Debezium、Apache Kafka 和 Schema Registry 使用實時數據流傳輸出站事件更好的方法呢？

總而言之，出站事件讓微服務得以符合 Unix 哲學，即“每個程序的輸出成為尚未知程序的輸入”。為了讓你的服務迎接未來的挑戰，你在設計服務時需要讓數據從入站 API 流向出站 API。這讓我們可以使用現代化的面向事件工具和模式統一開發和運維所有服務，并在將來解鎖通過事件公開的數據的更多未知用途。

隨著事件驅動架構的采用增長、服務演進速度不斷加快，元 API 的職責和重要性也在上升。元 API 工具的作用域不再局限于同步 API，還包括了異步 API。元 API 正在持續發展，通過兼容性檢查、更新通知、綁定代碼生成、測試模擬等途徑促進安全的模式演變，從而實現更快的開發周期。

作為服務的消費者，我想在同一處位置發現已有的端點和數據格式、API 兼容性規則、限制和服務遵守的 SLA。同時，我希望收到關于即將發生的任何更改、任何棄用、API 更新或我可能感興趣的服務將提供的任何新 API 的通知。不僅如此，開發人員還面臨著越來越快地交付代碼的挑戰，而現代 API 工具可以自動化模式和事件結構發現的過程。一旦一個模式被發現并添加到了注冊表中，開發人員就可以快速為其語言生成代碼綁定并開始在 IDE 中進行開發工作。然后，其他工具可以使用元 API 定義并生成測試和模擬（mock），并使用 Microcks 甚至 Postman 之類的東西發出偽事件來模擬負載。在運行時，元 API 中可用的上下文信息可以使讓我正在運行應用程序的平臺注入連接憑據，將其注冊到監控工具，等等。

總體而言，元 API 正在異步交互生態系統中發揮更積極的作用，包括自動化服務所有者之間的一些協調活動、提高開發人員生產力和自動化運營團隊的許多任務。為了實現這一點，包含 API 元數據、代碼生成、測試刺激、環境管理的各種工具必須更好地融合、標準化和集成。

事件驅動架構（EDA）有著悠久的歷史，而最近的一些推動因素，如云計算的流行、微服務架構和更快的變革步伐，都提高了 EDA 的重要性和采用率。正如 Kubernetes 及其生態系統在平臺空間中發生的整合和標準化過程，圍繞 Apache Kafka 的事件驅動空間中也存在著整合和社區驅動的標準化趨勢。我們來看幾個具體的例子。

Apache Kafka 已成為事件流的事實標準平臺，就像 AWS S3 之于對象存儲，Kubernetes 之于容器編排一樣。Kafka 背后有一個龐大的社區、一個大型的工具和服務開源生態系統，并且可能是現代數字組織采用的最大的事件基礎設施。業內存在各種各樣的由專業公司和云提供商提供的自托管 Kafka 產品和托管服務，最近 Red Hat 也加入了這一行列。（Red Hat OpenShift Streams for Apache Kafka 是我參與開發的一項托管 Kafka 服務，我很想聽聽大家的反饋意見。）

人們經常用 Kafka 作為基于日志的消息傳遞 API，甚至 Pulsar、Red Panda 和 Azure 事件中心等非 Kafka 項目也提供了對它的兼容性。今天的 Kafka 不僅僅是一個第三方架構依賴。Kafka 影響了服務的設計和實現方式，決定了系統實現擴展和高可用的路徑，并驅動用戶基于它來實時消費數據。但 Kafka 本身就像一個沒有任何 Pod 的裸 Kubernetes 平臺。下面我們來看看 Kafka 生態系統中還有哪些必不可少的補充內容，并且這些內容也正在成為事實標準。

模式注冊表（Schema Registry）對異步 API 來說就像是 API 管理器對于同步 API 一樣重要。在許多流場景中，事件負載包含了生產者和消費者都需要理解和驗證的結構化數據。模式注冊表為模式文檔提供了一個中央存儲庫和一個通用治理框架，并使應用程序能夠遵守這些契約。今天市面上有很多注冊表，例如 Red Hat 的 Apicurio、Aiven 的 Karapace，還有來自 Cloudera、Lenses、Confluent、Azure、AWS 等廠商的注冊表。雖然模式存儲庫越來越受歡迎，并且圍繞模式管理的功能和實踐也在不斷充實，但同時它們的許可限制也有很多不同。不僅如此，模式注冊表往往會以 Kafka 序列化器 / 反序列化器（SerDes）、轉換器和其他客戶端依賴的形式泄漏到客戶端應用程序中。因此人們很快意識到，需要一個開放和供應商中立的標準來切換實現。好消息是 CNCF 提出了模式注冊表 API標準提案，并且 Apicurio 和 Azure Schema Registry 等注冊表已經開始遵循它了。用開源服務注冊表 API 和通用治理實踐作為開源 Kafka API 的補充看起來是正確的做法，我希望這個領域能有越來越多的采用和整合過程，使整個元 API 概念成為事件驅動架構的基石。

與 EDA 類似，更改數據捕獲（CDC）的概念也并不新鮮。但最近圍繞事件驅動系統的驅動因素，和對實時數據訪問的日益增長的需求正在為事務日志驅動的事件流工具開辟道路。今天，市面上有許多閉源、點擊式工具（如 Striim、HVR、Qlik）依賴同樣的事務日志概念來點對點復制數據。有一些云服務，例如 AWS DMS、Oracle GoldenGate Cloud Service 和 Google Datastream 會將你的數據流式傳輸到它們的服務中（但反過來是不行的）。有許多數據庫和鍵值存儲也可以流式傳輸更改。人們越來越希望看到一種開源、供應商中立的 CDC 標準，不同供應商都可以遵循這種標準、下游的更改事件消費者也可以依賴它。

為了取得成功，這樣的標準必須在供應商中立的基礎上進行管理，并成為更廣闊的生態系統的一部分。目前最接近這一目標的是 CNCF，它已經誕生了 AsyncAPI、CloudEvents、Schema Registry 和 Serverless Workflow 規范。目前，CDC 領域領先的開源項目是 Debezium。Debezium 得到了很多大公司的使用，嵌入到了 Google、Heroku、Confluent、Aiven、Red Hat 的云服務和多個開源項目中，并被許多我們無法知曉的專有解決方案使用。如果你正在尋找這一領域的標準，最接近事實標準的就是 Debezium。

澄清一下，談到 CDC 標準，我并不是指數據源發出更改的 API。我的意思是說數據源和連接組件（例如 Debezium）在將數據庫事務日志轉換為事件時要遵循的標準約定。這包括了數據映射（從數據庫字段類型到 JSON/Avro 類型）、數據結構（例如 Debezium 的 Before/After 消息結構）、快照、將表劃分為主題、將主鍵劃分為主題分區、事務劃分指示符等等。如果你非常重視 CDC，使用 Debezium 將確保從數據庫事務日志條目映射到跨數據源統一的 Apache Kafka 事件的語義都是一致的。

圍繞 Apache Kafka 生態系統的規范和實現

CNCF 的事件驅動領域已經有一些規范正在獲得關注。

• AsyncAPI 是用于事件驅動應用程序的 OpenAPI 的等效實現，最近加入了 CNCF。它提供了一個規范來為你的事件驅動系統制訂文檔，以保持不同團隊和工具之間的一致性和統一治理。

• CloudEvents（也是 CNCF 的一部分）旨在將強制性元數據信息指定到可以稱為一個標準信封的內容中，來消除元數據挑戰。它還為多種協議的多種編程語言提供了庫，從而簡化了互操作性。

• OpenTelemetry（另一個 CNCF 沙箱項目）標準化了跟蹤信息的創建和管理工作，這些信息通過多個應用程序揭示事件的端到端路徑。

• CNCF Serverless Workflow 是一個供應商中立的規范，用于協調異步無狀態和有狀態交互。

• 還有我們上面討論的 CNCF 中的服務注冊表提案。

無論我們稱之為標準化、社區采用還是其他什么東西，我們都不能忽視圍繞事件驅動構造的整合過程，并看到一些開源項目正在崛起成為事實標準。

微服務的重心一直是封裝屬于某個業務領域的數據，并通過盡可能少的 API 將其公開。但這種情況正在改變。離開服務的數據與進入服務的數據同樣重要。在微服務中公開數據不再是事后才補上的概念。封裝在高度解耦的微服務中的孤立且不可訪問的數據是沒多少價值的。數據的新用戶和可能出現的用戶需要訪問可發現、可理解的實時數據。為了滿足這些用戶的需求，微服務必須將數據由內而外送出去，并在設計中加入可以發出數據的出站 API，和使數據消費成為自助活動的元 API。Apache Kafka、Debezium 和 Apicurio 等項目是這種架構的自然推動者，在各種開源異步規范的幫助下，它們正在成為實現面向未來的事件驅動微服務的事實選項。

作者介紹：

Bilgin Ibryam 是 Red Hat 的產品經理和前架構師，是 Apache 軟件基金會的提交者和成員。他是開源布道者、博客作家、演講者和《Kubernetes 模式》《Camel 設計模式》等書的作者。Bilgin 目前的工作重點是分布式系統、事件驅動架構和可重復的云原生應用程序開發模式與實踐?？梢栽?Twitter 上關注 @bibryam，以獲取這方面主題的未來更新內容。

原文鏈接：

https://www.infoq.com/articles/microservices-inside-out/