和開源Apache RocketMQ相比，阿里雲雲訊息佇列 RocketMQ 版具有更高的穩定性、安全性及更完善的營運體系。您可以將開源RocketMQ叢集遷移到雲訊息佇列 RocketMQ 版上以獲得更好的業務體驗，本文為您介紹開源RocketMQ叢集遷移上雲的方案及原理。
產品差異對比
和開源RocketMQ相比，阿里雲雲訊息佇列 RocketMQ 版在技術架構、彈性效率、營運複雜度及企業級產品能力方面具備明顯優勢，其差異對比如下：
對比項 | 自建開源RocketMQ叢集 | 雲訊息佇列 RocketMQ 版5.x系列 |
儲存彈性 | 無資源集區，一般採用存算一體架構。 | 充分利用雲基礎設施大規模資源集區，存算分離架構。 |
API/SDK接入 | 支援Apache RocketMQ SDK。 |
|
技術架構 |
|
|
計算彈性 |
|
|
營運複雜度 |
|
|
穩定性保障 | 自行營運保障，需要資深技術人員儲備。 | 提供明確服務能力的SLA保障：
|
企業級增強能力 | 自行定製開發，需要資深技術人員儲備。 | 開箱即用，提供全鏈路灰階、訊息路由複製、ETL、事件整合分析等增強能力。 |
體系化容災能力 | 自行營運保障，需要資深技術人員儲備。 | 提供以下體系化容災方案：
|
遷移方案原理
方案基本要求
RocketMQ廣泛應用於訂單交易、線上支付等核心鏈路情境，訊息收發的上下遊鏈路對Message Service的穩定性要求比較嚴格，因此RocketMQ叢集的遷移和替換必須謹慎，遷移方案的設計需要滿足以下要求：
服務不中斷
保證遷移過程中上層的訊息收發應用無感知，不會出現大量報錯和失敗。
訊息收發無大量重複
保證遷移過程中不會出現大量的訊息重複，業務方無需為遷移方案單獨處理系統性重複訊息。
訊息收發無明顯延遲
保證遷移過程中訊息收發端到端延遲不會有明顯變化，不會因遷移導致大量訊息接收不到。
方案設計原理
為滿足以上遷移要求，雲訊息佇列 RocketMQ 版提供對業務無感知可平滑切換的遷移工具，覆蓋中繼資料遷移（Topic、Group、消費進度等）及業務訊息遷移。
中繼資料遷移：通過讀取源自建RocketMQ叢集的中繼資料資訊，並複製到目標阿里雲雲訊息佇列 RocketMQ 版叢集中，實現中繼資料的建立和同步。
訊息遷移：通過雲訊息佇列 RocketMQ 版內建的路由控制組件後台代理Topic路由資訊，實現對用戶端讀寫流量的動態切換，切換過程業務無感知。
如上圖所示，假設源叢集TopicA的原始讀分區為8個，寫分區為8個。
目的地組群通過中繼資料遷移任務同樣建立了TopicA，且讀寫分區數和源叢集一致。
當進入訊息遷移流程時，雲訊息佇列 RocketMQ 版通過路由控制組件，同時控制源叢集和目的地組群的Topic路由資訊，根據不同的遷移階段動態向用戶端返回讀寫分區資訊。例如：
雙讀情境下：同時返回源叢集和目的地組群共計16個讀分區資訊。
唯寫目的地組群：只返回目的地組群的8個分區。
遷移方案優勢
雲訊息佇列 RocketMQ 版遷移上雲方案基於阿里雲訊息佇列自研的訊息路由中繼資料代理組件實現，可支援Topic粒度的訊息收發路由調度及切流量控制。該方案具備如下優勢：
服務不中斷、訊息收發影響小
遷移方案支援無感切換，在切流期間訊息收發不中斷，業務應用無感知，出現訊息延遲和訊息重複問題幾率非常小。
無需額外資源
業務方應用無需為遷移上雲進行擴容或部署多套叢集，遷移過程僅需要業務方進行配置滾動升級變更，無需額外的機器資源。
業務入侵小、易實施
遷移過程中僅需要相關業務應用更改存取點配置並重啟應用一次，後續切流全部由雲訊息佇列 RocketMQ 版服務端動態配置生效。訊息的上下遊鏈路可自由升級，無需梳理收發鏈路依賴。整個操作流程影響範圍小，便於上下遊業務配合實施。
可灰階、可復原
遷移任務粒度精確到Topic層級，可以按照指定Topic進行灰階操作，遷移過程中有業務風險可隨時復原。