開源 VS 商業，訊息中介軟體你不知道的那些事

標籤：

11月23日，新炬網路中介軟體技術專家劉拓老師在DBA+社群中介軟體使用者組進行了一次主題為“開源 VS 商業，訊息中介軟體你不知道的那些事”的線上分享。小編特別整理出其中精華內容，供大家學習交流。

 

 

嘉賓簡介  

 

• 新炬網路中介軟體技術專家

• 曾任職於IBM華南GTS 4年，IBM WebSphere、MQ、CICS產品線技術專家

• 5年行動電信業者（廣東移動、浙江移動）營運經驗，3年JAVA開發及售後經驗

 

演講實錄  

 

隨著雲端運算的興起，Docker、微服務的流行，分布式訊息佇列技術成為雲端運算平台中不可或缺的組件。今天由我來給大家分享下目前市場上主流的商業、開源訊息中介軟體之間的區別。

 

什麼是訊息中介軟體MOM（Message Oriented Middleware）利用高效可靠的訊息傳遞機制進行平台無關的資料交流，並基於資料通訊來進行分布式系統的整合。通過提供訊息傳遞和訊息排隊模型，它可以在分布式環境下擴充進程間的通訊。

 

 

• 非同步：基於儲存轉寄機制的非同步通訊方式，寄件者將訊息發送給Message Service器，Message Service器將訊息存放在若干隊列中，在合適的時候再將訊息轉寄給接收者。

 

• 松耦合：客戶和服務物件的生命週期松耦合，由MOM來保障訊息佇列及服務，二者的生命週期無需相同，即發送訊息的時候接收者不一定運行，接收訊息的時候寄件者也不一定運行。

 

• 可靠性：由MOM來保障訊息不會因網路連接異常斷開、進程異常重啟等各種原因導致訊息丟失。

 

訊息傳遞模式分為PTP和Pub/Sub兩種模式。

 

 

PTP（Point–to-Point）

• 每條訊息只有一個消費者。

• 寄件者和接收者沒有時間依賴（no timing dependencies）。

• 接受者成功接收回覆機制。

 

 

Pub/Sub（Publish/Subscribe）

• 每條訊息可以有多個訂閱者。

• 寄件者和接受者之間必須同步，用戶端只有訂閱後才能收到訊息。

 

訊息中介軟體有著非同步通知、資料複製、日誌同步、延遲隊列、廣播通知五大適用業務情境。

 

• 非同步通知：為面向服務架構（SOA）提供分散式交易支援；保證全域資料一致性。比如訂單處理調度通知，訂單拆解後發送開通、計費、賬處等到期提醒，辦理告知簡訊，訂單狀態，二次確認等。

• 資料複製：利用訊息中介軟體將資料從源頭複製到多個目的地；滿足搜尋、離線分析和分表規則變化等需求。如系統間TF資料同步多系統，局資料增量發布等。

• 日誌同步：應用通過可靠非同步方式將日誌同步到訊息中介軟體；可以對日誌做即時或離線分析。如統一日誌平台中心日誌入庫等。

• 延遲隊列：把訊息中介軟體當做可靠的延遲隊列；分布式環境下的定時器。如受理訂單入庫，系統日誌入庫等高頻率DB寫入情境。

• 廣播通知：可靠的叢集內廣播通知；用於通知緩衝失效等事件。如產品緩衝重新整理等。

 

訊息協議JMS VS AMQP

 

 

JMS提供了兩種訊息模型，peer-2-peer(點對點)以及publish-subscribe（發布訂閱）模型。在JMS中，訊息路由非常簡單，由producer和consumer連結到同一個queue（p2p）或者topic（pub/sub）來實現訊息的路由。JMSconsumer同時支援message selector（訊息選取器，通過訊息選取器，consumer可以只消費那些通過了selector篩選的訊息。

 

 

