1. 首页
  2. kafka实践

5. ActiveMQ平滑迁移到kafka

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

既然是从AMQ(AtiveMQ的简称)迁移到kafka,那么迁移过程中肯定需要做到平滑迁移:对于业务没有影响,对于上下游系统没有依赖。

由于系统一般会和多个上游,多个下游通过MQ中间件保持依赖关系,迁移的过程中,肯定要做到各个系统上线没有任何依赖。打个比方订单系统发送topic,会员系统和积分系统都会接收这个topic(会员增加成长值,积分系统加积分)。改造后发布时,订单系统,会员系统,积分系统三个系统上线应该可以任意顺序,任意时间发布上线。

依赖关系

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

vemqpinghuaqianyidaokafka_1.png

系统依赖图

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

  1. 生产型(1-1)–这种消息由本身系统H发送,下游系统X,Y,Z中任意且只有一个系统消费(AMQ中Queue的使用场景);
  2. 生产型(1-N)–这种消息由本身系统H发送,下游系统X,Y,Z中任意多个系统消费(AMQ中VirtualTopic的使用场景);
  3. 消费型–这种消息由上游系统例如A或者B发送,系统H负责消费;
  4. 自产自消型–这种消息由本身系统H发送,本身系统H负责消费。

VirtualTopic

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

vemqpinghuaqianyidaokafka_2.png

Topic&VirtualTopic

如上图所示,系统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_ORDERVConsumers.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发送方式和接收方式,整个滚动部署过程如下:
  1. 上线前
    重构上限前,所有系统都有AMQ发送方式和AMQ接收方式。自产自消。

    vemqpinghuaqianyidaokafka_3.png

    image.png

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

    vemqpinghuaqianyidaokafka_4.png

    image.png

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

    vemqpinghuaqianyidaokafka_5.png

    image.png

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

    vemqpinghuaqianyidaokafka_6.png

    image.png

  • 1-N
    如果自产自消是1-N类型消息,即系统H发送一个Topic,消费者也是系统H,且需要考虑多个实例之间部署的时间差。这个切相对麻烦一点。
  1. 需要保留AMQ的接收方式,同时新增kafka接收方式,发布一个版本。
  2. 新增kafka发送方式,删除AMQ发送方式,滚动发布,直到所有实例部署完成。

总结

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

作者:阿飞的博客

来源:https://www.jianshu.com/p/1c50bf048724


JS中文网,Javascriptc中文网是中国领先的新一代开发者社区和专业的技术媒体,一个帮助开发者成长的社区,是给开发者用的 Hacker News,技术文章由为你筛选出最优质的干货,其中包括:Android、iOS、前端、后端等方面的内容。目前已经覆盖和服务了超过 300 万开发者,你每天都可以在这里找到技术世界的头条内容。

本文著作权归作者所有,如若转载,请注明出处

转载请注明:文章转载自「 Java极客技术学习 」https://www.javajike.com

标题:5. ActiveMQ平滑迁移到kafka

链接:https://www.javajike.com/article/1789.html

« 6. kafka拦截器
4. kafka生产者&消费者»

相关推荐

QR code