終于！RocketMQ發布5.0版本：架構大重構，代碼變更比例高達60%

RocketMQ 是一個來自阿里巴巴的分布式消息中間件，于 2012 年開源，并在 2017 年正式成為 Apache 頂級項目。

2017 年 2 月 20 日，RocketMQ 正式發布 4.0 版本。差不多 5 年之后，我們終于等來了 5.0 版本。

RocketMQ 5.0 專注于消息基礎架構的云原生化演進，聚焦在消息領域的后處理場景，支持消息的流式處理和輕計算，幫助用戶實現消息的就近計算和分析，并將全面擁抱 Serverless 和 EDA。

據阿里云消息產品線負責人林清山介紹，這次發布的版本，因為進行了架構重塑，新增或者修改了超過 60% 的代碼，但是對 4.0 的所有功能以及整體架構進行了無縫兼容，且沒有引入任何外部依賴，保持了 RocketMQ 極簡架構、極低運維成本的特點。

RocketMQ 從設計之初就立足于在線交易鏈路，因此主要應用在大型在線系統的異步化處理。

歷經十年發展，目前的大規模落地場景有：電商物流的交易系統、在線教育課程系統、大型游戲信令系統、以及銀行交易系統，這些都大量使用了 RocketMQ 來做異步解耦和削峰填谷；同時在非在線業務的場景里，大量車聯網、電商網站基于 RocketMQ 實現 IoT 邊緣數據以及 C 端用戶行為數據采集傳輸和集成。

開源至今，RocketMQ 的核心架構大約經歷了四個重要的演進階段：

第一代 RocketMQ 其實是采用了推模式，數據存儲采用關系型數據庫。在這種模式下消息具有很低的延遲特性，并且很容易支持分布式事務。在阿里淘寶這種高頻交易場景中，具有非常廣泛的應用。

第二代 RocketMQ 在服務于交易場景基礎上開始探索自研存儲引擎，這個版本采用了拉模式和自研的專有消息存儲，在日志處理方面能夠媲美 Kafka 的吞吐性能。

在前兩代初步打磨了自研的存儲引擎后， RocketMQ 3.0 的重構前瞻性地去除了 ZooKeeper 等組件的外部依賴，并支持了單機海量 Topic。而剛好在前不久，我們也報道過消息系統 Kafka 去除 ZooKeeper 依賴。

第四代 RocketMQ 在高可靠低延遲方面重點優化，構建了全新的低延遲存儲引擎、新增了 Raft 多副本存儲能力、提供了豐富的消息特性。

目前社區開發者對 RocketMQ 的訴求來自于三個方面：首先，RocketMQ 如何更方便地與云原生生態整合是開發者最為關心的問題；其次，在流計算場景里，社區對 RocketMQ 的吞吐能力提出了更高的要求，企業客戶也一直希望就近處理流轉在 RocketMQ 系統中的如支付、交易等高價值的業務數據；還有一類則是在企業集成過程中，希望 RocketMQ 能提供更多 connector 幫助用戶構建企業數據流轉中心。

伴隨如今企業全面上云以及云原生的興起，新一代基礎架構必須朝著云原生化演進，RocketMQ 在 5.0 里面提供了可分可合的存儲計算分離架構以順應這一趨勢。

通過可分可合的存儲計算分離架構，用戶可以同一進程啟動存儲和計算的功能，也可以將兩者分開部署。分開部署后的計算節點可以做到“無狀態”，一個接入點可代理所有流量，在云上結合新硬件內核旁路技術，可以降低分離部署帶來的性能及延遲問題。而選擇“存儲計算一體化”架構，同時也能契合“就近計算”的趨勢，也就是在最靠近數據的地方做計算。

林清山表示新版本在存儲計算分離的架構選擇上非常慎重：“首先我們認為在云上多租、多 VPC、多種接入方式的場景下是非常有必要的，存儲計算分離后能夠避免后端存儲服務直接暴露給客戶端，便于實現流量的管控、隔離、調度、權限管理。”

但是有利必有弊，除了帶來延遲的上升、成本的增加以外，存儲計算分離也會給線上運維帶來巨大挑戰。在大多數場景下，用戶更希望的還是存儲計算一體化的架構，開箱即用、性能高、延遲低、運維輕松，尤其是在大數據場景下，能夠極大降低機器及流量成本。其實這個問題本質上還是由消息產品的特性決定的，消息相比于數據庫，計算邏輯相對簡單，拆分后往往會淪為無計算場景可發揮、存儲節點也得不到簡化的狀態，這個從 Kafka 的架構演進也可以得到印證。”

“存儲計算分離只是適應了部分場景，架構的演進還是要回歸到客戶的真實場景。”

在 4.0 版本中，RocketMQ 主要由 NameServer、Broker、Producer 以及 Consumer 四部分構成。Producer 和 Consumer 由用戶進行分布式部署。NameServer 以輕量級的方式提供服務發現和路由功能，每個 NameServer 存有全量的路由信息，提供對等的讀寫服務，支持快速擴縮容。Broker 負責消息存儲，以 Topic 為緯度支持輕量級的隊列，單機可以支撐上萬隊列規模。

