Kafka 迁移上云（方案一）

本文介绍通过方案一将开源 Kafka 集群迁移到火山引擎消息队列 Kafka版的操作步骤。

注意事项

• 业务迁移只迁移消息生产、消费链路和业务流量，并不会迁移 Kafka 旧集群上的消息数据。
• 创建Kafka实例、迁移消息收发链路之前，请先确定 Kafka 实例可正常访问，以免因访问异常造成迁移失败。您可以访问 Kafka 实例详情页中的接入点，确认实例的网络连通性。
• 业务迁移之前，请确认您已根据业务需求选择了正确的迁移方案。迁移方案对比请参考概述。
  

1 环境准备

迁移之前，您需要根据业务量合理评估资源需求，并创建 Kafka 实例及相关的依赖资源。

1.1 迁移评估

根据现有业务量和消息量估算所需的消息队列 Kafka版资源，例如业务读写流量峰值、磁盘容量和分区数等。不同规格的 Kafka 实例代表不同的计算能力及存储空间，请根据业务量合理评估资源需求。

1.2 准备相关资源

确认资源需求之后，还需要准备相关资源，例如私有网络和子网、ECS 云服务器和 Kafka 实例。

1. 搭建环境。
   您需要创建私有网络和子网、购买 ECS 云服务器。迁移后您的服务需要和 Kafka 实例处于相同的区域（Region）和 VPC 内，才能正常访问实例。详细说明请参考 准备环境 。
2. 购买 Kafka 实例。
   请根据业务量评估结果合理选择 Kafka 实例的计算规格和存储规格，保证资源充足。 详细操作步骤请参考 创建 Kafka 实例 。
   

2 迁移元数据

迁移元数据的步骤主要是在新的 Kafka 实例中创建与原 Kafka 集群相同的 Topic 和 Group 配置，包括 Topic 名称、分区数、副本数、消息保留时长等参数配置等。关于 Group 配置迁移，您可以根据需求选择在控制台创建 Group 或在使用 SDK 的过程中按需创建 Group。

1. 在原 Kafka 集群中收集 Topic 和 Group 的基本信息。
   其中，核心配置如下：

   配置	说明
   Topic 名称	Topic 的名称。
   Topic 分区数	此 Topic 的分区数量。分区数量越大，消费的并发度越大。
   分区副本数	分区的副本个数，用于保障分区的高可用。当其中一个 Broker 故障时仍可保障数据可用性，副本数越大可靠性越高。
   Group ID	Group 的 ID，即生产和消费时指定的消费组 Group ID。

2. 在火山引擎消息队列 Kafka版控制台中创建同样数量和配置的 Topic。
   您可以根据业务需要选择手动创建 Topic 或通过配置文件批量创建 Topic。操作步骤请参考 创建 Topic 或 批量导入 Topic 。

   说明

   Topic 名称和分区数等核心配置需要和原 Kafka 集群的 Topic 配置相同，消息保留时长等参数可以根据业务需求自行配置。

3. 创建同样数量和配置的 Group。
   消息队列 Kafka版通过自由使用 Group 功能控制 Kafka 实例支持的 Group 创建方式，该功能默认为开启状态。您可以根据需求选择是否开启自由使用 Group 功能，并且创建和迁移源端同样数量和 ID 的 Group。

   • 开启时，不仅可通过控制台创建 Group，还可以通过消费 SDK 解析获取并展示 Group 的信息。使用 SDK 时按需创建 Group 的方式请参考通过 SDK 设置 Group。
   • 关闭后，只能通过控制台创建 Group。通过控制台创建 Group 的操作步骤请参考通过控制台创建 Group。
     

3 迁移消息服务

业务迁移的方案一先启动新的消费端和生产端，让新集群的生产和消费正常运行。再下线旧的生产端，待旧集群的消息被旧 Consumer 消费完成后，再关闭旧消费端，完成迁移上云。该方案可以保障业务的可用性，业务迁移更加平滑，适用于对业务连续性和可用性要求较高的业务场景。但是该方案中，云上和云下双集群同步处理消息消费，无法保证消费的有序性。
迁移步骤如下：

1. 启动新的消费者和生产者。
   为新建的消息队列 Kafka版实例开启新的消费者和生产者，在云端搭建新的消息生产和消费流程，并启动消息的生产与消费。
   如果 Kafka 实例开启了公网访问，您可以直接修改生产端和消费端代码中的接入点，由自建集群接入点改为消息队列 Kafka版的公网接入点。
2. 检验新的 Kafka 实例业务是否正常运行。
   您可以根据业务自身的运行逻辑判断当前服务的健康度，确认火山引擎 Kafka 实例是否正常运行，也可以参考 查看迁移进度和结果 根据云监控数据判断实例的生产和消费是否正常。
   确认实例正常运行后，继续执行旧集群的下线操作。
3. 下线自建 Kafka 集群的生产者，但维持旧的消费者。
   此时旧消费者仍在持续消费存量的旧消息，即同时有两个消费端在同时消费不同的消息。 先停止生产业务可以避免生产流量不断写入，导致消费业务一直在处理源源不断的新数据，而持续无法停止消费。
4. 在旧 Kafka 集群的消息全部被旧消费者消费后，下线旧消费者以及旧 Kafka 集群。
   待停止生产业务后，可以参考 查看迁移进度和结果 ，观察消费组的处理进度，待消费组处理完成后，下线旧消费者以及旧 Kafka 集群。
   成功下线自建 Kafka 集群之后，表示您已完成开源 Kafka 迁移上云。