5.0速览

為何選擇 RocketMQ 5.0​

自 Apache RocketMQ 誕生以來，因其架構簡單、業務功能豐富、具備極強可擴充性等特點被眾多企業開發者以及雲廠商廣泛採用。歷經十餘年的規模場景打磨，RocketMQ 已成為業界共識的金融級可靠業務訊息首選方案，被廣泛應用於網際網路、大數據、行動網際網路、物聯網等領域的業務場景。儘管 RocketMQ 在開源社群已走過了十多個年頭，但在企業架構雲原生浪潮下，我們一直在思考 RocketMQ 的架構演進以及對上層集成的價值提升。Apache RocketMQ 5.0 的演進目標有三個： 訊息基礎架構的雲原生化演進：充分結合雲原生大潮下的基礎設施和生態技術，提高資源利用和彈性能力。 整合效率的痛點升級優化：從 API、SDK 多方面重構設計，為開發者提供更加簡單易用、輕量易集成的方案； 事件、流整合場景拓寬：我們將以當前業務集成的能力為基礎進一步聚焦訊息領域的後處理場景，支援訊息的流式處理和輕計算，幫助使用者實現訊息的就近計算和分析，並將全面擁抱 Serverless 和 EDA。

RocketMQ 5.0 的新功能​

基础架构云原生化升级​

RocketMQ 自誕生以來就一直堅持簡潔架構，比如元資料採用最終一致性設計，只引入幾百行程式碼的無狀態 NameSrv 組件。相較於其他產品依賴 ZK 進行元資料的管理維護，RocketMQ 的優勢是顯而易見的。隨著企業上雲的進一步普及以及雲原生技術趨勢的演進，集成的網路環境更加複雜，企業開發者對效率也有了更高的要求，我們看到當前的架構還存在一定的不足。當前的架構下儲存和計算資源的靈活匹配相對困難，特別是在如今企業上雲逐步普及的情況下，雲廠商的計算資源和儲存資源之間解耦靈活的彈性策略可以更好的實現降本提效。

RocketMQ 5.0 引入了全新的彈性無狀態代理模式，將當前的 Broker 職責進行拆分，對於客戶端協定適配、權限管理、消費管理等計算邏輯進行抽離，獨立無狀態的代理角色提供服務，Broker 則繼續專注於儲存能力的持續優化。這套模式可以更好地實現在雲環境的資源彈性調度。值得注意的是 RocketMQ 5.0 的全新模式是和 4.0 的極簡架構模式相容相通的，5.0 的代理架構完全可以以 Local 模式運行，實現與 4.0 架構完全一致的效果。開發者可以根據自身的業務場景自由選擇架構部署。

輕量 API 和多語言 SDK​

除了架構改變，RocketMQ 5.0 重新思考了面向開發者的整合介面，即 API 和 SDK 的設計。RocketMQ 4.x SDK 是比較重量級的富客戶端模式，提供了諸如順序消費、廣播消費、消費者負載均衡、訊息快取、訊息重試、位元管理、推拉結合、流控、診斷、故障轉移、異常節點隔離等一系列能力。這些複雜能力雖然可以幫助業務整合解決實際問題，但其自身的演進和迭代卻存在比較大的負擔，客戶端的升級和多語言普及難度較大。從 API 的簡潔性和友善性方面，RocketMQ 5.0 正在做輕量化設計。

RocketMQ 5.0 推出了基於 gRPC 全新的多語言 SDK，這套 SDK 有幾個重要特點： 採用全新極簡的 API，擁有不變 API 的設計，完善的錯誤處理，各語言 SDK API 在本地語言層面對齊，新的 API 化繁為簡，更易被使用和整合。 採用雲原生的 RPC 標準框架 gRPC，標準的傳輸層框架，更易被攔截，特別適合被 Service Mesh 整合從而賦予其更多的傳輸層基礎能力。 客戶端輕量化，以典型的「SimpleConsumer」為代表，採用全新的面向訊息的無狀態消費模型，整個 SDK 從程式碼到執行時都極為輕量。輕量化是一種非常重要的能力，如果各個中間件都採取富客戶端的形式，這些中間件當被一起植入到 Sidecar 中時，也會是一個非常龐大的 Sidecar，應用框架集成的複雜度非常高。

