记一次线上服务迁移方案调研

 

前言

    对于任何一个模块或服务或框架来说都需要具备可升级性。升级背后的诉求可能是多种：

•    版本的升级，寻求更安全的代码或者享用更强大的功能。

•    当前服务已经不能承担目前的用户量，急需要横向扩容升级。

•    其他外界因素引发的升级需求，如机房迁移等。

 

正文

    本文要讲的Kafka架构的升级，原因是上述讲的第二种。

    在kafka横向扩容中，首先调研了kafka本身架构具备的横向扩容能力。即将新broker加入到新的集群即可，新broker配置上集群的zookeeper即可加入。本以为这是个很简单的操作，但是并不是适用所有的业务场景。

    我所碰到的是一个平台的业务，kafka集群中有270+个topic，数据量大概在30T，更新峰值在1wqps。如果适用横向迁移操作，加入了新的节点后，这270+的topic将面临着分区迁移过程，注意，这是一个线上的操作过程。为了验证操作的可行性，我做了如下实验：

1:准备文件2: 生成默认迁移计划 ./bin/kafka-reassign-partitions.sh --zookeeper localhost:2149 --topics-to-move-json-file ./my_topics-to-move.json --broker-list "0,1,2,3,4" --generate其中：broker-list 指定需要迁移的目标brokertopics-to-move-