AMQP是一種協議，更準確的說是一種binary wire-level protocol（連結協議）。這是其和JMS的本質差別。AMQP不從API層進行限定，而是直接定義網路交換的資料格式。這使得實現了AMQP的provider天然性就是跨平台的。

 

在AMQP中，訊息路由（messagerouting）和JMS存在一些差別，在AMQP中增加了Exchange和binding的角色。producer將訊息發送給Exchange，binding決定Exchange的訊息應該發送到那個queue，而consumer直接從queue中消費訊息。queue和exchang的bind有consumer來決定。

 

市場上目前主流的訊息中介軟體有IBM MQ、WebLogic JMS、ActiveMQ、Rabbit MQ、Rocket MQ、Apollo等。

 

• IBM  MQ：WebSphere MQ是IBM業務整合基礎性產品，以其獨特的安全機制、簡便快速的編程風格、高穩定性、可擴充性和跨平台性，以及強大的交易處理能力和訊息通訊能力，成為業界市場佔有率最高的訊息中介軟體產品。

• WebLogic JMS：WebLogic JMS是Oracle公司一個高效能、叢集的Messaging Server，基於WebLogic產品，支援資料庫和檔案持久化，完全支援XA事務。

• RocketMQ：RocketMQ是阿里開源的分布式、隊列模型的訊息中介軟體，支援嚴格的訊息順序；支援Topic與Queue兩種模式；億級訊息堆積能力；比較友好的分布式特性；同時支援Push與Pull方式消費訊息。

• ActiveMQ：ActiveMQ是目前市場上非常流行的開源訊息傳遞和整合服務器。它的訊息傳遞速度非常快，支援多種跨平台的用戶端和協議，非常容易構建企業級的整合模式，同時支援JMS1.1和J2EE1.4規範。ActiveMQ基於Apache2.0許可。

• Apollo：Apollo是以ActiveMQ原型為基礎，是一個更快、更可靠、更易於維護的訊息代理工具，Apache稱Apollo為最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向訊息協議）伺服器。

• RabbitMQ：RabbitMQ是AQMP協議用Erlang實現的訊息佇列產品，它實現了代理（Broker）架構，訊息在發送到用戶端之前可以在中央節點上排隊。此特性使得RabbitMQ便於使用和部署，適宜於很多情境如路由、負載平衡或訊息持久化等。

 

 

這是某團隊各產品功能和效能對比的最終結果，從結果來看：

 

ActiveMQ各功能模組相對完善，不支援叢集控制台管理，在訂閱模式效能測試（10K及以下訊息大小）領先其他產品。

 

IBM WMQ有最完善的功能點實現，在點對點模式讀寫混合效能測試中領先其他產品。

 

Oracle JMS是Weblogic的組件，非獨立產品，各功能模組相對完善，在點對點模式純讀取效能測試中領先其他產品，不支援AMQP訊息協議。

 

RabbitMQ有獨特的鏡像隊列功能，能支援分布式記憶體複製實現持久化，在分布式擴充方面相對有優勢，控制台實現效能監控非常豐富。

 

RocketMQ功能模組支援較差，實現的訊息協議是自訂的文本傳輸協議，在1M訊息大小的效能測試中領先其他產品。

 

Apollo產品成熟度等級不夠，不支援叢集模式（訊息路由）。

 

 

商業產品中IBM WMQ產品成熟度等級高，實現功能完整，應用廣泛，相容性強，跨平台和跨語言支援較好；Oracle JMS是基於WebLogic的一個組件，僅支援JMS和WebLogic T3訊息協議，不支援AMQP協議，跨平台支援有待完善。開源產品中ActiveMQ最成熟、功能最完善。

 

準系統專題分析

 

• 總體來看，各產品在C/C++語言用戶端API、訊息優先順序實現相對較好。

• RocketMQ不支援使用者名稱和密碼認證、死信機制、訊息有效期間功能。

 

 

準系統——語言和協議支援

 

 

