本文作者：古崟佑，阿里云中間件開發。

RocketMQ 5.0 版本擁有非常多新特性，比如存儲計算分離、 batch 能力的提升等，它是具有里程碑意義的版本。

(相關資料圖)

提到新版本，我們往往會首先想到服務端架構的設計變動，很容易忽略客戶端的設計理念。客戶端也是消息產品的必要組成部分，許多特性需要 client 與 server 兩端互相協作，才能更好地實現。

輕量化、云原生以及統一模型是 RocketMQ 5.0 客戶端的三個設計理念。

01輕量化

輕量化的重點在于輕邏輯、輕流程，化繁為簡，減少多語言生態發展的阻礙。

上圖列舉了 RocketMQ 4.x 版本和 RocketMQ 5.0 版本的差異。

①4.x 版本的序列化使用 JsonCodecs 和 RocketMQCodecs，5.0 版本使用的則是標準的 Protobuf 協議。多語言發展的阻礙包括許多不規范，比如 RocketMQ 自定義序列化對于其他的語言需要自己實現一套協議以實現正反序列化解析。而 Json 作為標準序列化協議，基本可以實現所有語言的正反序列化，但缺點也非常明顯，冗余信息過多，體積占用太大，因此更多用于 restful 架構等前后端交互的場景。此外，消息中間件場景無需關心傳輸數據時是否可讀。因此， Protobuf 成為了選擇，它原生支持多語言，且傳輸時體積占用非常小，成熟且標準。

②此前客戶端使用 consumer 消費信息時，會存在計算邏輯比如重平衡 以及系統級 topic 處理。但是 RocketMQ 5.0 版本將所有計算邏輯上移到了服務端，客戶端只需簡單地調用 Receive 接口，也無需額外處理系統級 topic ，整體邏輯變得非常輕量。

③4.x版本的實現和維護成本非常高，因此5.0版本并沒有基于4.x進行迭代和更新。設計之初有一種思路為直接在4.x客戶端上增加 gRPC 協議，迭代升級成為5.0，但這相當于扛著歷史包袱往前走，也違背了輕量化原則，因此被否定。

02云原生

云的彈性、高可用性以及交互運維能力在 RocketMQ 5.0 客戶端中均有體現，分別對應極致彈性伸縮、低耦合以及云端一體。

上圖為 4.x版本和5.0版本的客戶端。在4.x版本中， 一個 Queue 最多對應一個 consumer，增加 consumer 不一定能提升消費并發，其彈性有上限。但在 RocketMQ 5.0，每一個 consumer 可以向所有 broker 發起 Pop 請求。此前為 push 模式，現在改為 pop 請求。提升 consumer 數量能夠提升消費并發，即使只有一個隊列，也可以生成數百數千個消費者統一拉取隊列消息。

比如購物網站突發退貨流量高峰，此前最簡單有效的方式為增加業務應用數量、增加處理并發，比如增加退貨系統和客戶系統核心的應用數據。但如果一開始隊列數設置并沒有這么多，則需要先擴容隊列，再擴容核心業務數。同時，擴容后也僅對新入隊的消息處理速度有提升，已經造成堆積的隊列消費速度依然緩慢。此時會出現一種情況，先提交的退貨申請后被處理，會對用戶體驗造成影響。

而 RocketMQ 5.0 的 pop 消費模型只需直接增加業務處理節點數即可解決問題。

已堆積隊列無法通過擴容的方式加速消費，與低耦合場景相似。比如在4.x版本中，假如某消費節點發生 FullGC ，消費比較慢，但是沒有完全下線，依然與服務端保持著心跳。因此隊列依然會被分配至該節點，分配隊列逐漸堆積可能會引發一系列問題。

但在 RocketMQ 5.0，如果某節點發生 FullGC，分配粒度會從隊列退化為消息，分配的消息消費緩慢，不會產生堆積。

因此，從極致彈性和低耦合上可以看出 RocketMQ 5.0 之后使用 Pop 協議的優越性，只需要簡單地在消費能力不足時擴容、富余時縮容，單一節點故障也不會影響到全局。

云可以理解為遠在機房的服務端，端則嵌在業務 SDK。此前，在控制臺上進行運維操作時，只能控制服務端，對客戶端的掌控非常有限，使用體驗非常割裂。比如更改服務端配置，除了白屏也可以通過命令工具輕松修改配置，且及時生效。但如果客戶端修改配置，則會涉及到業務發布，很容易出現問題。

