和开源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进行灰度操作，迁移过程中有业务风险可随时回滚。