1. 背景
历史原因，公司部分系统使用基于ECS自建 kafka消息队列，造成运维成本浪费、项目稳定性差等问题。
1. 方案汇总
方案1 单写双消费
方案思路：
完成Topic元数据的迁移。
自建 Kafka 集群中原有的消费者保持不动。
阿里云Kafka 消费端新起消费者，配置新的阿里云Kafka 集群的 bootstrap-server，消费新的阿里云Kafka 集群。
等待所有消费端都已经监听了新的阿里云Kafka 集群。
将自建集群的生产切到 阿里云Kafka 新集群上（配置新的阿里云Kafka集群的 bootstrap-server）。
自建 Kafka 集群中原有的消费者继续消费自建 Kafka 集群中剩余的数据，直到消费干净后方可下线原消费者。
方案2：单写单消费
方案思路：
完成Topic元数据的迁移。
将自建 Kafka 集群的生产切到阿里云Kafka 新集群上 (配置新的阿里云Kafka 集群的 bootstrap-server)。
等待自建集群中的消费者消费完剩余数据。
将老的消费者切到阿里云Kafka 新集群消费（配置新的阿里云Kafka 集群的 bootstrap-server）。
方案3:Mirrormaker 迁移
方案思路：
完成Topic元数据的迁移。
自建 Kafka 集群中原有的消费者保持不动。
启动 Mirrormaker 工具的数据同步功能。
等待数据同步完成，修改消费者配置并切换消费者。
等待数据同步完成，修改生产者配置并切换生产者。
迁移完成，去掉 Mirrormaker 工具。
方案4:停机
略
2. 方案对比
| 方案 | 是否平滑迁移 | 代码开发 | 是否要再次发布 |
|---|---|---|---|
| 1.单写双消费 | 是 | 除了KafKa迁移代码改造点，需要再一起套消费者，但是这个成本并不大 | 短期不需要 |
| 2.单写单消费 | 是 | KafKa迁移代码改造点(由于原有Topic和阿里云Topic映射的原因，在切换消费者时可能在代码中，要修改topic名） | 旧消费切到 阿里云Kafka集群之前， 阿里云Kafka集群会存在一定量的堆积（我们业务量并不大，堆积并不会太多）；因此需要即时观察旧消费者消费完，然后再次发布。 |
| 3.Mirrormaker 迁移 | 是 | 除了KafKa迁移代码改造点，Mirrormaker 工具开发熟悉使用新消费者从头开始消费，要保证所有消息幂等 | 短期需要 |
| 4.停机，等旧消费者消费完，然后切换新的生产者和消费者 | 否，且需要屏蔽所有操作入口 | KafKa迁移代码改造点 | 不需要 |
3. 参考资料
https://cloud.tencent.com/document/product/597/60528
https://www.alibabacloud.com/help/zh/message-queue-for-apache-kafka/latest/best-practices
