看看这波自建迁移上云，smooth 不 smooth？

导语

零改造、低侵入，RocketMQ 平滑迁移上云实践。

在迁移上云场景遇到的疑问和挑战

当前，随着企业对更高并发量、更多使用场景、更强计算能力、更加稳定安全的业务环境的追求，迁移上云已经是企业数字化发展的必然趋势。但对不少企业来说，迁移上云往往是一个重大且艰难的决定。迁移的过程虽不至于历经九九八十一难，但是“向云端”依旧会是一段颠簸的旅途。

尤其对于 RocketMQ 来说，作为连接生产者和消费者的 “通道型” PaaS 产品，迁移上云更是面临着巨大的挑战：

• 业务连续性：RocketMQ 作为在线消息场景的 “扛把子”，承担着大量在线核心业务，迁移过程中业务的连续性和稳定性是重中之重。只要保证迁移期间业务不间断并且足够稳定，就能为繁杂的迁移任务争取更多时间，避免“业务低峰通宵迁移，临近清晨被迫回滚”的人间惨剧再次上演。

• 代码改造量：潜在的代码改造量也是压在迁移路上的一座大山，迁移不应该是大拆大建，好的云产品都是要有人性关怀的，要尽可能减少迁移的侵入性和代码改动，最好一行都不改。

• 数据完整性：数据是企业重要的无形资产，一旦丢失或泄露，后果不堪设想。而RocketMQ 上云的过程中，保证消息不丢也是至关重要的。

• 迁移过程完全可控：迁移可以按照较小的粒度（如 Topic 粒度）分批迁移，整个过程的可观测、可灰度、可回滚也非常重要，这样确保迁移的操作者还是企业的运维人员能够实时查看迁移过程新老集群两侧的流量变化，如果出现异常可以直接回滚，极大程度地提高迁移过程中的容错率。

那真的有办法可以满足上面的要求么？

有，划重点！腾讯云 RocketMQ 无感迁移上云功能！

腾讯云 RocketMQ 无感迁移上云功能介绍

无感迁移功能是腾讯云 RocketMQ 面向自建集群迁移上云场景研发的白屏化无感迁移工具。通过白屏化的按步骤操作，只要保证网络连通的场景下，可以将任意部署环境（如各个云厂商、自建 IDC 等等）下的 RocketMQ 集群迁移到腾讯云 RocketMQ 集群上。

相比传统 “双读双写” 的迁移方式，客户无需梳理不同业务应用之间的生产消费依赖关系；作为迁移项目的负责人，也无需协调各内部业务方依次完成改造切换。因此极大降低了迁移过程中的阻力，缩短了迁移周期。

那么，迁移步骤是如何实现的呢？

腾讯云 RocketMQ 迁移上云实践

迁移概览

整体的迁移步骤分为以下五个步骤：

以上步骤太复杂？可以查看下文详细步骤。当然控制台也在每个步骤上方提供了详细的拓扑图供参考。

详细步骤展示

前提条件

在开始无感迁移任务前，登录 RocketMQ 控制台创建一个迁移任务，根据业务需求选择源集群和目标集群，目标集群可以根据实际需要选择 RocketMQ 4.x 专享集群或者 RocketMQ 5.x 集群。

说明：在创建任务前，需评估好源集群当前的流量情况。

步骤1：连接源集群

迁移任务创建完成后，进入连接源集群步骤，确认好网络连接类型，填写源集群的相关信息。

说明：在网络打通（专线和云联网）/公网的前提下，支持各个厂商的自建集群和商业化集群的无感迁移。

步骤2：导入元数据

在成功连接到源集群的 NameServer 后，开始将源集群的元数据同步到目标集群。

迁移工具会自动扫描出源集群的相关元数据，即 Topic 和 Group 等，如下图所示，在页面上确认 Topic 和 Group 的相关信息，确认无误后，单击操作列的“确认并导入“按钮进行确认。

步骤3：修改源集群接入点

