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