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

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

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

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

RocketMQ 從設(shè)計之初就立足于在線交易鏈路，因此主要應(yīng)用在大型在線系統(tǒng)的異步化處理。

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

開源至今，RocketMQ 的核心架構(gòu)大約經(jīng)歷了四個重要的演進階段：

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

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

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

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

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

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

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

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

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

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

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

在 5.0 版本中，對系統(tǒng)中的不同服務(wù)進行了解耦，比如 Nameserver 和 Broker，設(shè)計為以下架構(gòu)：

圖中借用了 Service Mesh 關(guān)于控制和數(shù)據(jù)面的劃分思想以及 xDS 的概念來描述各個組件的職責(zé)。

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

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

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

• Compute-Broker（CBroker），重構(gòu)版本后抽象出的無狀態(tài)計算集群，作為數(shù)據(jù)流量的入口，提供鑒權(quán)與簽名、上層計量統(tǒng)計、資源管理、客戶端連接管理、消費者管控治理、客戶端 RPC 處理、消息編解碼處理、流量控制、多協(xié)議支持等。

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

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

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

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

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

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

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

在 Streaming 領(lǐng)域，與 Kafka 只是作為 Flink 的上下游數(shù)據(jù)不同，RocketMQ 會全面擁抱 Flink 開源生態(tài)。RocketMQ-flink connector 將在近期從社區(qū)畢業(yè)，相比于 Kafka-flink connector，RocketMQ 實現(xiàn)了最新的 FLIP-27/FLIP-143 接口，能夠為開發(fā)者提供更一致的流批一體實時數(shù)據(jù)處理體驗。

更為重要的是，與其他任何消息產(chǎn)品不同，rsqlDB 首創(chuàng)性地兼容了 Flink/Blink SQL 標(biāo)準(zhǔn)以及 UDF/UDAF/UDTF，使得兩個開源產(chǎn)品的生態(tài)可以更好地融合，開發(fā)者可以將 Flink/Blink 已有 SQL 計算任務(wù)遷移到 RocketMQ ，在 RocketMQ 內(nèi)部完成輕量級的計算處理，在算力受限或者更大規(guī)模的場景下，同樣可以將 RocketMQ 的實時計算任務(wù)遷移到 Flink，利用 Flink 的大數(shù)據(jù)計算能力滿足業(yè)務(wù)訴求。

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

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

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

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

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

基于上述判斷，從 RocketMQ 5.0 開始，云時代事件驅(qū)動的基礎(chǔ)設(shè)施建設(shè)將成為下一階段 RocketMQ 預(yù)言演進的重中之重。從 5.0 開始，RocketMQ 會基于標(biāo)準(zhǔn)、開放的 CloudEvents 1.0 協(xié)議連接海量異構(gòu)、復(fù)雜云環(huán)境，并配合 Serverless 運行時支撐上層事件驅(qū)動服務(wù)。這一計劃當(dāng)前正在公共云環(huán)境進行產(chǎn)品孵化。在阿里云上已經(jīng)發(fā)布的 EventBridge 正是這樣的一款事件驅(qū)動運行時產(chǎn)品，用來承載海量云服務(wù)、自定義應(yīng)用的事件集成和驅(qū)動處理。未來在完成初期孵化后，EventBridge 會貢獻到開源 RocketMQ，進一步促進開源事件生態(tài)的集成。

總結(jié)來說，RocketMQ 5.0 的定位是云原生的"消息、事件、流"超融合處理平臺，用以幫助用戶更容易地構(gòu)建下一代事件驅(qū)動和流處理應(yīng)用。

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

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

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

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

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

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

開源地址：

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

采訪嘉賓簡介：

王小瑞：花名誓嘉，阿里云資深技術(shù)專家，Apache RocketMQ 創(chuàng)始人、PMC Chair。

林清山：阿里云資深技術(shù)專家，阿里云消息產(chǎn)品線負(fù)責(zé)人。