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

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

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

依赖关系

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

系统依赖图

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

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具体用法网上一大堆，这里就不累述了）：

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_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发送方式和接收方式，整个滚动部署过程如下：

1. 上线前
   重构上限前，所有系统都有AMQ发送方式和AMQ接收方式。自产自消。

   
   image.png

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

   
   image.png

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

   
   image.png

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

   
   image.png

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

1. 需要保留AMQ的接收方式，同时新增kafka接收方式，发布一个版本。
2. 新增kafka发送方式，删除AMQ发送方式，滚动发布，直到所有实例部署完成。

总结

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