|
|
51CTO旗下网站
|
|
移动端
创建专栏

高速飞机上换引擎,MQ如何实现平滑迁移?

前几天,杨紫琼同学在知识星球提问,说公司要切换MQ,从一个旧的服务商升级为新的服务商,问有没有什么好方案。这个需求估计还挺普遍的,这里分享一些经验。

作者:58沈剑|2019-08-09 08:05

前几天,杨紫琼同学在知识星球提问,说公司要切换MQ,从一个旧的服务商升级为新的服务商,问有没有什么好方案。

这个需求估计还挺普遍的,这里分享一些经验。

一、MQ架构简述

如上图,使用MQ异步通信,一般分为三层:消息发送方:使用MQ客户端生成消息。

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

MQ服务:中转消息。 消息接收方:使用MQ客户端消费消息。

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

这是一个典型的pub-sub架构,如果要替换MQ供应商,至少三个地方要替换:

  • 发送方mq-client
  • MQ-server
  • 接收方mq-client

如何平滑迁移,是今天要讨论的话题。

二、平滑迁移方案

平滑迁移的目标是:不停服,平滑升级。 如果有很多主题,需要一个一个主题的迁移,每个主题的迁移,分为三个步骤。

步骤一:消费方双向订阅

如上图所示,不妨设:

  • 粉色是旧MQ体系
  • 蓝色是新MQ体系

平滑迁移最终目的,是“发布-服务-订阅”三层全由粉色升级为蓝色。 第一步升级消费方,同一个主题,既要订阅旧MQ,又要订阅新MQ。

此时,“新服务-新订阅”之间虽然有TCP连接,但“新发布”没有上线,实际上不会有消息发送过来(上图虚线),消息仍走的是旧MQ(上图实线)。

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

第二步升级生产方,由旧MQ发布,升级为新MQ发布。

此时,“新发布-新服务-新订阅”之间会建立TCP连接,消息会转移到新通道(上图实线),“旧服务-旧订阅”之间虽然有TCP连接,但实际不会有消息发送过来(上图虚线)。

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

第三步升级消费方,将旧订阅下线,整个MQ的迁移完成。

三、架构启示

MQ更换服务商,蚂蚁搬家,一步步平滑迁移,成本其实还挺高的。

之所以这么麻烦,不能统一升级,本质是业务与底层基础设施细节(即,具体使用哪个MQ)的耦合。如果公司在早期技术体系规划的时候,能够“浅浅的封装一层”,便能隔离“业务代码”与“底层基础设施细节”。

举个更通俗的例子。

假如没有封装一层,业务代码是:

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

即,业务方需要关心ActiveMQ,如果基础设施升级为RabbitMQ,业务代码需要升级。 假如有一层浅浅的封装:

  1. ShenJianMQ::SendMsg(topic, msg){ 
  2. ActiveMQ-client::SendMsg(topic,msg); 
  3.   
  4. ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC) 
  5. ActiveMQ-client::RecvMsg(topic,msg, CALLBACK_FUNC); 

业务方不需要关心底层是什么MQ,而只需要依赖基础组件ShenJianMQ。

此时如果基础设施升级为RabbitMQ,只需要基础组件ShenJianMQ升级。

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

  1. ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC) 
  2. ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC); 
  3. RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC); 

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

  1. ShenJianMQ::SendMsg(topic, msg){ 
  2. RabbitMQ-client::SendMsg(topic, msg); 

第三步:RecvMsg下线旧订阅。

  1. ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC) 
  2. RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC); 

会发现,除了升级依赖新版的ShenJianMQ基础组件,业务代码不需要修改代码。

不仅MQ,缓存与数据库的客户端,浅浅封装一层也能实现业务代码与基础组件的解耦,在基础组建替换,或者基础组建升级的时候,业务代码不需要升级。

画外音:浅浅封装一层之后,监控/告警/数据收集等工作都更容易统一实现了。

关于MQ平滑迁移的问题,先聊这么多,希望能解答杨紫琼同学的问题。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

【编辑推荐】

  1. 交易峰值突增1200倍,阿里基础设施架构如何演进?
  2. 数据库软件架构,到底要设计些什么?
  3. 1万属性,100亿数据,每秒10万吞吐,架构如何设计?
  4. 互联网架构的演变,看了好多这个讲的确实清楚!
  5. AI中台——智能聊天机器人平台的架构与应用
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