對微服務使用異步通信時，通常使用消息代理。代理確保不同微服務之間的通信可靠且穩定，消息在系統內得到管理和監控，并且消息不會丟失。您可以從幾個消息代理中進行選擇，它們的規模和數據功能各不相同。這篇博文將比較三種最受歡迎的代理：RabbitMQ、Kafka 和 Redis。

微服務通信：同步和異步

微服務之間有兩種常見的通信方式：同步和異步。在同步通信中，調用者在發送下一條消息之前等待響應，它作為 HTTP 之上的 REST 協議運行。相反，在異步通信中，消息是在不等待響應的情況下發送的。這適用于分布式系統，通常需要消息代理來管理消息。

您選擇的通信類型應考慮不同的參數，例如您如何構建微服務、您擁有的基礎設施、延遲、規模、依賴關系和通信目的。異步通信的建立可能更復雜，需要向堆棧中添加更多組件，但對微服務使用異步通信的優點大于缺點。

異步通信優勢

首先，異步通信根據定義是非阻塞的。它還支持比同步操作更好的擴展。第三，在微服務崩潰的情況下，異步通信機制提供了各種恢復技術，并且通常更擅長處理與崩潰有關的錯誤。此外，當使用代理而不是 REST 協議時，接收通信的服務實際上不需要相互了解。甚至可以在舊服務運行很長時間后引入新服務，即更好的解耦服務。

最后，在選擇異步操作時，您可以提高未來創建中央發現、監控、負載平衡甚至策略執行器的能力。這將為您的代碼和系統構建提供靈活性、可擴展性和更多功能。

選擇正確的消息代理

異步通信通常通過消息代理進行管理。還有其他方法，例如 aysncio，但它們更加稀缺和有限。

在選擇代理來執行異步操作時，您應該考慮以下幾點：

Broker Scale — 系統中每秒發送的消息數。

數據持久性——恢復消息的能力。

消費者能力——經紀人是否能夠管理一對一和/或一對多的消費者。

一對一

一對多

我們檢查了最新和最好的服務，以找出這三個類別中最強大的提供商。

比較不同的消息代理

RabbitMQ (AMQP)

規模：

根據配置和資源，這里的大概是每秒 50K msg。

持久性：

支持持久性和瞬態消息。

一對一與一對多消費者：

兩者兼而有之。

RabbitMQ 于 2007 年發布，是最早創建的通用消息代理之一。它是一個開源軟件，通過實現高級消息隊列協議 (AMQP)，通過點對點和發布-訂閱方法傳遞消息。它旨在支持復雜的路由邏輯。

有一些托管服務允許您將其用作 SaaS，但它不是本地主要云提供商堆棧的一部分。RabbitMQ 支持所有主要語言，包括 Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift 等。

在持久模式下會出現一些性能問題。

卡夫卡

規模：

每秒最多可以發送一百萬條消息。

持久化：

是的。

一對一 vs 一對多消費者：

只有一對多(乍一看似乎很奇怪，對吧?!)。

Kafka 由 Linkedin 于 2011 年創建，用于處理高吞吐量、低延遲的處理。作為分布式流媒體平臺，Kafka 復制了發布訂閱服務。它提供數據持久性并存儲記錄流，使其能夠交換質量消息。

Kafka 在 Azure、AWS 和 Confluent 上管理了 SaaS。他們都是Kafka項目的創造者和主要貢獻者。Kafka 支持所有主要語言，包括 Python、Java、C/C++、Clojure、.NET、PHP、Ruby、JavaScript、Go、Swift 等。

Redis

規模：

每秒最多可以發送一百萬條消息。

持久性：

基本上，沒有——它是一個內存中的數據存儲。

一對一與一對多消費者：

兩者兼而有之。

Redis 與其他消息代理略有不同。從本質上講，Redis 是一種內存中數據存儲，可用作高性能鍵值存儲或消息代理。另一個區別是 Redis 沒有持久性，而是將其內存轉儲到磁盤/數據庫中。它也非常適合實時數據處理。

最初，Redis 不是一對一和一對多的。然而，自從 Redis 5.0 引入了 pub-sub，功能得到了提升，一對多成為了一個真正的選擇。

每個消息代理的用例

我們介紹了 RabbitMQ、Kafka 和 Redis 的一些特性。這三者都是同類中的野獸，但正如所描述的，它們的運作方式大不相同。以下是我們針對不同用例使用的正確消息代理的建議。

短命消息：Redis

Redis 的內存數據庫幾乎非常適合具有不需要持久性的短期消息的用例。因為它提供極快的服務和內存中的功能，Redis 是短保留消息的完美候選者，在這種情況下，持久性不是那么重要，您可以容忍一些損失。隨著 5.0 中 Redis 流的發布，它也是一對多用例的候選者，由于限制和舊的 pub-sub 功能，這是絕對需要的。

海量數據：Kafka

Kafka 是一個高吞吐量的分布式隊列，專為長時間存儲大量數據而構建。Kafka 非常適合需要持久性的一對多用例。

復雜路由：RabbitMQ

RabbitMQ 是一個較舊但成熟的代理，具有許多支持復雜路由的特性和功能。當要求的速率不高(超過幾萬條消息/秒)時，它甚至會支持復雜的路由通信。

考慮您的軟件堆棧

當然，最后要考慮的是您當前的軟件堆棧。如果您正在尋找一個相對簡單的集成過程，并且您不想在一個堆棧中維護不同的代理，您可能更傾向于使用您的堆棧已經支持的代理。

例如，如果您在 RabbitMQ 之上的系統中使用 Celery for Task Queue，您將有動力使用 RabbitMQ 或 Redis，而不是 Kafka，后者不受支持并且需要一些重寫。