準系統——使用者名稱密碼認證：主要通過建立使用者名稱和密碼，使用JMS用戶端進行串連嘗試，實現使用者名稱密碼不一致的情況是否允許串連。

 

• IBM WMQ由隊列管理器、隊列、通道各部分組成，可通過介面對每個組成部分都進行存取控制。

• Oracle JMS訊息佇列基於AdminServer執行個體，可通過介面添加使用者，指定JMS訊息佇列的存取控制。

• RabbitMQ是根據業務劃分不同的virtual hosts進行存取控制。

• RocketMQ不支援使用者名稱密碼認證。

• ActiveMQ / Apollo支援主題和隊列兩種模式的存取控制。

 

準系統——死信機制：主要通過測試訊息在傳遞失敗或訊息到期時是否可以標記為死信。

 

• IBM WMQ、Oracle JMS、RabbitMQ、ActiveMQ均支援讀取異常、訊息到期兩種死信機制。

• RocketMQ不支援訊息死信機制。

• Apollo只支援訊息到期模式，可設定redelivered參數，當超過maximumRedeliveries（預設為6次）次數時，訊息會放入無效信件佇列。

 

準系統——訊息有效期間：主要通過在JMS用戶端設定訊息存留時間，在存留時間結束後啟動消費者，訊息是否被丟棄或銷毀。

 

• 除RocketMQ之外的產品均支援訊息有效期間配置。

• RabbiMQ訊息有效期間最長保留時間為2^32-1毫秒。

• RocketMQ支援隊列有效期間設定，當磁碟空間不夠時會刪除建立時間最久的持久化檔案。

 

準系統——訊息優先順序：主要通過在JMS用戶端發送一組訊息，是否可配置訊息的優先順序，是否可按訊息的優先順序進行處理。

 

• IBM WMQ、Oracle JMS、ActiveMQ、Apollo均支援訊息優先順序和隊列優先順序配置。

• RabbitMQ、RocketMQ不支援訊息優先順序配置，只支援隊列優先順序配置，即配置一個優先順序高的隊列，和一個普通優先順序的隊列，將優先順序不同的訊息發往不同隊列進行處理。

 

營運管理專題分析

 

• 總體來看，各產品在營運管理模組實現都較為完善，沒有明顯短板。

• 商業產品在管理工具和日誌系統相對較為完善。

• RabbitMQ監控系統的功能實現更為豐富。

 

 

營運管理——管理工具：在管理介面測試是否可以進行隊列的建立、刪除、啟動等準系統。

 

• 商業產品在管理介面上支援較為完善，能通過管理介面進行隊列的建立、刪除及隊列的啟停等動作。

• 開源產品在管理介面上只支援隊列的建立、刪除，不支援隊列的啟停等動作。

• IBM WMQ、Oracle有完善的設定檔、命令列、介面支援。

• RabbitMQ、RocketMQ管理介面不支援隊列的啟停，可通過命令列、介面實現，支援Rest API介面。

• ActvieMQ / Apollo管理介面除不支援隊列的啟停外，不支援集中化管理，通過JMX設定檔實現，支援Rest API介面。

 

營運管理——日誌系統：可以修改執行個體的記錄層級，使其可以記錄系統的重要事件，比如新的入站串連、新訊息入站等。

 

• 商業產品在日誌系統上做得最為完善，日誌配置也比較簡單。

• 開源產品在訊息可見度、日誌分割支援力度不夠。

• RabbitMQ基於AMQP協議，不支援第三方Log4j的日誌列印實現。

• RocketMQ不支援TRACE日誌跟蹤。

 

營運管理——監控系統：可監控訊息中介軟體運行狀態，可監控到叢集內所有節點隊列數、隊列中訊息數、出入隊訊息數、串連數等。

 

• RabbitMQ在監控系統模組表現最為優秀，叢集效能、隊列效能、訊息發送次數、持久化大小、TPS效能等均有豐富的實現。

