微服務消息代理選型:Redis、Kafka、RabbitMQ
在為微服務使用異步通信時,通常使用消息代理。代理確保不同微服務之間的通信可靠穩定,消息在系統內得到管理和監控,并且消息不會丟失。您可以從幾個消息代理中選擇,它們的規模和數據功能各不相同。這篇博文將比較三個最受歡迎的代理brokers:RabbitMQ、 Kafka 和 Redis 。
但首先,讓我們了解一下微服務通信。
微服務通信:同步和異步
微服務之間有兩種常見的通信方式:同步和異步。在同步通信中,調用方在發送下一條消息之前等待響應,它作為HTTP之上的REST協議運行。相反,在異步通信中,消息是在不等待響應的情況下發送的。這適用于分布式系統,通常需要消息代理來管理消息。
您選擇的通信類型應考慮不同的參數,如如何構造微服務、設置什么基礎設施、延遲、規模、依賴性和通信目的。異步通信的建立可能更加復雜,并且需要向堆棧中添加更多的組件,但是將異步通信用于微服務的優點大于缺點。
異步通信優勢
首先也是最重要的是,異步通信從定義上講是無阻塞的。它還支持比同步操作更好的擴展。第三,在微服務崩潰的情況下,異步通信機制提供了各種恢復技術,通常更好地處理與崩潰相關的錯誤。此外,當使用代理而不是REST協議時,接收通信的服務實際上不需要相互了解。甚至可以在舊服務運行很長時間后引入新服務,即更好的解耦服務。
最后,在選擇異步操作時,您可以提高將來創建中心發現、監視、負載平衡甚至策略實施器的能力。這將為您的代碼和系統構建提供靈活性、可伸縮性和更多功能。
選擇正確的消息代理
異步通信通常通過消息代理進行管理。還有其他方法,比如aysncio,但它們更為稀缺和有限。
在選擇執行異步操作的代理時,應考慮以下幾點:
1. Broker Scale–系統中每秒發送的消息數。
2. 數據持久性–恢復消息的能力。
3. 消費者能力–brokers是否能夠管理一對一和/或一對多消費者。
一對一:
一對多:
我們查看了最新和最好的服務,以找出這三個類別中哪家提供商最強。
比較不同的消息代理
RabbitMQ(AMQP)
規模:根據配置和資源,這里的大概速度約為每秒50K味精。
持久化:支持持久性和暫時性消息。
一對一vs一對多消費者:兩者皆有。
RabbitMQ于2007年發布,是首批創建的通用消息代理之一。它是一個開源軟件,通過實現高級消息隊列協議(AMQP),通過點對點和發布子方法來傳遞消息。它旨在支持復雜的路由邏輯。
有一些托管服務允許您將其用作SaaS,但它不是本機主要云提供商堆棧的一部分。RabbitMQ支持所有主要語言,包括Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift等。
在持久模式下可能會出現一些性能問題。
Kafka
規模:每秒最多可發送數百萬條消息。
持久化:是的。
一對一vs一對多消費者:只有一對多(乍一看似乎很奇怪,對吧?!)。
Kafka由Linkedin于2011年創建,用于處理高吞吐量、低延遲的處理。作為一個分布式流媒體平臺,Kafka復制了發布-訂閱服務。它提供數據持久性并存儲記錄流,使其能夠交換高質量的消息。
Kafka在Azure、AWS和Confluent上管理SaaS。他們都是Kafka計劃的創造者和主要貢獻者。Kafka支持所有主要語言,包括Python、Java、C/C++、Clojure、.NET、PHP、Ruby、JavaScript、Go、Swift等。
Redis
規模:每秒最多可發送一百萬條消息。
持久化:基本上不是——它是內存中的數據存儲。
一對一vs一對多消費者:兩者皆有。
Redis與其他消息代理稍有不同。Redis的核心是內存中的數據存儲,可以用作高性能鍵值存儲或消息代理。另一個區別是Redis沒有持久性,而是將其內存轉儲到磁盤/DB中。它也非常適合實時數據處理。
最初,Redis不是一對一和一對多。然而,自從Redis 5.0推出pub-sub以來,功能得到了提升,一對多成為了一種現實選擇。
每個用例的消息代理
我們介紹了RabbitMQ、卡夫卡和Redis的一些特性。這三種動物都屬于這一類,但如上所述,它們的運作方式截然不同。下面是我們根據不同的用例為正確的MessageBroker提供的建議。
短消息:Redis
Redis的內存數據庫幾乎完全適合于不需要持久性的短消息用例。因為它提供了極快的服務和內存功能,Redis是短保留消息的完美選擇,在短保留消息中,持久性并不重要,您可以容忍一些損失。隨著Redis streams在5.0中的發布,它也是一對多用例的候選者,這是由于限制和舊的發布訂閱功能而絕對需要的。
大量數據:Kafka
Kafka是一個高吞吐量的分布式隊列,用于長時間存儲大量數據。Kafka非常適合于需要持久性的一對多用例。
復雜路由:RabbitMQ
RabbitMQ是一個較老但成熟的代理,具有許多支持復雜路由的特性和功能。當所需速率不高(超過數萬msg/秒)時,它甚至支持復雜的路由通信。
考慮你的軟件棧
當然,最后要考慮的是您當前的軟件堆棧。如果您正在尋找一個相對簡單的集成過程,并且不希望在堆棧中維護不同的代理,那么您可能更傾向于使用堆棧已經支持的代理。
例如,如果您在RabbitMQ之上的系統中使用芹菜作為任務隊列,您將有動力使用RabbitMQ或Redis,而不是Kafka,后者不受支持,需要一些重寫。