概述
在这篇文章中，我将回顾一下在我工作过程中遇到过的一个关于迁移 Kafka 的事故，虽然问题的本质是操作过程中缺乏严谨造成的，但是这个迁移过程还是有一些可以学习的地方的。所以在闲暇之余趁着我还记得一些细节，就记录一下事情的来龙去脉，以及问题出现的原因。
问题描述
这个问题是出现在我们部署新的服务的时候，当我们灰度发布的时候发现对应的服务异常了，实际上这次发版我们并没有做任何业务相关的变更，只是升级了一下 Go 的版本，所以怀疑是新版本的 Go 有问题，于是决定回滚部署，但是情况并没有变好，回滚依旧解决不了问题，故障没有得到缓解。
定位过程
所以我们就只能先顶着压力定位一下问题了，这里的定位过程并没有很复杂，第一步直接查看异常日志，发现日志中报错是连接 Kafka 异常，然后马上就想到了最近我们做过 Kafka 的迁移，但是这里应用使用的还是旧的 Kafka 地址，于是，我们马上更新应用的配置，将 IP 列表更换为 DNS 记录，并且重新部署服务，重新部署后问题被解决，然后异常恢复了。
问题原因
Kafka 迁移过程
因为最近我们准备迁移一个机房，在这个机房中，我们有一个 Kafka 服务，所以我们需要将这个服务迁移到其他的机房，迁移的方法有很多，我们选择了一种不需要重启的无痛迁移方式：
- 创建新的 Kafka 集群（3 节点），然后加入到旧的集群（3 节点）中，此时，客户端应该感知到集群的变动，获取到最新的集群列表（6 节点）；
- 让新集群的节点都承担了旧集群的的副本集，此时新旧集群同时提供服务；
- 然后我们逐渐下线旧集群的节点，此时，客户端也会感知到集群的变动，从而减少集群的列表；
- 最终下线所有的旧集群节点，然后迁移完成。
问题出就出在第 4 步，虽然在当前应用中我们已经完成了 Kafka 集群的迁移，但是，我们忘记了修改应用的 Kafka 地址的配置，它们依旧使用的是旧集群的地址，这样，就导致了当我们重新部署或者重启服务的时候，依旧使用的是旧 Kafka 集群的地址，从而导致故障。
访问 Kafka 的方式
其实，这里还有一个不妥之处就是我们通过集群 IP 列表来配置 Kafka 的 Broker 地址，所以每次变动都需要手动地更改应用的配置，在这一次，我们直接将配置修改为 DNS 的方式，这样，我们可以配合公司内部的 Kafka 集群管理功能，当有集群变动的时候，它们会自动地更新 DNS 的记录，从而我们无需任何操作即可适应 Kafka 集群的变化。
总结
在这篇文章中，我回顾了一下工作中遇到过的一个和 Kafka 相关的故障，其实这个问题没有很复杂，甚至有点粗心，但是，在这个过程中，关于迁移 Kafka 的经验以及对应用的配置管理还是有一些借鉴意义的，所以就顺带记录一下。