每日分享最新，最流行的軟件開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支持，跪求關注，點贊，留言。
如何使用 Apache Kafka 實現請求-響應消息交換模式，優缺點，以及與 CQRS 和事件溯源的比較。
如何與 Apache Kafka 進行請求-響應通信？這是我經常收到的最常見的問題之一。這篇博文探討了何時（不）使用這種消息交換模式、同步和異步通信之間的區別、與 CQRS 和事件溯源相比的優缺點，以及如何在數據流基礎架構中實現請求-響應。
Apache Kafka 數據流中的消息隊列模式
在我開始這篇文章之前，我想讓你知道這個內容是關于“JMS、消息隊列和 Apache Kafka”的博客系列的一部分：
- JMS 消息代理與 Apache Kafka 數據流的10 個比較標準
- 通過Apache Kafka 中的死信隊列 (DQL)進行錯誤處理的替代方案
- 這篇文章——使用 Apache Kafka實現請求-回復模式
- 即將推出——用于選擇正確消息系統的決策樹（JMS 與 Apache Kafka）
- 即將推出——從 JMS 消息代理到 Apache Kafka：集成、遷移和/或替換
我會盡快在此處鏈接其他帖子。
什么是請求-響應（Request-reply）消息交換模式？
請求-響應（有時稱為請求-答復）是計算機在網絡中用于相互通信的主要方法之一。
第一個應用程序發送一些數據的請求。第二個應用程序響應請求。它是一種消息交換模式，其中請求者向回復者系統發送請求消息，回復者系統接收并處理請求，最終返回消息作為響應。
請求-回復效率低下，并且根據用例可能會遭受很多延遲。HTTP 或更好的 gRPC 適用于某些用例。請求-回復 被 CQRS（命令和查詢責任分離）模式“替換”為流數據的 Kafka。CQRS 在 JMS API 中是不可能的，因為 JMS 不提供狀態功能并且缺乏事件溯源功能。讓我們更深入地研究這些陳述。
請求-響應 (HTTP) 與數據流 (Kafka)
在討論同步和異步通信之前，讓我們探討一下請求-響應和數據流背后的概念。傳統上，這是兩種不同的范式：
請求-響應 (HTTP)：
- 通常是同步的
- 點對點
- 高延遲（與數據流相比）
- 預定義 API
- 連續加工
- 通常是異步的
- 事件驅動
- 低延遲
- 通用事件
大多數架構需要點對點通信（例如，服務器和移動應用程序之間）的請求-響應和連續數據處理的數據流。考慮到這一點，讓我們看看 HTTP 與 Kafka 一起使用的用例。
同步與異步通信
請求-響應消息交換模式通常是純粹同步實現的。然而，請求-響應也可以異步實現，響應在某個未知的稍后時間返回。
讓我們看一下最流行的消息交換示例：REST、消息隊列和數據流。
同步 Restful API (HTTP)
Web 服務是應用程序開發和企業應用程序集成中同步通信背后的主要技術。雖然多年前 WSDL 和 SOAP 占主導地位，但REST/HTTP 是當今幾乎所有 Web 服務中的通信標準。
我不會在這篇文章中討論“HTTP 與 REST”的爭論。簡而言之，REST（Representational state transfer）已被整個軟件行業所采用，并且是一套被廣泛接受的用于創建無狀態、可靠的 Web API 的指南。遵循 REST 約束的 Web API 被非正式地描述為 RESTful。RESTful Web API 通常松散地基于 HTTP 方法。
通過 HTTP 進行的同步 Web 服務調用保持連接打開并等待響應傳遞或超時期限到期。
HTTP Web 服務的延遲比較高。使用 HTTP 時，它需要為每個請求-響應迭代設置和斷開 TCP 連接。需要明確的是：對于許多用例來說，延遲仍然足夠好。
另一個可能的缺點是 HTTP 請求可能會阻塞等待隊列頭請求被處理，并且如果有太多未完成的 HTTP 請求，可能需要在服務器上設置 HTTP 斷路器。
異步消息隊列（IBM MQ、RabbitMQ）
消息隊列范式是發布者/訂閱者設計模式的兄弟，通常是更廣泛的面向消息的中間件系統的一部分。大多數消息傳遞系統在其 API 中同時支持發布者/訂閱者和消息隊列模型，例如 JAVA 消息服務 (JMS)。如果您不熟悉此討論，請閱讀“ JMS 消息隊列與 Apache Kafka ”一文。
生產者和消費者相互解耦，異步通信。消息隊列存儲事件，直到它們被成功消費。
大多數消息隊列中間件產品都提供了內置的請求-響應 API。它的通信是異步的。該實現使用相關 ID。
請求-響應 API（例如，在 JMS 中）通過從請求中獲取回復端點來創建一個臨時隊列或主題，該隊列或主題在請求中被引用以供消費者使用。ID 用于將請求與單個請求者分開。這些隊列或主題也僅在請求者與回復會話處于活動狀態時可用。
這種帶有臨時隊列或主題的實現在 Kafka 中沒有意義。我實際上已經看到企業試圖這樣做。卡夫卡不是那樣工作的。結果是 Kafka 集群中有太多的分區和主題。結果是可擴展性和性能問題。
異步數據流 (Apache Kafka)
數據流持續處理來自數據源的攝取事件。此類數據應使用流處理技術進行增量處理，而無需訪問所有數據。
異步通信范式類似于消息隊列。與消息隊列相反，數據流提供了事件的長期存儲和歷史信息的可重放性。結果是生產者和消費者之間真正的脫鉤。在大多數 Apache Kafka 部署中，具有非常不同的通信范式和延遲能力的多個生產者和消費者發送和讀取事件。
Apache Kafka 不提供內置的請求-響應 API。 正如有些人認為的那樣，這不一定是壞事。數據流提供不同的設計模式。 這就是這篇博文的主要原因！讓我們探索消息系統中請求-響應模式的權衡，并了解更適合數據流世界的替代方法。但是這篇文章也探討了如何使用 Kafka 實現異步或同步請求-回復。
但請記住：不要重復使用您關于 HTTP 和 MQ 的“遺留知識”，并嘗試使用 Apache Kafka 重新構建相同的模式。話雖如此，Kafka 也可以實現請求-響應。更多關于這方面的內容在以下部分中。
請求-回復與 CQRS 和事件溯源
CQRS (Command Query Responsibility Segregation)規定，每個方法要么是執行操作的命令，要么是向調用者返回數據的查詢，但不能同時是兩者。服務變得真正相互分離。
Martin Fowler 有一個很好的 CQRS 圖表。
事件溯源是一種架構模式，其中實體不使用直接序列化或對象關系映射來跟蹤其內部狀態，而是通過讀取事件并將其提交到事件存儲。
當事件溯源與 CQRS 和域驅動設計相結合時，聚合根負責驗證和應用命令（通常通過從命令處理程序調用它們的實例方法），然后發布事件。
使用 CQRS，狀態會根據每個相關的事件消息進行更新。因此，狀態總是已知的。查詢存儲在物化視圖（例如，Kafka Streams 中的 KTable）中的狀態是有效的。對于請求響應，服務器必須計算或確定每個請求的狀態。使用 CQRS，它只計算/更新一次，而不管相關發生時的狀態查詢數量如何。
這些原則完全適合數據流世界。Apache Kafka 是一種分布式存儲，可將傳入事件附加到不可變提交日志中。開箱即用的 Kafka 基礎設施中內置了真正的事件解耦和可重放性。大多數具有領域驅動設計的現代微服務架構都是使用 Apache Kafka 構建的，而不是 REST 或 MQ。
如果不需要，不要在 Kafka 中使用 Request-Response！
如果您構建現代企業架構和新應用程序，請應用最適合該技術的自然設計模式。請記住：數據流是一種不同于 Web 服務和消息隊列的技術！帶有事件溯源的 CQRS是 Kafka 世界中大多數用例的最佳模式。
如果你沒有必要，不要在 Kafka 中使用請求-響應概念！Kafka 是為流數據和真正解耦各種生產者和消費者而構建的。
即使對于事務性工作負載也是如此。事務不需要同步通信。Kafka API 支持關鍵任務事務（盡管它本質上是異步的和分布式的）。考慮進行銀行付款。它從不是同步的，而是一個復雜的業務流程，在組織內部和跨組織中包含許多獨立事件。
Apache Kafka 的同步與異步請求響應
在我解釋過請求-響應不應該是構建新的 Kafka 應用程序時的第一個想法之后，這并不意味著它是不可能的。有時，它是解決問題的更好、更簡單或更快的方法。因此，讓我們看一下使用 Kafka 實現同步和異步請求-響應的示例。
請求-回復模式可以用 Kafka 來實現。但不一樣。嘗試像在 JMS 消息代理中那樣做（帶有臨時隊列等）最終會殺死 Kafka 集群（因為它的工作方式不同）。盡管如此，使用的概念與 JMS API 中的概念相同，例如相關 ID。
Apache Kafka 的異步請求-響應
Spring 項目及其Kafka Spring Boot Kafka 模板庫有一個很好的使用 Kafka 構建的異步請求-回復模式的示例。查看“ org.springframework.kafka.requestreply.ReplyingKafkaTemplate ”。它使用 Kafka API 輕松創建請求/回復應用程序。該示例很有趣，因為它實現了異步請求/回復，如果您使用例如 JMS API，則編寫起來會更復雜）。
Spring 的優點在于 易于使用的模板和方法簽名的可用性。該框架允許使用沒有自定義代碼的設計模式來實現它們。例如，以下是使用 Kafka 進行請求-回復的兩種 Java 方法：
爪哇1RequestReplyFuture < K , V , R > sendAndReceive ( ProducerRecord < K , V > 記錄); 2RequestReplyFuture < K , V , R > sendAndReceive ( ProducerRecord < K , V > record , Duration replyTimeout );
結果是ListenableFuture異步填充的結果（或異常，超時）。結果還有一個sendFuture屬性，它是調用的結果KafkaTemplate.send()。您可以使用這個未來來確定發送操作的結果。
Apache Kafka 的同步請求-響應
另一篇優秀的 DZone 文章討論了使用 Spring Kafka模板的同步請求/回復。該示例顯示了一個Kafka 服務，它通過同步請求-響應行為計算兩個數字的總和以返回結果：
Spring 自動在生產者記錄中設置相關 ID。@SendTo此關聯 ID 由消費者端的注釋按原樣返回。
查看DZone 帖子以獲取完整的代碼示例。
Kafka 模板的 Spring 文檔有很多關于 Kafka 的請求/回復模式的詳細信息和代碼示例。使用 Spring，使用 Kafka 實現請求/回復模式非常簡單。如果您不使用 Spring，您可以學習如何在您的框架中使用 Kafka 進行請求-回復。 這就是開源的美妙之處……
數據流和 Rest API 的結合
上面的示例展示了如何使用 Apache Kafka 實現請求-響應模式。盡管如此，它仍然只是次優方法，并且通常是流數據的反模式。 數據 流和請求響應 REST API 通常結合使用，以充分利用兩者。我寫了一篇關于“使用 Apache Kafka 的 HTTP 和 REST API 的用例和架構”的專門博客文章。
Apache Kafka 和 API 管理
一種非常常見的方法是使用 Kafka 生態系統大規模實時實施應用程序，然后在頂部放置一個 API 管理層以將事件作為 API 公開給外部世界（另一個內部業務域或 B2B 3rd 方應用程序） ）。
這是連接 SAP 數據的示例。SAP 有數十種與 Kafka 集成的選項，包括 Kafka Connect 連接器、REST/HTTP、專有 API 或 3rd 方中間件。
無論您如何將數據獲取到流數據中心，在右側，Kafka REST API 用于通過 HTTP 公開事件。API 管理解決方案在Kafka 接口之上處理安全和貨幣化/計費要求：
在博客文章“ Apache Kafka 和 API 管理/API 網關 – 朋友、敵人還是敵人？ ”中閱讀有關此討論的更多信息。它涵蓋了 Apache Kafka 和 API 管理平臺（如 Kong、MuleSoft Anypoint 或 google 的 Apigee）之間的關系。
使用 Apache Kafka 進行內部和外部數據共享的流交換
在討論了 API、請求-響應通信和 Kafka 之間的關系之后，讓我們來探討一下市場上的一個重要趨勢：Data Mesh（流行語）和用于實時數據共享的流交換（問題解決者）。
數據網格是一種新的架構范式，近來備受關注。沒有任何一種技術可以完美地構建數據網格。像 Apache Kafka 這樣的開放且可擴展的去中心化實時平臺通常是 Data Mesh 基礎架構的核心，并輔以許多其他數據平臺來解決業務問題。
流原生數據共享而不是在中間使用請求-響應和 REST API 是許多用例的自然演變：
在“使用 Kafka 和動態數據網格進行流式數據交換”一文中了解更多信息。
一起使用數據流和請求響應！
大多數架構需要點對點通信（例如，服務器和移動應用程序之間）的請求-響應和連續數據處理的數據流。
可以使用 Apache Kafka 實現同步和異步請求-響應通信。但是，CQRS 和事件溯源在大多數情況下是更好、更自然的數據流方法。了解不同的選項及其權衡，并為工作使用正確的工具（在這種情況下，是正確的設計模式）。
