这个需求估计还挺普遍的，这里分享一些经验。 一、MQ架构简述
如上图，使用MQ异步通信，一般分为三层：
消息发送方 ：使用MQ客户端生成消息。MQ-client::SendMsg(topic, msg);
MQ服务 ：中转消息。 消息接收方 ：使用MQ客户端消费消息。MQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
这是一个典型的pub-sub架构，如果要替换MQ供应商，至少 三个地方要替换 ：发送方mq-client
MQ-server
接收方mq-client
如上图所示，不妨设：
粉色是旧MQ体系
蓝色是新MQ体系
第二步升级生产方，由旧MQ发布，升级为新MQ发布。
此时，“新发布-新服务-新订阅”之间会建立TCP连接，消息会转移到新通道（上图实线），“旧服务-旧订阅”之间虽然有TCP连接，但实际不会有消息发送过来（上图虚线）。 步骤三：消费方下线旧订阅
第三步升级消费方，将旧订阅下线，整个MQ的迁移完成。
三、架构启示 MQ更换服务商，蚂蚁搬家，一步步平滑迁移，成本其实还挺高的。 之所以这么麻烦，不能统一升级，本质是 业务与底层基础设施细节 （即，具体使用哪个MQ）的 耦合 。如果公司在早期技术体系规划的时候，能够“浅浅的封装一层”，便能隔离“业务代码”与“底层基础设施细节”。 举个更通俗的例子。 假如没有封装一层，业务代码是：ActiveMQ-client::SendMsg(topic, msg);
ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
即，业务方需要关心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平滑迁移的问题，先聊这么多，希望能解答杨紫琼同学的问题。
本文转自“架构师之路”公众号，58沈剑提供。