• RocketMQ不支援隊列記憶體佔用和持久化大小的實現。

• IBM MQ、Oracle JMS不支援隊列記憶體佔用、持久化大小、TPS效能的實現。

• ActiveMQ / Apollo僅支援單個隊列的控制台實現，但對單個隊列的監控實現較為豐富，不支援TPS效能的實現。

 

叢集功能、事務支援、高可用、穩定性專題分析

 

• 除Apollo外各產品均能較好的實現叢集所需功能。

• Apollo不支援叢集功能（訊息路由），能通過設定檔實現水平擴充，能通過failover協議實現負載平衡。

• RabbitMQ需通過第三方軟體HAProxy來實現負載平衡。

 

 

叢集功能：通過配置叢集執行個體，能實現隊列的水平擴充、動態擴充，能實現訊息的路由和負載平衡。

 

• 除Apollo外各產品均能較好的實現叢集所需功能。

• Apollo不支援叢集功能（訊息路由），能通過設定檔實現水平擴充，能通過failover協議實現負載平衡。

• RabbitMQ需通過第三方軟體HAProxy來實現負載平衡。

 

事務支援：通過應用程式測試是否支援本地事務的commit、rollback等機制。

 

• 所有產品均能較好的實現本地事務支援功能，包括事務提交、交易回復等。

• RabbitMQ需購買商業JMS用戶端實現。

• Rocket採用自訂文本協議實現事務提交、復原等功能。

 

高可用：通過測試當佇列服務器出現故障或者網路故障時，用戶端可以自動連接到其他隊列，保持業務的不間斷。

 

• 所有產品均能實現FAILOVER機制，RabbitMQ需通過HAProxy來實現FAILOVER。

• 僅RabbitMQ能實現訊息的無持久化記憶體複製。

• IBM WMQ、RabbitMQ、RocketMQ、ActiveMQ能實現Master-Slave模式高可用。

 

穩定性：通過持續發送訊息，主機CPU在60%以上壓力下，訊息中介軟體運行情況。

 

• 各產品均表現出良好的穩定性，在連續12小時高並發測試情況下，均能保持100%的訊息處理正確率。

 

 

擴充功能專題分析

 

• 各產品在檔案傳輸功能、事件訊息機制、網路限流方面均能較好的實現。

• RabbitMQ檔案傳輸、大檔案傳輸、交易一致性、延遲隊列功能需購買JMS用戶端實現。

• RocketMQ不支援大檔案傳輸。

• Apollo不支援續傳重傳、延遲隊列功能。

 

 

檔案傳輸功能：通過測試伺服器之間的檔案傳輸，統計資料發送和接收正確率，檢驗是否有檔案丟失或重複。

 

• 所有產品均能實現檔案傳輸功能。商業產品本身支援檔案傳輸功能，開源產品需通過應用程式實現。

• RabbitMQ檔案傳輸功能需購買JMS用戶端實現。

 

事件訊息機制功能：通過在測試時，人為進行網路斷連等例外狀況事件，在出現例外狀況事件後訊息節點會收到例外狀況事件資訊。

 

• 所有產品均能實現事件訊息機制功能。

• IBM WMQ支援各種事件的配置是否啟用，如許可權事件、禁止事件、本地事件等等。

 

網路限流功能：通過調整訊息中介軟體的配置參數，測試允許使用的網路頻寬，進行資料轉送，檢查限流功能。

 

• IBM WMQ對網路限流支援較為全面，能通過訊息大小限制、批次傳輸限制、訊息總量限制、記憶體使用量限制、磁碟使用限制等各種配置實現對網路限流功能。

• Oracle JMS可通過訊息大小限制、訊息總量限制實現對網路限流功能。

• RabbitMQ支援通過對記憶體使用量限制、磁碟使用限制實現對網路限流功能。

• RocketMQ支援通過訊息大小限制實現網路限流功能。