在确认需要迁移的元数据都完成导入后，根据页面的指引，修改所有客户端的接入点地址。

客户端修改接入点后，迁移工具会将流量转发到源集群上，实际各个客户端连接的还是源集群，故本步骤不会产生风险。

通过查看接入点修改详情列表页展示的各个 Topic 连接的客户端个数和最近连接时间，可以判断是否所有的客户端均完成接入点的修改。

确认所有客户端的接入点均已修改完成，则正式进入切流阶段。

步骤4：灰度迁移消息

在灰度迁移阶段，迁移工具将按 Topic 粒度进行逐个迁移，按照 “初始状态（读写源集群） > 开启双读（写源集群双读） > 双读双写 > 切流中（写目标集群双读） > 切流完成（读写目标集群）” 的顺序进行迁移，迁移过程中，每个状态均可以回滚到上一个状态：

• 初始状态：读写源集群状态，是迁移的起始状态，读写流量经过迁移组件代理转发，依旧访问源集群，因此对业务侧无侵入。

• 开启双读：消息生产者客户端写源集群，同时消息消费者同时读取来自源集群和目标集群的流量。

• 双读双写：消息生产者客户端发送的消息随机到源集群或者目标集群，您可以在监控页面查看不同集群的流量；同时消息消费者同时读取来自源集群和目标集群的流量。

• 切流中：消息生产者客户端写目标集群，同时消息消费者同时读取来自源集群和目标集群的流量。您需要在此阶段验证新的消息收发链路无异常，并等待源集群存量消息消费完成。

• 切流完成：在上一步确认新的消息收发链路符合预期后，在源集群已经消费所有消息并无堆积情况下，进入读写目标集群状态，全部读写流量只访问目标新集群。

在迁移过程中：

• 通过查看是否就绪列的内容，查看 Topic 是否具备迁移条件。

• 通过操作列的健康检查 按钮进行单个 Topic 的实时检查，迁移工具会间隔一段时间进行批量扫描。达到 “已就绪” 状态的 Topic 可以进入下一阶段。

• 在切流过程中，通过操作列的单击 回滚，可以进行单个 Topic 或者批量的状态回滚。

步骤5：完成迁移

在所有 Topic 均到 “切流完成” 状态后，即完成整个迁移过程。

迁移完成后，即所有的 Topic 和客户端均完成迁移，所有的消息流量均在 TDMQ RocketMQ 上运行。此时可以通过查看目标集群和源集群的监控，后续可以逐步下线源集群。

以上操作步骤可以查看官网文档：

https://cloud.tencent.com/document/product/1493/98868

您也可以戳下方链接查看完整视频教程。

https://www.bilibili.com/video/BV1UosBe1Eo6/?vd_source=479307cf5f3abfaabd9d90eb33158e29

迁移上云案例

以某泛金融用户为例

客户痛点

• 集群数8个，Topic 数568，消费组4787个。
• 按照传统的”双读双写”方案，需要梳理清楚业务之间的生产消费依赖关系，先切消费方应用，再切生产方应用，推动协调各个业务团队按顺序修改接入点，将 MQ 集群从自建切换到云上。
• 预计迁移周期长达数月，客户运维侧业务推动阻力极大，动力不足，基本无法落地。

客户诉求

• 切换前是否能不依赖业务生产消费顺序。
• 切换过程中是否可以灰度先小范围验证。
• 切换过程中有问题是否能及时回滚。

方案优势

• 不需要梳理上下游依赖，统一修改接入点至云上集群，减少业务侵入。
• 支持按 Topic 分批创建迁移任务，可灰度，可回滚，可监控，降低迁移风险。
• 使用云上平滑迁移方案后，一个月内完成全部业务的迁移和割接。
  
  

未来展望

同步迁移出实效，可视操作见真章。

未来 RocketMQ 还将进一步提升无感迁移过程中的体验，结合新增功能（未及时修改接入点的客户端提醒、源集群和目标集群监控指标对比等），进一步提升迁移过程的可观测、可灰度、可回滚能力。