📚 课程目录第2章现状评估与迁移就绪度分析

2. 现状评估与迁移就绪度分析

迁移到 Confluent Kafka 之前，最忌讳的动作就是“先动手、后盘点”。现状评估的目标不是写一份漂亮的报告，而是回答三个具体问题：现有集群里到底有什么、哪些东西会阻碍迁移、迁移后哪些行为可能发生变化。只有把这三件事量化，才能给出可信的就绪度结论，并据此决定迁移批次、停机窗口和回滚策略。

盘点对象与采集方式

盘点应覆盖六个维度：集群与版本、规模与容量、客户端、Topic、ACL 与安全、连接器与上下游系统。采集方式优先使用只读命令与元数据接口，避免对生产集群造成额外压力。

# 集群与 Broker 版本
kafka-broker-api-versions.sh --bootstrap-server broker1:9092 | head -20

# Topic 清单与分区/副本
kafka-topics.sh --bootstrap-server broker1:9092 --describe

# 消费组与滞后
kafka-consumer-groups.sh --bootstrap-server broker1:9092 --all-groups --describe

# ACL 清单
kafka-acls.sh --bootstrap-server broker1:9092 --list

# 连接器状态（如使用 Kafka Connect）
curl -s http://connect1:8083/connectors?expand=status | jq .

这些命令输出的是原始数据，需要整理成可比较的表格。例如 Topic 盘点至少记录：名称、分区数、副本因子、保留时长、清理策略、平均消息大小、日增量和峰值吞吐。客户端盘点要记录：客户端类型（Java/Go/Python/librdkafka）、版本号、是否使用旧版消费者协议、是否依赖 ZooKeeper 直连、是否使用已废弃的 API。

就绪度评估的核心维度

就绪度不是单一分数，而是多个维度的加权判断。建议从以下维度评估，并给出“就绪 / 有条件就绪 / 不就绪”三档结论：

版本兼容性：源集群版本与目标 Confluent Platform 版本的协议兼容性。若源版本低于 0.10.2，客户端协议差异较大，需要重点验证。
客户端兼容性：是否存在依赖 ZooKeeper 的旧客户端、使用旧版 Offset 存储（ZooKeeper 而非 __consumer_offsets）的消费者。
Topic 与分区规模：分区总数、单集群 Topic 数、副本因子是否超过目标集群推荐上限。
安全与 ACL：ACL 数量、是否使用 SASL/PLAIN、是否依赖旧版授权器、是否启用 SSL 双向认证。
连接器与上下游：Connect 插件类型、是否使用自研连接器、上下游系统的 SLA 与接口稳定性。
运维与监控：现有监控指标、告警规则、是否依赖 JMX 自定义指标。

就绪度评估报告应给出每个维度的证据来源和判断依据，而不是只给结论。例如“客户端兼容性：有条件就绪，因为存在 3 个使用 0.9 版消费者的应用，需在迁移前升级到 2.x 客户端”。

迁移就绪度评估报告的结构

一份可执行的报告通常包含以下部分：现状摘要、风险清单、迁移批次建议、验证计划、回滚方案。其中风险清单要按“影响面 × 发生概率”排序，迁移批次建议要说明每个批次的 Topic 范围、客户端范围和停机窗口。

维度	示例发现	就绪度	关键动作
版本	源集群 0.10.1，目标 CP 7.x	有条件就绪	升级客户端协议，验证消息格式
客户端	2 个应用使用旧版消费者	不就绪	迁移前升级到 2.8+ 客户端
Topic	1200 个 Topic，分区总数 8000	就绪	按业务域分批迁移
ACL	450 条 ACL，使用 SASL/PLAIN	有条件就绪	映射到 Confluent RBAC 或保留 ACL
连接器	3 个自研 Sink 连接器	不就绪	评估重写或使用 Confluent 托管连接器

从盘点数据到迁移决策

盘点完成后，需要把数据转化为决策。一个实用的做法是建立“迁移单元”概念：把相互依赖的 Topic、消费组、连接器和上下游系统打包成一个迁移单元，按单元评估风险和排期。例如订单域包含 12 个 Topic、3 个消费组、1 个 MySQL Sink 连接器，作为一个迁移单元整体切换，避免跨单元的部分迁移导致数据不一致。

对于每个迁移单元，要明确：切换方式（双写、镜像、停机切换）、数据校验方式（消息数、Offset、业务对账）、回滚触发条件（延迟超过阈值、错误率超过阈值）。这些内容应写入就绪度报告，作为后续迁移执行的依据。

常见风险与判断依据

在评估过程中，有几类风险出现频率最高，需要重点标注。第一类是旧版消费者依赖 ZooKeeper 存储 Offset，迁移后必须改为 __consumer_offsets，否则消费位点会丢失。判断依据是检查消费者配置中 offsets.storage 是否为 zookeeper。第二类是 Topic 分区数过多导致迁移后元数据管理压力增大，一般建议单集群分区总数控制在 20 万以内，超过时需要合并或拆分。第三类是 ACL 数量庞大且使用旧版授权器，迁移到 Confluent 后需要重新映射到 RBAC 或保留 ACL 模式，判断依据是 authorizer.class.name 的配置值。

就绪度评估报告不是一次性文档。在迁移执行前，应至少更新一次，确认整改项已完成、风险等级已下降。若整改项未完成，应调整迁移批次或推迟迁移。

最后，就绪度评估的结论要落到可执行的迁移计划上。建议输出一张迁移单元清单，每个单元包含：单元名称、Topic 列表、消费组列表、连接器、上下游系统、就绪度、整改项、目标批次、切换方式、回滚条件。这张清单既是评估报告的附件，也是后续迁移执行的检查表。