在 5.0 版本中，對系統中的不同服務進行了解耦，比如 Nameserver 和 Broker，設計為以下架構：

圖中借用了 Service Mesh 關于控制和數據面的劃分思想以及 xDS 的概念來描述各個組件的職責。

• 全新輕量級 SDK，基于 gRPC 協議重新打造的一批多語言客戶端，采取 gRPC 的主要考慮其在云原生時代的標準性、兼容性以及多語言傳輸層代碼的生成能力。

• 導航服務（Navigation Server），這是個可選組件，通過 LB Group 暴露給客戶端。客戶端通過導航服務獲取數據面的接入點信息（Endpoint），隨后通過計算集群 CBroker 的 LB Group 進行消息的收發。通過 EDS 暴露 CBroker 的接入點信息的方式比通過 DNS 解析的負載均衡更加智能且可以更精細實現流量控制等邏輯。

• NameServer，RocketMQ 原有的核心組件，主要提供 SBroker 的集群發現（CDS），存儲單元 Topic 的路由發現（RDS）等，為運維控制臺組件、用戶控制臺組件、計算集群 CBroker 提供 xDS 服務。

• Compute-Broker（CBroker），重構版本后抽象出的無狀態計算集群，作為數據流量的入口，提供鑒權與簽名、上層計量統計、資源管理、客戶端連接管理、消費者管控治理、客戶端 RPC 處理、消息編解碼處理、流量控制、多協議支持等。

• Storage-Broker（SBroker），重構后下沉的存儲節點，專注于提供極具競爭力的高性能、低延遲的存儲服務。

• LB Group，根據用戶的需求提供多樣化的負載均衡接入能力。

但存儲計算一體化在很多場景下依然是最佳選擇，因此，RocketMQ 在 5.0 為存儲計算分離架構提供了靈活的選擇：可分可合。如上圖所示，左邊是一個分離部署的形態，右邊是合并部署的形態，合并部署時計算節點可以作為存儲節點的 SideCar，采用網格的思想部署，也可以將計算和存儲揉進同一個進程部署。

在云原生架構設計中，我們常聽到要讓基礎設施完全解耦，這意味著可以讓用戶在任意的基礎設施上部署交付。現在公有云、專有云、混合云、多云下的基礎設施均不相同，以存儲為例，可能有云盤，也有可能是本地盤；以網絡為例，可能是經典網絡，也有可能是多 VPC 網絡...... 這樣的環境要求對于基礎服務的云原生架構設計是一個非常大的挑戰。所以，RocketMQ 5.0 架構的重塑，很重要的改變是在不同的應用場景下都能提供極致的彈性和統一的架構，“我們稱之為場景多元化”，RocketMQ 創始人誓嘉表示。

舉例來說，使用 RocketMQ 可以自由選擇私有化多副本部署方式或者利用公共云云盤的方式，后者既能提升性能又能降低硬件成本及運維成本，也帶來了更高的彈性能力。在對一致性要求非常高且需要主從自動切換能力的場景，Raft 又可以保證數據可靠性、業務可用性。同時，RocketMQ 還支持多元索引，可以基于一份原始數據構建多份索引來滿足不同的業務場景，包括消費索引、查詢索引、批索引、百萬隊列索引等，以便在同一套架構支撐著不同行業的各種差異化訴求。

目前業界有兩個發展態勢，一個是不可阻擋的云原生改造趨勢，另一個是流計算時代的全面興起。因此，除提供對云原生的支持外，作為業界首個兼容 Flink 生態的消息產品，RocketMQ 5.0 這個大版本里面提供了 rocketmq-streams 實時計算框架， 目前已經在 Apache 社區開源。

作為一套全新的流式處理框架，rocketmq-streams 依賴少、部署簡單，可任意橫向擴展，利用 RocketMQ 資源即可完成輕量級的數據處理和計算。除此以外，為了方便開發者讓基于 RocketMQ 的流式計算更容易，后續還會開源 rsqlDB，為開發者提供基于 SQL 的開發體驗。

在 Streaming 領域，與 Kafka 只是作為 Flink 的上下游數據不同，RocketMQ 會全面擁抱 Flink 開源生態。RocketMQ-flink connector 將在近期從社區畢業，相比于 Kafka-flink connector，RocketMQ 實現了最新的 FLIP-27/FLIP-143 接口，能夠為開發者提供更一致的流批一體實時數據處理體驗。

更為重要的是，與其他任何消息產品不同，rsqlDB 首創性地兼容了 Flink/Blink SQL 標準以及 UDF/UDAF/UDTF，使得兩個開源產品的生態可以更好地融合，開發者可以將 Flink/Blink 已有 SQL 計算任務遷移到 RocketMQ ，在 RocketMQ 內部完成輕量級的計算處理，在算力受限或者更大規模的場景下，同樣可以將 RocketMQ 的實時計算任務遷移到 Flink，利用 Flink 的大數據計算能力滿足業務訴求。

