前几天,杨紫琼同学在知识星球提问,说公司要切换MQ,从一个旧的服务商升级为新的服务商,问有没有什么好方案。
这个需求估计还挺普遍的,这里分享一些经验。
MQ-client::SendMsg(topic, msg);
MQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
这是一个典型的pub-sub架构,如果要替换MQ供应商,至少
三个地方要替换
:
发送方mq-client
MQ-server
接收方mq-client
如果有很多主题,需要一个一个主题的迁移,每个主题的迁移,分为三个步骤。
平滑迁移最终目的,是“发布-服务-订阅”三层全由粉色升级为蓝色。
第一步升级消费方,同一个主题,既要订阅旧MQ,又要订阅新MQ
。
此时,“新服务-新订阅”之间虽然有TCP连接,但“新发布”没有上线,实际上不会有消息发送过来(上图虚线),消息仍走的是旧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升级。
ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
}
ShenJianMQ::SendMsg(topic, msg){
RabbitMQ-client::SendMsg(topic, msg);
}
ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
}
会发现,除了升级依赖新版的ShenJianMQ基础组件,
业务代码不需要修改代码
。
不仅
MQ,缓存与数据库的客户端,浅浅封装一层
也能实现业务代码与基础组件的解耦,在基础组建替换,或者基础组建升级的时候,业务代码不需要升级。
画外音:浅浅封装一层之后,监控/告警/数据收集等工作都更容易统一实现了。
关于MQ平滑迁移的问题,先聊这么多,希望能解答杨紫琼同学的问题。
知识星球-刚开始玩