微服務需要一場由內至外的變革

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"分佈式系統專家 Martin Kleppmann 在他的“"},{"type":"link","attrs":{"href":"https:\/\/martin.kleppmann.com\/2015\/11\/05\/database-inside-out-at-oredev.html","title":"","type":null},"content":[{"type":"text","text":"由內至外的數據庫變革"}]},{"type":"text","text":"”的演講中提出了一個激進的想法：“從關係型數據庫轉向不可變事件和物化視圖的日誌可以帶來顯著的收益。”他在演講中講解了關係型數據庫的內部工作原理，以及使用這種數據庫架構創建的應用程序所面臨的諸多侷限，這些內容會徹底改變你對數據庫和事件日誌的看法。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"雖然我同意他列舉的各條數據庫侷限，也認可他所提到的事件日誌的好處，但我不認爲用事件日誌替換數據庫在實踐中是可行的。我認爲用來徹底變革數據庫的那些設計原則應該應用在更高的服務設計級別，徹底改變微服務的流。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通過這種轉變，在服務中，我們可以繼續使用傳統數據庫做最適合它們的事情——高效處理可變狀態，並使事件日誌以可靠的方式在服務之間傳播更改。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"藉助充當數據庫和事件日誌之間連接組件的 Debezium 等框架，我們可以同時享受非常熟悉、久經考驗的數據庫技術以及現代化的事件日誌（例如 Red Hat 的託管 "},{"type":"link","attrs":{"href":"https:\/\/developers.redhat.com\/products\/red-hat-openshift-streams-for-apache-kafka\/getting-started","title":"","type":null},"content":[{"type":"text","text":"Apache Kafka 服務"}]},{"type":"text","text":"）技術的便利。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這種變革性的思維需要有意識地在微服務中提供出站 API，以將所有相關的狀態更改和領域事件從服務內部傳輸到外部世界。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務運動與事件驅動的新興趨勢的融合，就是我所說的由內至外的微服務變革（turning microservices data inside-out）。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"微服務 API 類型"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基於上述理念，我從微服務提供和消費的不同 API 類型的視角來研究微服務。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務的一種常見描述是“圍繞一個業務領域構建的許多獨立部署的組件，各自擁有自己的數據並通過 API 公開。”這很像是前文視頻中對數據庫的描述——有一個單個進出 API 的黑匣子。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/res.infoq.com\/articles\/microservices-inside-out\/en\/resources\/1data-flowing-from%20microservices-inbound-to-outbound-APIs-1627634941130.jpg","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"數據從微服務的入站 API 流向出站 API"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我認爲微服務的一種更好的描述是，每個微服務都由數據流經的入站和出站 API 以及描述這些 API 的一個元 API 組成。雖然入站 API 在今天廣爲人知，但出站 API 用到的地方並不多，而元 API 的職責分散在了各種工具和快速發展的微服務技術上。爲了讓這種由內至外的方法發揮作用，我們需要讓出站和元 API 成爲微服務的一等構造，並圍繞這些領域改進工具鏈和實踐。"}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"入站 API"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如今所有微服務都有入站 API，它們以服務端點的形式存在。這些 API 是由外向內的，它們允許外部系統通過命令和查詢直接或通過事件間接與服務交互。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/res.infoq.com\/articles\/microservices-inside-out\/en\/resources\/1inbound-APIs-are-the-norm-in-microservices-today-1627634941130.jpg","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"入站 API 是當今微服務的常態"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在實現方面，這些 API 通常是基於 REST 的，它們爲同步操作提供突變或只讀操作，以負載均衡網關作爲前端。這些也可以實現爲異步的、基於命令的交互隊列，或基於事件的交互的主題。這些 API 的職責和治理很容易理解，它們構成了當今微服務 API 領域的大部分內容。"}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"出站 API"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我所說的出站 API 是源自服務內部並通向外部服務和系統的交互，其中大部分是由服務發起的查詢和命令，目標是其他實體擁有的相關服務。我把源自服務內部的出站事件也放在這個類別下面。出站事件不同於針對特定端點的查詢和命令，因爲出站事件是由服務定義的，而沒有對現有和未來可能的接收者的具體知識。雖然這種 API 具有間接的性質，我們仍然期望對於服務中發生的任何重大更改（通常由入站交互引起），能夠可預測且可靠地生成這些事件。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"今天，出站事件往往是在設計後期纔會加上去的。它們要麼是爲依賴於它們的特定消費者的需求而創建的，要麼是在服務生命週期的後期添加的——不是由服務所有者，而是由其他負責數據複製的團隊添加。在這兩種情況下，出站事件的可能用例都很狹窄，其潛力也被削弱了。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"出站事件的一大挑戰是爲服務中發生的任何更改實現一個統一且可靠的通知機制。爲了在每一個微服務和所有類型的數據庫中統一應用這種方法，這裏的工具必須是非侵入性的，並且對開發人員足夠友好。但現實中並不存在支持這種模式的良好框架，也沒有經過驗證的模式、實踐和標準，這些都阻礙了人們採用出站事件作爲通行的頂級微服務構造。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/res.infoq.com\/articles\/microservices-inside-out\/en\/resources\/1outbound-events-implemented-through-change-data-capture-1627635737569.jpg","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"通過更改數據捕獲實現的出站事件"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"要實現出站事件，你可以在應用程序代碼中加入更新數據庫和將事件發佈到消息傳遞系統的邏輯，但這會引發衆所周知的雙重寫入問題。或者你可以嘗試用事件日誌替換傳統數據庫，或使用專門的事件源平臺。但是，如果你認爲項目中最有價值的資源是人才，以及他們久經戰陣的工具和實踐，那麼用其他東西來替換數據庫等基本組件肯定會帶來重大影響。更好的方法是繼續使用關係型數據庫和圍繞它的所有歷經數十年風雨考驗的工具和實踐，並使用 Debezium 等連接組件來爲你的數據庫做一個補充（免責聲明：我是 Red Hat 的 Debezium 產品經理，所以我肯定會偏愛它）。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我認爲出站事件的最佳實現方法是發件箱模式，它使用單個事務來執行由服務邏輯指示的正常數據庫更新，並將消息插入到同一數據庫中的一個專用發件箱表中。將事務寫入數據庫的事務日誌後，Debezium 從日誌中提取發件箱消息並將其發送到 Apache Kafka。這種模式優點很多，例如“讀取你自己的寫入”語義，其中對服務的後續查詢會返回新存儲的記錄，同時我們還能通過 Apache Kafka 獲得可靠、異步的更改傳播。Debezium 可以有選擇地從數據庫事務日誌中捕獲更改，以統一的方式將它們轉換併發布到 Kafka 中，充當服務的出站事件接口。Debezium 可以作爲一個庫嵌入到 Java 應用程序運行時中，也可以解耦成一個邊車（sidecar）。它是即插即用的組件，無論是遺留服務還是從頭開始創建的新服務都可以把它加進去。這就是任何服務都需要的，基於配置的出站事件 API。"}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"元 API"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"今天，元 API 負責描述入站和出站 API，並實現對它們的治理、發現和使用。它們是在圍繞特定技術的孤立工具中實現的。在我的定義中，發佈到 API 門戶的 REST 端點的 OpenAPI 就是元 API 的一個示例。發佈到模式註冊表的消息主題的 AsyncAPI 也是元 API 的一個示例。Debezium 發佈數據庫模式更改事件（不同於數據更改事件）的模式更改主題是元 API 的又一個示例。其他工具中有各種描述數據結構的功能，服務它們的 API 都可以歸類爲元 API。所以在我的定義中，元 API 是允許不同利益相關者使用服務並支持其他系統使用入站和出站 API 的工件。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/res.infoq.com\/articles\/microservices-inside-out\/en\/resources\/1the-evolving-responsibilities-of-Meta-APIs-1627635737569.jpg","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"元 API 的職責演變"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務的一條基本設計原則是讓服務可獨立更新和部署。但是今天，服務所有者之間仍然需要大量協調才能完成涉及 API 更改的升級工作。服務所有者需要更好的元 API 工具來訂閱依賴服務的更新並實現及時更改。元 API 工具需要更深入地集成到開發和運營活動中，以提高敏捷性。今天的元 API 工具在整個技術棧中都是孤立的、被動的和不相關的。將來，元工具需要將服務交互的變化性質反映爲事件驅動的方法，並在自動化開發和運營團隊的一些常規任務方面發揮更積極的作用。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"新興趨勢"}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"出站事件的興起"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"出站事件已經成爲大多數現代平臺的首選集成方法。大多數雲服務都會發出事件。許多數據源（例如 Cockroach changefeeds、MongoDB 更改流）甚至文件系統（例如 Ceph通知）都可以發出狀態更改事件。定製的微服務在這裏也不例外。發出狀態更改或域事件是現代微服務統一匹配它們所連接的事件驅動系統，以便從相同的工具鏈和實踐中受益的最自然方式。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"出於多種原因，出站事件必然會成爲頂級微服務設計構造。設計具有出站事件的服務有助於在應用程序現代化過程中複製數據。出站事件還能通過發件箱模式和使用非阻塞 Saga 實現跨越多個服務的複雜業務事務，來實現優雅的服務間交互。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"出站事件非常適合分佈式數據網格架構。在這種架構中，服務從設計之初就考慮了自己的數據消費者。數據網格聲稱，對於推動創新的數據，其所有權必須由負責將其數據作爲產品提供的域數據所有者之間聯合承擔。簡而言之，與其讓一箇中心化的數據工程團隊通過 ETL 流程從每個微服務複製數據，不如讓微服務與開發人員和數據工程師共同擁有，並在設計服務時一開始就讓數據可用。有什麼比通過 Debezium、Apache Kafka 和 Schema Registry 使用實時數據流傳輸出站事件更好的方法呢？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"總而言之，出站事件讓微服務得以符合 Unix 哲學，即“每個程序的輸出成爲尚未知程序的輸入”。爲了讓你的服務迎接未來的挑戰，你在設計服務時需要讓數據從入站 API 流向出站 API。這讓我們可以使用現代化的面向事件工具和模式統一開發和運維所有服務，並在將來解鎖通過事件公開的數據的更多未知用途。"}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"元 API 工具的融合"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"隨着事件驅動架構的採用增長、服務演進速度不斷加快，元 API 的職責和重要性也在上升。元 API 工具的作用域不再侷限於同步 API，還包括了異步 API。元 API 正在持續發展，通過兼容性檢查、更新通知、綁定代碼生成、測試模擬等途徑促進安全的模式演變，從而實現更快的開發週期。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"作爲服務的消費者，我想在同一處位置發現已有的端點和數據格式、API 兼容性規則、限制和服務遵守的 SLA。同時，我希望收到關於即將發生的任何更改、任何棄用、API 更新或我可能感興趣的服務將提供的任何新 API 的通知。不僅如此，開發人員還面臨着越來越快地交付代碼的挑戰，而現代 API 工具可以自動化模式和事件結構發現的過程。一旦一個模式被發現並添加到了註冊表中，開發人員就可以快速爲其語言生成代碼綁定並開始在 IDE 中進行開發工作。然後，其他工具可以使用元 API 定義並生成測試和模擬（mock），並使用 Microcks 甚至 Postman 之類的東西發出僞事件來模擬負載。在運行時，元 API 中可用的上下文信息可以使讓我正在運行應用程序的平臺注入連接憑據，將其註冊到監控工具，等等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"總體而言，元 API 正在異步交互生態系統中發揮更積極的作用，包括自動化服務所有者之間的一些協調活動、提高開發人員生產力和自動化運營團隊的許多任務。爲了實現這一點，包含 API 元數據、代碼生成、測試刺激、環境管理的各種工具必須更好地融合、標準化和集成。"}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"事件驅動空間的標準化"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"事件驅動架構（EDA）有着悠久的歷史，而最近的一些推動因素，如雲計算的流行、微服務架構和更快的變革步伐，都提高了 EDA 的重要性和採用率。正如 Kubernetes 及其生態系統在平臺空間中發生的整合和標準化過程，圍繞 Apache Kafka 的事件驅動空間中也存在着整合和社區驅動的標準化趨勢。我們來看幾個具體的例子。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Apache Kafka"},{"type":"text","text":" 已成爲事件流的事實標準平臺，就像 AWS S3 之於對象存儲，Kubernetes 之於容器編排一樣。Kafka 背後有一個龐大的社區、一個大型的工具和服務開源生態系統，並且可能是現代數字組織採用的最大的事件基礎設施。業內存在各種各樣的由專業公司和雲提供商提供的自託管 Kafka 產品和託管服務，最近 Red Hat 也加入了這一行列。（Red Hat OpenShift Streams for Apache Kafka 是我參與開發的一項託管 Kafka 服務，我很想聽聽大家的反饋意見。）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"人們經常用 Kafka 作爲基於日誌的消息傳遞 API，甚至 Pulsar、Red Panda 和 Azure 事件中心等非 Kafka 項目也提供了對它的兼容性。今天的 Kafka 不僅僅是一個第三方架構依賴。Kafka 影響了服務的設計和實現方式，決定了系統實現擴展和高可用的路徑，並驅動用戶基於它來實時消費數據。但 Kafka 本身就像一個沒有任何 Pod 的裸 Kubernetes 平臺。下面我們來看看 Kafka 生態系統中還有哪些必不可少的補充內容，並且這些內容也正在成爲事實標準。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"模式註冊表"},{"type":"text","text":"（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 概念成爲事件驅動架構的基石。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"與 EDA 類似，"},{"type":"text","marks":[{"type":"strong"}],"text":"更改數據捕獲"},{"type":"text","text":"（"},{"type":"link","attrs":{"href":"https:\/\/www.redhat.com\/en\/topics\/integration\/what-is-change-data-capture","title":"","type":null},"content":[{"type":"text","text":"CDC"}]},{"type":"text","text":"）的概念也並不新鮮。但最近圍繞事件驅動系統的驅動因素，和對實時數據訪問的日益增長的需求正在爲事務日誌驅動的事件流工具開闢道路。今天，市面上有許多閉源、點擊式工具（如 Striim、HVR、Qlik）依賴同樣的事務日誌概念來點對點複製數據。有一些雲服務，例如 AWS DMS、Oracle GoldenGate Cloud Service 和 Google Datastream 會將你的數據流式傳輸到它們的服務中（但反過來是不行的）。有許多數據庫和鍵值存儲也可以流式傳輸更改。人們越來越希望看到一種開源、供應商中立的 CDC 標準，不同供應商都可以遵循這種標準、下游的更改事件消費者也可以依賴它。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"爲了取得成功，這樣的標準必須在供應商中立的基礎上進行管理，併成爲更廣闊的生態系統的一部分。目前最接近這一目標的是 CNCF，它已經誕生了 AsyncAPI、CloudEvents、Schema Registry 和 Serverless Workflow 規範。目前，CDC 領域領先的開源項目是 Debezium。Debezium 得到了很多大公司的使用，嵌入到了 Google、Heroku、Confluent、Aiven、Red Hat 的雲服務和多個開源項目中，並被許多我們無法知曉的專有解決方案使用。如果你正在尋找這一領域的標準，最接近事實標準的就是 Debezium。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"澄清一下，談到 CDC 標準，我並不是指數據源發出更改的 API。我的意思是說數據源和連接組件（例如 Debezium）在將數據庫事務日誌轉換爲事件時要遵循的標準約定。這包括了數據映射（從數據庫字段類型到 JSON\/Avro 類型）、數據結構（例如 Debezium 的 Before\/After 消息結構）、快照、將表劃分爲主題、將主鍵劃分爲主題分區、事務劃分指示符等等。如果你非常重視 CDC，使用 Debezium 將確保從數據庫事務日誌條目映射到跨數據源統一的 Apache Kafka 事件的語義都是一致的。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/b4\/e4\/b441ce0e449646b2yy12121eb769f0e4.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圍繞 Apache Kafka 生態系統的規範和實現"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"CNCF 的事件驅動領域已經有一些規範正在獲得關注。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.asyncapi.com\/docs\/specifications\/latest","title":"","type":null},"content":[{"type":"text","text":"AsyncAPI"}]},{"type":"text","text":" 是用於事件驅動應用程序的 "},{"type":"link","attrs":{"href":"https:\/\/spec.openapis.org\/oas\/latest.html","title":"","type":null},"content":[{"type":"text","text":"OpenAPI"}]},{"type":"text","text":" 的等效實現，最近加入了 CNCF。它提供了一個規範來爲你的事件驅動系統制訂文檔，以保持不同團隊和工具之間的一致性和統一治理。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"CloudEvents（也是 CNCF 的一部分）旨在將強制性元數據信息指定到可以稱爲一個標準信封的內容中，來消除元數據挑戰。它還爲多種協議的多種編程語言提供了庫，從而簡化了互操作性。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/opentelemetry.io\/","title":"","type":null},"content":[{"type":"text","text":"OpenTelemetry"}]},{"type":"text","text":"（另一個 CNCF 沙箱項目）標準化了跟蹤信息的創建和管理工作，這些信息通過多個應用程序揭示事件的端到端路徑。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"CNCF Serverless Workflow 是一個供應商中立的規範，用於協調異步無狀態和有狀態交互。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"還有我們上面討論的 CNCF 中的服務註冊表提案。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"無論我們稱之爲標準化、社區採用還是其他什麼東西，我們都不能忽視圍繞事件驅動構造的整合過程，並看到一些開源項目正在崛起成爲事實標準。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"總結"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務的重心一直是封裝屬於某個業務領域的數據，並通過儘可能少的 API 將其公開。但這種情況正在改變。離開服務的數據與進入服務的數據同樣重要。在微服務中公開數據不再是事後才補上的概念。封裝在高度解耦的微服務中的孤立且不可訪問的數據是沒多少價值的。數據的新用戶和可能出現的用戶需要訪問可發現、可理解的實時數據。爲了滿足這些用戶的需求，微服務必須將數據由內而外送出去，並在設計中加入可以發出數據的出站 API，和使數據消費成爲自助活動的元 API。Apache Kafka、Debezium 和 Apicurio 等項目是這種架構的自然推動者，在各種開源異步規範的幫助下，它們正在成爲實現面向未來的事件驅動微服務的事實選項。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"作者介紹："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"Bilgin Ibryam"},{"type":"text","text":" 是 Red Hat 的產品經理和前架構師，是 Apache 軟件基金會的提交者和成員。他是開源佈道者、博客作家、演講者和《"},{"type":"link","attrs":{"href":"https:\/\/k8spatterns.io\/","title":"","type":null},"content":[{"type":"text","text":"Kubernetes 模式"}]},{"type":"text","text":"》《Camel 設計模式》等書的作者。Bilgin 目前的工作重點是分佈式系統、事件驅動架構和可重複的雲原生應用程序開發模式與實踐。可以在 Twitter 上關注 @bibryam，以獲取這方面主題的未來更新內容。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"原文鏈接："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.com\/articles\/microservices-inside-out","title":"xxx","type":null},"content":[{"type":"text","text":"https:\/\/www.infoq.com\/articles\/microservices-inside-out"}]}]}]}