[[420340]]

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

但首先，讓我們了解一下微服務(wù)通信。

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

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

您選擇的通信類型應(yīng)考慮不同的參數(shù)，如如何構(gòu)造微服務(wù)、設(shè)置什么基礎(chǔ)設(shè)施、延遲、規(guī)模、依賴性和通信目的。異步通信的建立可能更加復(fù)雜，并且需要向堆棧中添加更多的組件，但是將異步通信用于微服務(wù)的優(yōu)點大于缺點。

異步通信優(yōu)勢

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

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

選擇正確的消息代理

異步通信通常通過消息代理進(jìn)行管理。還有其他方法，比如aysncio，但它們更為稀缺和有限。

在選擇執(zhí)行異步操作的代理時，應(yīng)考慮以下幾點：

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

2. 數(shù)據(jù)持久性–恢復(fù)消息的能力。

3. 消費者能力–brokers是否能夠管理一對一和/或一對多消費者。

一對一：

一對多：

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

比較不同的消息代理

RabbitMQ（AMQP）

規(guī)模：根據(jù)配置和資源，這里的大概速度約為每秒50K味精。

持久化：支持持久性和暫時性消息。

一對一vs一對多消費者：兩者皆有。

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

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

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

Kafka

規(guī)模：每秒最多可發(fā)送數(shù)百萬條消息。

持久化：是的。

一對一vs一對多消費者：只有一對多（乍一看似乎很奇怪，對吧？！）。

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

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

Redis

規(guī)模：每秒最多可發(fā)送一百萬條消息。

持久化：基本上不是——它是內(nèi)存中的數(shù)據(jù)存儲。

一對一vs一對多消費者：兩者皆有。

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

最初，Redis不是一對一和一對多。然而，自從Redis 5.0推出pub-sub以來，功能得到了提升，一對多成為了一種現(xiàn)實選擇。

每個用例的消息代理

我們介紹了RabbitMQ、卡夫卡和Redis的一些特性。這三種動物都屬于這一類，但如上所述，它們的運作方式截然不同。下面是我們根據(jù)不同的用例為正確的MessageBroker提供的建議。

短消息：Redis

Redis的內(nèi)存數(shù)據(jù)庫幾乎完全適合于不需要持久性的短消息用例。因為它提供了極快的服務(wù)和內(nèi)存功能，Redis是短保留消息的完美選擇，在短保留消息中，持久性并不重要，您可以容忍一些損失。隨著Redis streams在5.0中的發(fā)布，它也是一對多用例的候選者，這是由于限制和舊的發(fā)布訂閱功能而絕對需要的。

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

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

復(fù)雜路由：RabbitMQ

RabbitMQ是一個較老但成熟的代理，具有許多支持復(fù)雜路由的特性和功能。當(dāng)所需速率不高（超過數(shù)萬msg/秒）時，它甚至支持復(fù)雜的路由通信。

考慮你的軟件棧

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

例如，如果您在RabbitMQ之上的系統(tǒng)中使用芹菜作為任務(wù)隊列，您將有動力使用RabbitMQ或Redis，而不是Kafka，后者不受支持，需要一些重寫。