RocketMQ 5.0 采用 telemetry 遙測協議與服務端進行協同。遙測協議的作用為使云和端之間通過 telemetry 進行交互，包括但不限于限流策略、重試策略、發布和訂閱關系管控、可觀測開關、接入點信息、堆棧信息等。主要實現方式為直接由 SDK 向服務端發起 telemetry 請求，然后往 observer 讀寫上圖所示的指令即可。

指令類型包括設置、打印堆棧、驗證消息、消費以及事務消息回查，其中比較關鍵的能力為可觀測開關以及 OTLP 接入點信息。

以往的可觀測是基于消息軌跡實現，在發送消息和消費消息時，將上下文中的參數添加進軌跡消息，在后臺攢批異步發送。上圖為發送消息的所有 context，包括MessageQueue、MessageID 、IP 等信息。

上圖為消費時的 context 。對于單個 MessageID ，端對端會產生三條軌跡消息，分別為發送后、消費前和消費后。如果想要跟蹤消息輪轉軌跡，可以通過查詢軌跡的消息數據找到它，因其將 MessageID 作為 key 值插入到 topic 。而此前需要在控制臺根據 MessageID 查詢軌跡消息。

RocketMQ 此前已經具備可觀測能力，但自定義可觀測方式無法很好地對接現有的可觀測產品和能力。而5.0版本擁有了標準化的可觀測協議，可以使用更豐富、更專業的分析和展示工具，讓可觀測數據有了更高的價值。

Telemetry 遙測協議是將可觀測開關以及接入點下發到客戶端，Proxy 會默認將接入點信息設置為自己，可以將客戶端上報的所有可觀測消息在服務端做收斂，再統一使用標準的 OpenTelemetry 和 Opencensu 兩個協議上報到 SLS ， SLS 再通過 TLog 的方式與 Prometheus、Grafana 進行對接。

Tracing 的數據鏈路比較復雜，也需要先經過 proxy 將可觀測數據導到 proxy 上。而Tracing 的數據量較大，此前也曾考慮過直接通過用戶自定義配置導出接入點，不經過 proxy ，但這會引發其他問題，比如4.x用戶希望接入 RocketMQ 5.0 服務端使用可觀測能力，則需要通過軌跡消息解碼進行解析再通過標準化可觀測協議輸出。

多語言方面，最新出的 OpenTelemetry 支持不一定足夠全面，因此也會需要一些舊的可觀測協議比如 Opencensu，但整體來說，它們都是標準的協議。

03統一模型

此前的 RocketMQ API 缺乏精心設計的消息模型，很多概念沒有明確的定義。比如發送消息時有兩個 ID ，分別是用戶自己定義的 MessageID 和服務端下發的 offsetID 。但是在消費時，下發的 offsetID 又變成了 MessageID ，模棱兩可的定義使得預測客戶行為變得更加困難。并且，此前大多以執行為導向，對開發者并不友好，許多功能是基于實現而不是接口。因此用戶需要觸及到很多細節，需要面對過多冗余和復雜界面，出錯概率極大。

另外，發展多語言生態時，也需要統一模型引導多語言的發展實現。

主題類型是其中一個明顯的改變。

此前，客戶端不做 topic 類型校驗，任何一種類型消息都可以發往 topic 。但是在RocketMQ 5.0 之后會對 topic 類型做校驗，真正從 topic 主題類型上做了區分，比如順序消息 topic 只能發順序消息。此前的 delay 消息為分級別延時消息，而現在為支持毫秒級精度的定時消息，可以支持任意時間精度。

同時，模型定義了各種各樣的消費者，有不同的消費者實現，比如 PushConsumer 、PullConsumer 以及 SimpleConsumer ，底層均使用 pop 協議實現。比如以前的PushConsumer 是基于手動拉的方式，而現在采用了 pop 方式。

SimpleConsumer 的使用方法非常簡單，直接調用 receive message 接口，獲取到消息之后進行消費，消費成功則進行 Ack；如果消費失敗，則更改可見時間。整體流程非常直觀，完全基于接口定義。

新版本的啟動流程增加了準備工作，為了能夠更早地捕捉到明顯的錯誤以及異常，比如嘗試從服務端獲取設置，可以對此類設置進行熱更新，稱為服務器和客戶遙測，任何準備失敗都會導致客戶端啟動失敗，而以往可以強行將客戶端拉起，然后不斷進行重試。

增加了準備工作后，配置問題或本身網絡問題可以提前被發現，比如 topic 路由信息不存在，啟動時會先對 bonding topic 做檢查，每一個發送者、生產者可以提前設置預留 topic 信息，再根據錯誤信息進行檢查，判斷是否可以啟動。