• ActiveMQ支援通過記憶體使用量限制實現網路限流功能。

• Apollo支援通過訊息總量限制實現網路限流功能。

 

 

續傳重傳功能：通過人為斷開網路來測試訊息中介軟體的斷點續傳能力，統計資料發送和接收正確率，檢查是否有資料丟失或重複。

 

• 除Apollo之外的產品均支援續傳重傳功能。

• Apollo不支援ConnectionControl command處理，不能實現自動重連，所以不支援重傳功能。預計在Apollo1.8版本中實現該特性。

 

大檔案傳輸效率：通過進行大檔案傳輸測試訊息中介軟體對大檔案傳輸的支援程度。

 

• IBM WMQ、Oracle JMS、ActiveMQ、Apollo支援大檔案傳輸。

• RabbitMQ需購買JMS用戶端實現。

• RocketMQ不支援大檔案傳輸。

 

 

交易一致性：通過驗證訊息中介軟體是否支援交易最終一致性。

 

• 除Rocket之外的產品均支援交易一致性功能。

• RabbitMQ需購買JMS用戶端實現。

• 開源版RocketMQ不支援分布式事物，商業版ONS支援。

 

延遲隊列：通過應用程式設定訊息延時時間，在延時時間後訊息是否被丟棄或銷毀，無法被處理。

 

• 除Apollo之外各產品均支援延遲隊列功能。

• RabbitMQ需購買JMS用戶端實現。

 

總體效能測試結果

 

• 各產品在水平擴充性能測試方面，均有優秀的表現。

• 點對點效能測試方面，RabbitMQ、Oracle JMS表現尚可，ActiveMQ、IBM WMQ、RocketMQ略有不足，Apollo差距較大。

• 訂閱效能測試方面，ActiveMQ一枝獨秀，表現優秀，RocketMQ、IBM WMQ表現尚可，Oracle JMS、Apollo仍有差距，RabbitMQ差距較大。

 

 

水平擴充專題分析：通過兩節點、四節點配置進行訊息大小1KB、持久化、讀寫混合的效能測試，得出水平擴充的資料。

 

• 從各產品的水平擴充能力來看，RabbitMQ和Rocket的處理能力明顯優於其他產品。2節點的處理能力，RabbiMQ和RocketMQ優勢較為明顯。

 

 

點對點效能測試專題分析：通過進行點對點模式，分1K、2K、10K、1M四種訊息大小、對8個隊列組成的叢集進行效能測試。

 

• IBM WMQ在讀寫混合效能測試中表現優秀，純寫入效能測試表現不理想。

• Oracle JMS在純讀取效能測試中表現優秀，純寫入效能測試表現不理想。

• RabbitMQ在持久化方面支援記憶體複製模式，在純寫入效能測試表現優秀，純讀取效能測試不理想。

• RocketMQ不支援非持久化，純讀取效能測試表現優秀，純寫入效能測試不理想。

• ActiveMQ在混合效能測試中表現優秀，純寫入效能測試表現良好，純讀取效能測試表現不理想。

• Apollo整體表現較差，僅在非持久化純寫入和純讀取效能測試表現尚可。

 

 

訂閱效能測試專題分析：通過進行訂閱模式，分1K、2K、10K、1M四種訊息大小、對8個隊列組成的叢集進行效能測試。

 

• ActiveMQ整體表現非常優秀，無論是非持久化還是持久化。

• RocketMQ不支援非持久化，持久化方面整體有著較好的表現。

• IBM WMQ整體表現均衡，讀寫混合效能測試中表現稍好。

• Oracle JMS整體表現均衡，在非持久化讀寫混合效能測試表現優秀。

• Apollo整體表現一般，讀寫混合效能測試表現較好。

• RabbitMQ整體表現仍有差距，非持久化效能測試不理想。

開源 VS 商業，訊息中介軟體你不知道的那些事