解密MQ平滑迁移：架构师的必备实战指南

有位朋友问我，如果想更换消息队列（MQ），把旧的消息服务商升级成新的，整个切换过程能否做到平滑无误呢？今天我们就来深入探讨这个问题。

之前我们聊过《MySQL如何实现不停机平滑迁移？》，而最近有朋友又提出了类似的需求，问我们能否像迁移数据库那样，在更换MQ服务商时也能无缝衔接。今天我们就一起聊聊具体的操作方案。

一、MQ架构简述

如上图所示，使用MQ进行异步通信通常包含三个关键环节：

消息发送方：通过MQ客户端生成消息。

MQ-client::SendMsg(topic, msg);

MQ服务端：负责消息的存储和转发。

消息接收方：通过MQ客户端消费消息。

MQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);

这是一个典型的发布-订阅架构。如果希望替换MQ提供商，至少需要对以下三个部分进行替换：

• 发送方的客户端组件
• MQ服务端集群
• 接收方的客户端组件

二、平滑迁移方案

平滑迁移的核心目标是：在保证服务不中断的前提下，逐步完成系统升级。

如果系统中有多个主题（topic），需要对每个主题进行逐一迁移。每个主题的迁移可分为三个清晰的阶段。

步骤一：消费方实现双向订阅

如图所示，我们假设：

• 粉色部分代表旧版MQ体系
• 蓝色部分代表新版MQ体系

平滑迁移的最终目标，是实现“发布-服务-订阅”三层完全从粉色体系升级到蓝色体系。

第一步先升级消费方：针对同一主题，既要订阅旧版MQ，也要订阅新版MQ。

此时，“新版服务-新版订阅”之间虽然建立了TCP连接，但由于“新版发布”尚未上线，实际不会有消息通过新版通道传输（上图中虚线所示），消息仍然沿用旧版MQ通道（上图中实线所示）。

步骤二：生产方升级为新发布

第二步升级生产方：将原来通过旧版MQ发布消息的方式，切换到通过新版MQ进行发布。

此时，“新版发布-新版服务-新版订阅”之间会建立完整的TCP连接，消息将转入新通道传输（上图中实线所示）；而“旧版服务-旧版订阅”之间虽然仍有TCP连接，但实际上已不会有新消息通过（上图中虚线所示）。

步骤三：消费方下线旧订阅

第三步是完成消费方的升级：将旧版订阅完全下线，整个MQ迁移过程就圆满完成了。

三、架构启示

更换MQ服务提供商就像搬家一样，如果希望平稳过渡，成本其实相当高。之所以过程如此繁琐，无法一步到位，根本原因在于业务代码与底层基础设施之间存在着紧耦合关系（具体体现在使用了哪个特定的MQ服务）。

如果企业在早期技术体系规划时，能够“浅浅地封装一层”，就能有效隔离“业务代码”与“底层基础设施实现细节”。

举个通俗的例子来说明。如果中间没有封装层，业务代码会直接依赖具体实现：

ActiveMQ-client::SendMsg(topic, msg);ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);

这意味着业务方需要关心具体的MQ实现，比如ActiveMQ。如果基础设施升级为RabbitMQ，业务代码就需要相应调整。

但如果有一层浅浅的封装：

ShenJianMQ::SendMsg(topic, msg){ActiveMQ-client::SendMsg(topic,msg);}ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC){ActiveMQ-client::RecvMsg(topic,msg, CALLBACK_FUNC);}

业务方就无需关注底层具体使用哪种MQ，只需要依赖基础组件ShenJianMQ即可。

此时如果基础设施升级为RabbitMQ，只需升级基础组件ShenJianMQ：

第一步：RecvMsg升级为双向订阅。

ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC){ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);}

第二步：SendMsg升级为新发布。

ShenJianMQ::SendMsg(topic, msg){RabbitMQ-client::SendMsg(topic, msg);}

第三步：RecvMsg下线旧订阅。

ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC){RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);}

你会发现，除了需要升级新版ShenJianMQ基础组件外，业务代码完全不需要修改。

不仅仅是MQ，缓存与数据库的客户端，通过浅浅封装一层也能实现业务代码与基础设施的解耦。这样在基础设施需要更换，或者基础设施升级时，业务代码都不需要跟着升级。

MQ平滑迁移的技巧，大家都掌握了吗？知其然，更要知其所以然。有时候，解决问题的思路比具体结论更为重要。