作者 |   林清山

Apache RocketMQ 自 2012 年開源以來，因其架構簡單、業務功能豐富、具備極強的可擴展性等特點被廣泛采用。RocketMQ 在阿里巴巴集團內部有著數千臺的集群規模，每天十萬億消息流轉的規模。在阿里云上，RocketMQ 的商業化產品也以彈性云服務的形式為全球數萬個用戶提供企業級的消息解決方案，被廣泛應用于互聯網、大數據、移動互聯網、物聯網等領域的業務場景，成為了業務開發的首選消息中間件。 盡管消息中間件 RocketMQ 在阿里巴巴和開源社區已經走過了十多個年頭，但在云原生浩浩蕩蕩的浪潮下，我們開始對 RocketMQ 的架構有了一些新的思考。

痛點與困局

阿里巴巴有大規模實踐 RocketMQ 的生產經驗，自 RocketMQ 從 2016 年對外商業化以來，一直延續跟集團消息中間件相同的架構為云上的客戶提供全托管的消息服務，發展至今，消息隊列 RocketMQ 在云上已經具備相當大的業務規模。隨著業務的發展，這套極簡的分布式架構在云原生環境下逐漸顯露出了一些不足，比如，運維成本增加、效率降低。

集團消息中間件通過存儲計算一體化的部署架構，為集團電商業務提供了高性能、低延遲、低成本的消息服務。隨著云的進化，云開始變得更加彈性，網絡環境更加復雜，云原生時代對效率也有了更高的要求，我們也迎來了對云上消息架構進行云原生化改造的契機。 上圖是目前RocketMQ在云上部署的一個簡化版架構(僅包含最核心的組件)，這套部署架構近年來在云上遇到的主要痛點有以下幾點：

1.富客戶端形態

RocketMQ 的用戶需要借助官方提供的 SDK 使用云上的服務，這是一個比較重量級的富客戶端，提供了諸如順序消費、廣播消費、消費者負載均衡、消息緩存、消息重試、位點管理、推拉結合、流控、診斷、故障轉移、異常節點隔離等一系列企業級特性。RocketMQ 的富客戶端極大地降低了集團內客戶的接入成本，一站式助力集團客戶構建高韌性、高性能的消息驅動應用，但云上的富客戶端有一些不足：

• 富客戶端跟云原生的技術棧不匹配，比如很難跟 Service Mesh 結合，也跟 Dapr 這類新興的云原生應用框架不兼容(?)，消費者物理資源耗費比較大，對 Serverless 彈性也不是很友好;
• 多語言客戶端對齊困難，在云上對多語言的訴求是非常強烈的，但富客戶端邏輯復雜，團隊無充足的人力保障多語言客戶端的質量，為此云上誕生了基于 GraalVM 和 HTTP 協議的多語言 SDK，但都有其局限性;
• 客戶端不是完全無狀態，存在內存狀態，重啟的時候會觸發重平衡，導致消費抖動、延遲。這種重平衡的設計滿足了性能上的需求，但對于敏感型業務，這些抖動可以說在過去幾年貢獻了很多的工單;
• 分區級別的消費粒度，客戶端負載均衡的粒度在分區，一個分區無法同時被多個消費者消費，在慢消費者場景影響非常大，無法通過擴容分擔慢消費者的壓力。

2.計算存儲一體化

Broker 是 RocketMQ 最核心的節點，承擔了服務端所有的計算和存儲邏輯，其核心能力為：

• 計算：鑒權與簽名、商業化計量、資源管理、客戶端連接管理、消費者管控治理、客戶端 RPC 處理、消息編解碼處理等。
• 存儲：基于分區的 WAL 存儲，多類型索引(普通、定時、事務等)，核心的收、發、查詢能力，多副本復制能力等。

計算存儲一體化的 Broker 具備以下優點：部署結構簡單、開源用戶可以開箱即用;部署節點少，低成本支持集團雙十一萬億級的消息規模;數據就近處理，無中間環節，性能高，延遲低。但一體化的 Broker 在云環境也有其局限性：

• 業務迭代效率低：發布單元為 Broker，即使調整了一行計量邏輯，需要全量發布數千臺 Broker 節點才能全網生效，導致業務創新和迭代的速度慢。
• 穩定性風險高：計算存儲一體，但大多數業務需求都是針對計算邏輯，存儲節點相對穩定，頻繁的低價值發布帶來了穩定性風險和運維成本;每一次因計算邏輯的修改帶來的發布將引起緩存重建、消費延遲、客戶端異常感知等問題。
• 資源利用率低：Broker 是磁盤 IO 和內存密集型應用，對計算資源的消耗相對較低，但兩者一體后擴縮容也是一體的，無法將計算和存儲節點單獨做 Serverless 彈性，整體 Broker 集群資源利用率偏低。

管控鏈路復雜：因為數據和狀態完全分布式存儲在 Broker 上，管控節點需要與每個 Broker 進行通信，比如一個查詢操作需要命中多個 Broker 并將結果進行聚合等，導致管控鏈路的邏輯復雜。

