作者 | Bilgin Ibryam

譯者 | 王強

編輯 | Tina

為了讓微服務足以應對未來的挑戰(zhàn)，在設計微服務時需要加入數(shù)據(jù)流經(jīng)的入站和出站 API，以及描述這些 API 的元 API。

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

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

通過這種轉(zhuǎn)變，在服務中，我們可以繼續(xù)使用傳統(tǒng)數(shù)據(jù)庫做最適合它們的事情——高效處理可變狀態(tài)，并使事件日志以可靠的方式在服務之間傳播更改。

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

這種變革性的思維需要有意識地在微服務中提供出站 API，以將所有相關的狀態(tài)更改和領域事件從服務內(nèi)部傳輸?shù)酵獠渴澜纭?/p>

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

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

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

數(shù)據(jù)從微服務的入站 API 流向出站 API

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

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

入站 API 是當今微服務的常態(tài)

在實現(xiàn)方面，這些 API 通常是基于 REST 的，它們?yōu)橥讲僮魈峁┩蛔兓蛑蛔x操作，以負載均衡網(wǎng)關作為前端。這些也可以實現(xiàn)為異步的、基于命令的交互隊列，或基于事件的交互的主題。這些 API 的職責和治理很容易理解，它們構成了當今微服務 API 領域的大部分內(nèi)容。

我所說的出站 API 是源自服務內(nèi)部并通向外部服務和系統(tǒng)的交互，其中大部分是由服務發(fā)起的查詢和命令，目標是其他實體擁有的相關服務。我把源自服務內(nèi)部的出站事件也放在這個類別下面。出站事件不同于針對特定端點的查詢和命令，因為出站事件是由服務定義的，而沒有對現(xiàn)有和未來可能的接收者的具體知識。雖然這種 API 具有間接的性質(zhì)，我們?nèi)匀黄谕麑τ诜罩邪l(fā)生的任何重大更改（通常由入站交互引起），能夠可預測且可靠地生成這些事件。

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

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

通過更改數(shù)據(jù)捕獲實現(xiàn)的出站事件

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

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

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

元 API 的職責演變

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圍繞 Apache Kafka 生態(tài)系統(tǒng)的規(guī)范和實現(xiàn)

CNCF 的事件驅(qū)動領域已經(jīng)有一些規(guī)范正在獲得關注。

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

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

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

• CNCF Serverless Workflow 是一個供應商中立的規(guī)范，用于協(xié)調(diào)異步無狀態(tài)和有狀態(tài)交互。

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

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

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

作者介紹：

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

原文鏈接：

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