除了 API/SDK 的設計最佳化，RocketMQ 5.0 還引入了無狀態消費模式，即 Pop 機制，創新地在佇列模式之上支援了無狀態的消息模式，在一個主體上同時支援兩種消費模式，體現了訊息和流的「二象性」。面向流場景採用高性能的佇列模式進行消費；面向訊息的場景，採用無狀態的消息模式進行消費。業務可以只關心訊息本身，透過「SimpleConsumer」提供單條訊息級別的消費、重試、修改不可見時間、以及刪除等 API 能力。

事件、流处理场景集成​

除了上述基礎架構以及 API 整合的變化，RocketMQ 5.0 基於業務訊息的基礎優勢，RocketMQ 5.0 進一步拓寬在訊息後處理計算的場景挖掘。支援訊息的串流處理和輕計算，幫助使用者實現訊息的就近計算和分析，並且全面擁抱 Serverless 和 EDA。

伴隨著企業雲原生化進程的加速，計算力的構成越來越多元化，透過事件驅動架構來開發雲原生應用是一件非常順理成章的事情。RocketMQ 5.0 正是基於此技術趨勢大潮開放了相容標準 CloudEvents 協定的 RocketMQ-EventBridge 元件。EventBridge 提供豐富的跨產品、跨平台連接能力，能夠促進雲廠商、企業應用、SaaS 服務三者相互整合。EventBridge 的目標是以統一開放的標準連結社群活躍的生態，同時能與各個雲廠商的「Hub」類產品進行整合，來達到開源和雲的資料互通，助力企業客戶輕鬆上雲和下雲。

在訊息串流處理場景，RocketMQ 5.0 將目前的佇列下沉為物理佇列，上層重新抽象了邏輯佇列。一個邏輯佇列可以包含多個物理佇列，各個物理佇列都作為邏輯佇列的一個片段，以此拼接出真正的串流佇列。也因此可以做到更輕量，秒級擴縮，在物理節點發生變化時不涉及到存量資料複製遷移；實現資料儲存的靈活調度，配合 TTL 實現無限儲存能力。同時，應對流的高吞吐場景，RocketMQ 5.0 優化裡儲存批次處理的讀寫效能。

在計算架構方面，RocketMQ 5.0 引入了一套輕量級串流處理架構 RSteams。RStreams 依賴少、部署簡單，可任意橫向擴展，利用 RocketMQ 資源即可完成輕量級的資料處理和計算。除此以外，為了方便開發者讓基於 RocketMQ 的串流計算更容易，RocketMQ 5.0 還支援了一套輕量 SQL 查詢引擎 RSQLDB，為開發者提供基於 SQL 的開發體驗。RSQLDB 首創性地相容了 Flink/Blink SQL 標準以及 UDF/UDAF/UDTF，使得兩個開源產品的生態可以更好地融合，開發者可以將 Flink/Blink 已有 SQL 計算任務遷移到 RocketMQ，在 RocketMQ 內部完成輕量級的計算處理，在算力受限或者更大規模的場景下，同樣可以將 RocketMQ 的即時計算任務遷移到 Flink，利用 Flink 的大資料計算能力滿足業務訴求。

如何升級到 5.0​

RocketMQ 5.0 在完成上述架構升級、API 重構和新功能場景時，統一遵循了向下相容的原則。RocketMQ 4.x 版本可以無縫升級到 5.0 版本同時保持對歷史版本 SDK 的相容。選擇 5.0 版本無需擔心不相容歷史版本的應用。我們建議升級伺服器端版本後，儘快替換使用新版本的 SDK 以獲得更好的接入體驗和新功能。