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

微服務(wù)通信：同步和異步

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

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

異步通信優(yōu)勢

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

最后，在選擇異步操作時，您可以提高未來創(chuàng)建中央發(fā)現(xiàn)、監(jiān)控、負載平衡甚至策略執(zhí)行器的能力。這將為您的代碼和系統(tǒng)構(gòu)建提供靈活性、可擴展性和更多功能。

選擇正確的消息代理

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

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

Broker Scale — 系統(tǒng)中每秒發(fā)送的消息數(shù)。

數(shù)據(jù)持久性——恢復消息的能力。

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

一對一

一對多

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

比較不同的消息代理

RabbitMQ (AMQP)

規(guī)模：

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

持久性：

支持持久性和瞬態(tài)消息。

一對一與一對多消費者：

兩者兼而有之。

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

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

在持久模式下會出現(xiàn)一些性能問題。

卡夫卡

規(guī)模：

每秒最多可以發(fā)送一百萬條消息。

持久化：

是的。

一對一 vs 一對多消費者：

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

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

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

Redis

規(guī)模：

每秒最多可以發(fā)送一百萬條消息。

持久性：

基本上，沒有——它是一個內(nèi)存中的數(shù)據(jù)存儲。

一對一與一對多消費者：

兩者兼而有之。

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

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

每個消息代理的用例

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

短命消息：Redis

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

海量數(shù)據(jù)：Kafka

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

復雜路由：RabbitMQ

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

考慮您的軟件堆棧

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

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