架构师方案-将自建 Kafka 集群迁移到云Kafka 集群方案

1. 背景

历史原因，公司部分系统使用基于ECS自建 kafka消息队列，造成运维成本浪费、项目稳定性差等问题。

1. 方案汇总

方案1 单写双消费

方案思路：

1. 完成Topic元数据的迁移。

2. 自建 Kafka 集群中原有的消费者保持不动。

3. 阿里云Kafka 消费端新起消费者，配置新的阿里云Kafka 集群的 bootstrap-server，消费新的阿里云Kafka 集群。

4. 等待所有消费端都已经监听了新的阿里云Kafka 集群。

5. 将自建集群的生产切到 阿里云Kafka 新集群上（配置新的阿里云Kafka集群的 bootstrap-server）。

6. 自建 Kafka 集群中原有的消费者继续消费自建 Kafka 集群中剩余的数据，直到消费干净后方可下线原消费者。

方案2：单写单消费

方案思路：

1. 完成Topic元数据的迁移。

2. 将自建 Kafka 集群的生产切到阿里云Kafka 新集群上 (配置新的阿里云Kafka 集群的 bootstrap-server)。

3. 等待自建集群中的消费者消费完剩余数据。

4. 将老的消费者切到阿里云Kafka 新集群消费（配置新的阿里云Kafka 集群的 bootstrap-server）。

方案3:Mirrormaker 迁移

方案思路：

1. 完成Topic元数据的迁移。

2. 自建 Kafka 集群中原有的消费者保持不动。

3. 启动 Mirrormaker 工具的数据同步功能。

4. 等待数据同步完成，修改消费者配置并切换消费者。

5. 等待数据同步完成，修改生产者配置并切换生产者。

6. 迁移完成，去掉 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