3.客戶端與Broker直連

RocketMQ 當前的用戶通過客戶端直接與 Broker 進行通信，鏈路是最短化的，運維簡單、延遲低，但這樣的設計無法很靈活地適配網絡極其復雜的云環境，網絡上有經典網絡、VPC 網絡、公網，部署環境上有 OXS 區、售賣區，為客戶暴露每一個 Broker 節點帶來了運維上的負擔：

• Broker 對客戶端不透明，客戶端感知每個 Broker 節點，Broker 的運維動作在客戶端往往有明顯的感知;
• Broker 直接對外提供服務，需要為每個 Broker 申請 VIP，包含 Classic VIP、VPC VIP 甚至公網 IP，線上運維了數千個 VIP。每個 Broker 數個 VIP，運維代價高的同時，很長一段時間 VIP 的手動申請阻礙了RocketMQ的自動化部署。
• 無法支持多接入點，Broker 通過 NameServer 暴露給用戶，只能暴露一個接入點，用戶一般只能在經典網絡、VPC 網絡以及公網接入點中三選一。

基于這個大背景，阿里云消息團隊對 RocketMQ 在云上進行了云原生架構升級專項，實踐存儲計算分離的新架構，同時引入基于gRPC 的全新多語言解決方案，來加速消息中間件的云原生化。

存算分離新思路

如何在云上實踐存算分離，如何探索出一個適合 RocketMQ 三位一體的新架構，是 RocketMQ 進行云原生架構升級主要考慮的點，這里面有很多現實因素的考量：

• RocketMQ 在阿里集團已經充分驗證了其架構優秀的特征，是否需要適配云的需求進行存算分離?由此帶來的延遲、額外的成本是否能覆蓋新架構帶來的新價值?
• 阿里云上多款消息產品已經是存算分離的架構形態，比如消息隊列 RabbitMQ、消息服務 MNS，新的架構怎么與這些產品架構進行融合?

對于第一個問題，實踐的結果已經告訴我們架構簡單的優異性，但在云上遇到的痛點又告訴我們存算分離勢在必行，可見存儲與計算要不要分離，并不是一個非此即彼的選擇，架構上的選擇是否能都要呢?對于這個問題，我們的解法是存儲計算需要做到可分可合：

• 「分」有兩層解釋，首先代表了模塊和職責的分明，屬于計算的邏輯應該封閉在計算模塊，屬于存儲的邏輯應該下成到存儲模塊;第二層是計算和存儲要支持分開部署，計算完全采用無狀態的部署方式，存儲是有狀態的放式，來很好地解決在云上多租戶場景面臨的種種問題。
• 「合」的前提是從代碼設計上要先分開，至于是分開部署還是合并部署完全是業務的選擇，新的架構必須要支持合并的部署形態，滿足吞吐型的業務場景。比如，阿里集團內部超大規模的消息流場景;又比如小規模單租戶場景，不需要服務化的場景，合并部署可以快速將 RocketMQ 投產。

對于第二個問題，在阿里云上有多個自研的不同協議標準的消息服務，如何通過單一架構支持多產品形態至關重要，將 RocketMQ 的核心業務消息的能力無縫復制到多個產品，放大業務價值。

總而言之，架構層面的核心理念是以存儲計算架構分離為切入點，進一步探索單一架構多產品形態，以降低消息子產品的重復建設，最終也需要實現存儲與計算可分可合的部署形態，同時滿足云上的運維靈活性以及開源、集團等部署簡單、高性能的需求。

1.存儲計算分離架構

RocketMQ 5.0 在架構上的第一個升級便是存儲計算分離改造，通過引入無狀態的 Proxy 集群來承擔計算職責，原Broker 節點會逐步演化為以存儲為核心的有狀態集群，同時會重新研發一批多語言的瘦客戶端來解決富客戶端帶來的諸多問題。

上圖是一個存儲計算分離架構的簡圖，圖中借用了 Service Mesh 關于控制和數據面的劃分思想以及 xDS 的概念來描述，架構中各個組件的職責分別為：

• 多語言瘦客戶端，基于 gRPC 協議重新打造的一批多語言客戶端，采取 gRPC 的主要考慮其在云原生時代的標準性、兼容性以及多語言傳輸層代碼的生成能力。
• 導航服務(Navigation Server)，通過 LB Group 暴露給客戶端，客戶端通過導航服務獲取數據面的接入點信息(Endpoint)，隨后通過計算集群 Proxy 的 LB Group 進行消息的收發。通過 EDS 來暴露 Proxy 的接入點信息與通過 DNS 解析的負載均衡進行路由相比而言，可以作出更智能與更精細的租戶及流量控制、負載均衡決策等。
• NameServer，RocketMQ 中原有的核心組件，主要提供用于存儲的 Broker 集群發現(CDS)、存儲單元Topic 的路由發現(RDS)等，為運維控制臺組件、用戶控制臺組件、計算集群 Proxy 提供xDS服務。
• Proxy，重新研發的無狀態計算集群，數據流量的入口，提供鑒權與簽名、商業化計量、資源管理、客戶端連接管理、消費者管控治理、客戶端RPC處理、消息編解碼處理、流量控制、多協議支持等。
• Broker，原 Broker 模塊的存儲部分獨立為新的存儲節點，專注提供極具競爭力的高性能、低延遲的存儲服務，存儲計算分離后也更易加速存儲能力的創新。原 Broker 模塊的計算部分逐漸上移到 Proxy集群當中。
• LB Group，根據用戶的需求提供 Classic VIP、VPC VIP、Internet VIP、Single Tunnel、PrivateLink 等多樣化的接入能力。