另外，RocketMQ 4.x 的設計里，用戶的消息分布在 Topic 內的多個隊列上，但這些隊列都是和物理節點內的索引文件一一對應。這樣的設計雖然能夠保證單機范圍內萬級隊列的高效讀寫，但也導致了運維不靈活的問題，即 RocketMQ 的存儲物理節點擴縮容時，用戶 Topic 內的隊列數量就會產生變化。眾所周知，在流式數據處理過程中上層業務一般要求存儲隊列始終固定，同時還要求在底層節點運維過程中物理節點的變化對上層隊列是透明的，只有這樣才能保證流式數據處理的順序性和完整性。

RocketMQ 5.0 將消息隊列下沉為物理隊列，上層重新抽象了邏輯隊列。一個邏輯隊列可以包含多個物理隊列，各個物理隊列都作為邏輯隊列的一個片段，以此拼接出真正的流式隊列。也因此可以做到更輕量，秒級擴縮，在物理節點發生變化時不涉及到存量數據復制遷移；實現數據存儲的靈活調度，配合 TTL 實現無限存儲能力。

RocketMQ 5.0 通過全新設計實現的 Streaming 計算框架以及對 Streaming 場景的邏輯隊列存儲優化，使得 RocketMQ 快速具備了完善的流式數據計算能力和兼容 Flink 的 SQL 計算能力，所以這個版本絕對算得上是一次里程碑式的發布。

另一方面，“基于云廠商的視角，我們判斷在企業全面上云的時代，事件驅動又會重新發揮作用”，林清山表示。

“我們發現在企業數字化轉型進入深水區之后，企業系統的業務集成不再僅僅需要一個消息通道。用戶的業務集成必然會涉及到復雜異構的 IaaS 基礎設施打通與連接；對信息的深層次解析和價值挖掘；低代碼、彈性高效的完成業務開發與集成。而這些新的訴求都需要在消息通道的基礎上重新定義事件標準、異構連接、低代碼、無服務器等開發模式。因此可以簡單地下一個斷言，事件驅動將是消息驅動在業務集成領域的下一個演進階段。”

基于上述判斷，從 RocketMQ 5.0 開始，云時代事件驅動的基礎設施建設將成為下一階段 RocketMQ 預言演進的重中之重。從 5.0 開始，RocketMQ 會基于標準、開放的 CloudEvents 1.0 協議連接海量異構、復雜云環境，并配合 Serverless 運行時支撐上層事件驅動服務。這一計劃當前正在公共云環境進行產品孵化。在阿里云上已經發布的 EventBridge 正是這樣的一款事件驅動運行時產品，用來承載海量云服務、自定義應用的事件集成和驅動處理。未來在完成初期孵化后，EventBridge 會貢獻到開源 RocketMQ，進一步促進開源事件生態的集成。

總結來說，RocketMQ 5.0 的定位是云原生的"消息、事件、流"超融合處理平臺，用以幫助用戶更容易地構建下一代事件驅動和流處理應用。

阿里的數據統計表明，RocketMQ 目前全球 Contributors 接近 500 人，并形成了包括內核、批、connect、streaming、多語言客戶端、rocketmq-flink、operator、exporter，openschema 等一系列興趣小組。從最近的幾個版本來看，越來越多的公司以及開發者參與了進來，阿里以外的公司貢獻的代碼已經超過 60%。

RocketMQ 同時也正在積極聯合阿里內部的云原生熱點項目 maintainer 進行云原生生態建設，目前這一塊已經取得了較大的進展。RocketMQ 與 Kubernetes Operator、Prometheus、Knative、Envoy、Dapr、CloudEvents 等生態項目的整合已經被相關的頂級社區官方收錄，可以提供開箱即用的用戶體驗。

未來的演進核心方向仍將繼續圍繞消息、事件和流三個核心場景開展：

“首先，消息架構本身必將繼續朝著 Serverless 彈性、強容災能力、可觀測免運維的方向繼續推進；其次，面向消息數據的就近處理，這一塊將基于 Streaming 存儲和框架為用戶提供輕量級的計算能力，以適配 IoT、邊緣計算的場景訴求；最后，會面向未來的企業集成模式，消息驅動將演進到事件驅動的階段，為用戶提供低代碼、無服務器的開發體驗。”

除了上述幾點以外，RocketMQ 也會有更多面向云原生、流計算的特性發布，社區正在進行如火如荼的開發，比如：輕量級客戶端、gRPC 協議支持、批量消息的發送存儲消費、OpenSchema、列讀、原生 KV 支持等。

接下來一段時間，還會發布一些非常重磅且經過大規模云上生產驗證的生態項目，比如 Event Bridge、Serverless Runtime 實現、Dapr/Envoy 的集成、完全兼容 Flink SQL 的計算框架 rsqlDB、 AMQP/MQTT 協議支持等，用以幫助 RocketMQ 快速構建完整強大的云原生生態。

開源地址：

https://github.com/apache/rocketmq/tree/5.0.0-previewhttps://github.com/apache/rocketmq-streams

采訪嘉賓簡介：

王小瑞：花名誓嘉，阿里云資深技術專家，Apache RocketMQ 創始人、PMC Chair。

林清山：阿里云資深技術專家，阿里云消息產品線負責人。