标签:fun 不能 如何 关于 更换 平滑 代码 相关 消费
前几天,杨紫琼同学在知识星球提问,说公司要切换MQ,从一个旧的服务商升级为新的服务商,问有没有什么好方案。这个需求估计还挺普遍的,这里分享一些经验。
如上图,使用MQ异步通信,一般分为三层:
消息发送方:使用MQ客户端生成消息。
MQ-client::SendMsg(topic, msg);
MQ服务:中转消息。
消息接收方:使用MQ客户端消费消息。
MQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
这是一个典型的pub-sub架构,如果要替换MQ供应商,至少三个地方要替换:
平滑迁移的目标是:不停服,平滑升级。
如果有很多主题,需要一个一个主题的迁移,每个主题的迁移,分为三个步骤。
如上图所示,不妨设:
第一步升级消费方,同一个主题,既要订阅旧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升级。
第一步: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平滑迁移的问题,先聊这么多,希望能解答杨紫琼同学的问题。
知识星球-刚开始玩
刚开始玩知识星球,欢迎大家提问。
画外音:所有提问都会细心解答(如这一篇)。
上次开放了200个名额一下就满了,再开放500个名额(人不宜太多,怕解答不过来)。
《基础组件,究竟要不要自研?》
《什么时候不能使用MQ》
《究竟什么时候使用MQ》
《MQ消息可达性+幂等性+延时性架构设计》
贵司有浅浅封装?还是自研?还是原生耦合?
标签:fun 不能 如何 关于 更换 平滑 代码 相关 消费
原文地址:https://blog.51cto.com/jyjstack/2548563