如何从ActiveMQ平滑迁移到Kafka?

  1. 云栖社区>
  2. 程序员DD>
  3. 博客>
  4. 正文

如何从ActiveMQ平滑迁移到Kafka?

技术小能手 2018-09-14 14:49:52 浏览1875
展开阅读全文

直入主题,不讨论为什么迁移,直接谈迁移方案。


既然是从AMQ(AtiveMQ的简称)迁移到kafka,那么迁移过程中肯定需要做到平滑迁移:对于业务没有影响,对于上下游系统没有依赖。由于系统一般会和多个上游,多个下游通过MQ中间件保持依赖关系,迁移的过程中,肯定要做到各个系统上线没有任何依赖。打个比方订单系统发送topic,会员系统和积分系统都会接收这个topic(会员增加成长值,积分系统加积分)。改造后发布时,订单系统,会员系统,积分系统三个系统上线应该可以任意顺序,任意时间发布上线。


依赖关系


给出具体方案之前,先捋一下各个系统之间的依赖关系。再复杂的系统,和其他系统之间的依赖关系也就如下图所示,假设我们关注的是系统H。它会接受上游系统A和B发送的topic,以及给下游系统X,Y和Z发送topic(说明:下图是系统依赖关系图,而不是实例关系依赖图)。


75207f3bf5bc39309017fc281fa4e4692e38fd9c


根据这张架构图,我们将消息分为几个类型:

  • 生产型(1-1)--这种消息由本身系统H发送,下游系统X,Y,Z中任意且只有一个系统消费(AMQ中Queue的使用场景);

  • 生产型(1-N)--这种消息由本身系统H发送,下游系统X,Y,Z中任意多个系统消费(AMQ中VirtualTopic的使用场景);

  • 消费型--这种消息由上游系统例如A或者B发送,系统H负责消费;

  • 自产自消型--这种消息由本身系统H发送,本身系统H负责消费


VirtualTopic


生产型(1-N)消息,不能认为是Topic的使用场景,而应该是VirtualTopic的使用场景(至少大部分情况下)。两者的区别如下图所示(AMQ的VirtualTopic具体用法网上一大堆,这里就不累述了):


abd3caa6ec334ca0475a66efb5396dd195495356


如上图所示,系统X有三个实例X-1,X-2,X-3;系统Y有三个实例Y-1,Y-2,Y-3。如果系统H发送一个VirtualTopic,假如名为:


VirtualTopic.PAY_SUCCESS_ORDER。


系统X和系统Y分别接收队列:


VConsumers.memberGroup.VirtualTopic.PAY_SUCCESS_ORDER


VConsumers.pointIssue.VirtualTopic.PAY_SUCCESS_ORDER。


那么系统X的三个实例只会有一个实例接收到


VConsumers.memberGroup.VirtualTopic.PAY_SUCCESS_ORDER,


系统Y的三个实例也只有一个实例接收到


VConsumers.pointIssue.VirtualTopic.PAY_SUCCESS_ORDER。


如果系统H发送一个Topic,假如名为


PAY_SUCCESS_ORDER


那么系统X的三个实例和系统Y的三个实例都会接收到这个Topic。


接下来我们分别讨论这几种消息如何做到平滑迁移(假定系统H就是我们要改造的系统)。


消费型


这类消息由于我们的系统H是消费者,即被动方,我们不确定上游系统A和B的发送方式什么时候从AMQ切换到kafka,另外我们无法预知我们订阅的AMQ存量消息什么时候消费完。所以对于这种类型的消息,系统H在改造时要保留原来的AMQ消息接收方式,同时需要新增kafka消息接收方式即可。


生产型(1-1)


这种场景就是AMQ中Queue的使用场景。这类消息由于我们的系统H是生产者,即主动方。且依赖关系比较简单,就是1对1。但是考虑到下游系统即消费者不确定什么时候加入kafka接收方式。所以,我们重构时AMQ发送方式要保留,kafka发送方式也要新增。但是需要在发送的地方增加一个开关,在两种发送方式之间切换。当下游系统即消费者引入kafka接收方式后,这个开关就可以切换到kafka发送。生产者的AMQ发送方式的代码和开关在下一个版本就可以删除了。同理,这个消费者的AMQ消费方式在下一个版本也可以删除。


生产型(1-N)


这种场景就是AMQ中VirtualTopic的使用场景。这类消息由于我们的系统H是生产者,即主动方。但是依赖关系相比Queue使用场景要复杂一点,因为消费者比较多。考虑到若干个下游系统即消费者不确定什么时候加入kafka接收方式。所以,我们重构时AMQ发送方式要保留,kafka发送方式也要新增。但是需要在发送的地方增加一个开关,在两种发送方式之间切换。当下游系统即消费者全部引入kafka接收方式后,这个开关就可以切换到kafka发送。生产者的AMQ发送方式的代码和开关在下一个版本就可以删除了。同理,若干个消费者的AMQ消费方式在下一个版本也可以删除。


自产自消型


这种类型的消息,即使消息的生产和消费都在我们的系统H中,整个过程我们能够完全掌控。如果不考虑多个实例之间部署的时间差,那么直接将AMQ的发送方式和接收方式全部更新为kafka发送方式和接收方式。例如本地缓存定时刷新这种场景。


如果考虑多个实例之间部署的时间差,那么就比较麻烦了。


1-1


如果自产自消是1-1类型消息,即系统H发送一个Queue,消费者也是系统H,且需要考虑多个实例之间部署的时间差。这个切换过程比较简单。直接将AMQ的发送方式和接收方式全部更新为kafka发送方式和接收方式,整个滚动部署过程如下:


  • 上线前
    重构上线前,所有系统都有AMQ发送方式和AMQ接收方式。自产自消。

ba1166950fff7b3012502be6ee18fc5c57b710fa

  • 实例H1上线后
    实例H1上线后,实例H1是kafka发送方式和接收方式。如果消息是H1发送的,那么只能H1接收。如果消息是H2或者H3发送的,那么H2和H3都可以接收。

eae836452e94bd093da6327b242ccfe5983899ed

  • 实例H2上线后
    实例H2上线后,实例H1和H2是kafka发送方式和接收方式。如果消息是H1或者H2发送的,那么H1和H2都能接收。如果消息是H3发送的,那么H3可以接收。

    a0ce1aac77f0b13ed1b15b543d2aed311dba27ba

  • 实例H3上线后
    实例H3即最后一个上线后,三个实例全部是kafka的发送方式和接收方式。

    b688716086a65d4c2acafbf49c26a7373c10e40b


1-N


如果自产自消是1-N类型消息,即系统H发送一个Topic,消费者也是系统H,且需要考虑多个实例之间部署的时间差。这个切相对麻烦一点。

  1. 需要保留AMQ的接收方式,同时新增kafka接收方式,发布一个版本。

  2. 新增kafka发送方式,删除AMQ发送方式,滚动发布,直到所有实例部署完成。


总结


通过上面的方案设计,即使整个部门,或者整个公司相互之间通过MQ中间件依赖的系统有成百上千个,也可以做到从容不迫,一个系统一个系统慢慢迁移。完全不受其他项目组,不受其他部门的影响。整个过程真正做到平滑迁移。



原文发布时间为:2018-09-14
本文作者:阿飞Javaer
本文来自云栖社区合作伙伴“程序猿DD”,了解相关信息可以关注“程序猿DD”。

网友评论

登录后评论
0/500
评论
技术小能手
+ 关注
所属团队号: 程序员DD