有位朋友问我，如果想更换消息队列（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平滑迁移的技巧，大家都掌握了吗？知其然，更要知其所以然。有时候，解决问题的思路比具体结论更为重要。