存儲計算分離帶來的額外成本主要是延遲和成本。

關于延遲，存儲和計算節點從本地方法調用轉換為遠程調用后，無可避免地增加了延遲，一般是毫秒級別，在阿里云上即使是跨 AZ 的網絡通信，延遲一般在 2ms 以內，這種量級的延遲增加對大多數業務來講是完全可以接受的。

• 關于成本，存算的分開，導致網絡傳輸層面，序列化和反序列化層面不可避免需要更多的 CPU 資源。但另一方面，存儲和計算一個屬于磁盤 IO、內存密集型，一個是 CPU 密集型，拆開后可以更好地設計規格，更好地利用碎片化資源，更容易提高資源利用率，利用云的彈性能力，成本反而可以降低。
• 簡而言之，在云上環境，云服務形態的 RocketMQ 非常適合存儲計算分離架構。

2.存儲計算合并架構

但從本質來講，存儲計算分離與就近計算和就近存儲的理念是沖突的。存儲計算一體化的架構在云上帶來了困擾，本質還是因為云上是一個多租戶的環境，存儲計算一體化在多租戶的場景下靈活性不夠。但很多場景往往都是小規格單租戶，其實更適合存儲計算一體化。

• 在開源場景，開源用戶更加期望 RocketMQ 是一款開箱即用、部署簡單的消息中間件，存儲計算分離架構會帶來一定的復雜度，影響開源生態的建設。
• 在集團的場景，數千臺物理機的規模，存儲計算分離將帶來額外的機器成本。
• 在專有云場景，很多專有云可能節點數量有限，更傾向于采用一體化的架構。

為了云外云內都能統一技術方案，我們更加期望的一種機構是存儲與計算可分可合的部署形態，分開部署是計算節點完全無狀態，運維迭代極其簡單，合并部署時更原架構體驗保持一致。

但無論采用什么樣的部署架構，存儲和計算的分離都是一種良好的模塊化設計方式，在編程層面的分開是必須要進行的。

如上圖所示，左邊是云上一個分離部署的形態，右邊是合并部署的形態，合并部署時計算節點可以作為存儲節點的SideCar，采用網格的思想進行部署，也可以將計算和存儲揉進同一個進程進行部署。實際上，我們在實踐的過程中，通過對代碼進行充分設計，Proxy 節點可以通過構造器構造出「Local」和「Cluster」部署兩種形態，分別對應合并部署和分離部署的兩種架構形態。

3.單一架構多產品形態

《云原生時代消息中間件的演進路線》一文中提到，阿里云消息團隊目前有業界最豐富的消息產品矩陣，包括消息隊列 RocketMQ、消息隊列 Kafka、微消息隊列 MQTT、消息隊列 AMQP、消息服務 MNS、事件總線EventBridge。豐富的產品矩陣是團隊多年來踐行多樣性和標準化演進路線的結果，所有的消息子產品目前都構建在RocketMQ 存儲內核之上，非常具備統一架構的前提。

通過單一的存儲計算分離架構，支持多產品的業務形態，是云原生消息探索的一個重要方向。這種單一架構多產品形態會帶來諸多好處，比如計算節點共建，通過模型抽象支持多業務模型，多通信協議，釋放重復建設的人力。通過存儲節點并池，各產品打通內部存儲節點，形成資源池合并，統一運維和管控，有助于降低成本、提高效率，加速存儲創新，孵化消息中臺。

如上圖所示，單一架構多產品形態的核心先統一存儲和計算，并進一步統一管控和運維，真正做到一套架構支撐多個云產品。

• 存儲集群足夠抽象，滿足通用的消息存取需求。
• 計算集群多合一，足夠的模塊化，可插拔，滿足多產品部署帶來不同權限體系、不同協議、不同抽象模型等的需求。

總結

目前，阿里云消息隊列 RocketMQ 實踐存儲計算徹底分離的架構還處于第一個過渡階段，未來的路還很長，我們會投入至少 1 年的時間在公有云環境全面落地存儲計算分離架構，讓消息服務更彈性、更云原生，讓團隊提高效率，加速業務創新。我們期望新的架構能穩定服務于未來至少 5 年的業務增長，同時，存算可分可合的部署架構也能夠非常好地支撐不同規模開源用戶的個性化需求，讓 Apache RocketMQ 開源社區能夠整體收益于存算計算可分可合架構的新形態。