3. Kafka主题与Schema的版本化建模
在 Kafka DataOps 的持续交付体系里，Topic 与 Schema 是两类最核心的“契约资产”。Topic 决定数据在物理层如何分布与冗余，Schema 决定数据在语义层如何被生产者和消费者理解。二者都必须像代码一样被版本化、评审、发布与回滚，否则一次随意的分区调整或字段删除，就可能在数小时内击穿下游数十个作业。
一、Topic 命名规范：把语义写进名字
Topic 名称是跨团队协作的第一接口。推荐采用“域.实体.版本.用途”的分层命名，例如 pay.order.v1.event、pay.order.v1.cdc。其中“域”对应业务边界（pay、risk、logistics），“实体”对应聚合根（order、payment），“版本”用 v1/v2 显式标注语义大版本，“用途”区分 event（业务事件）、cdc（变更捕获）、dlq（死信）、retry（重试）等。这样命名带来三个直接收益：一是权限与配额可按前缀批量授予；二是监控告警可按域聚合；三是消费者一眼能判断该 Topic 是否允许跨域订阅。
需要避免的反模式包括：用日期或环境后缀（order_20240101、order_test）污染语义；用下划线和大写混排导致跨语言客户端不一致；把分区数写进名字（order_12p），因为分区数属于可调参数而非身份标识。环境隔离应通过集群或命名空间实现，而不是靠 Topic 名后缀。
二、分区与副本策略：容量、顺序与可用性的三角
分区数决定 Topic 的最大并行度。经验公式是：分区数 ≈ 目标吞吐 / 单分区吞吐，同时保证分区数 ≥ 消费者组最大并行实例数。例如目标峰值 120 MB/s，单分区实测可稳定承载 10 MB/s，则至少 12 个分区；若消费者组计划部署 20 个实例，则应取 20 或 24（便于均匀分配）。分区只能增加不能减少，因此初期宁可略多，但也不宜盲目上千，否则会放大 Controller 元数据压力与再平衡时间。
副本策略围绕 replication.factor 与 min.insync.replicas 展开。生产环境通常 RF=3，min.insync.replicas=2，配合生产者 acks=all，可在容忍单节点故障的同时避免脑裂写入。机架感知通过 broker.rack 让副本分散到不同可用区。关键业务 Topic 还应设置 unclean.leader.election.enable=false，牺牲可用性换取一致性。
三、Schema 演进规则：三种格式的兼容性边界
Schema Registry 的核心价值在于：在生产者写入前校验 Schema 是否兼容，把破坏性变更拦截在发布阶段，而不是等消费者崩溃后才发现。三种主流格式的演进规则差异显著。
Avro 依赖读写 Schema 的字段名匹配与默认值。允许的向后兼容变更包括：新增带默认值的字段、删除无默认值的字段（对旧消费者而言）。不允许的变更包括：修改字段类型（int→long 在 Avro 中可通过提升规则部分允许，但 string→int 绝对禁止）、重命名字段（除非使用 alias）、删除带默认值的字段（会破坏旧消费者）。
Protobuf 以字段编号为身份标识，字段名可自由修改。安全变更包括：新增字段、删除字段（保留编号）、修改字段名。危险操作是复用已删除的字段编号，这会导致新旧数据解析错乱。因此删除字段时必须使用 reserved 标记编号。
JSON Schema 的兼容性判断最复杂，取决于 additionalProperties 与 required 的组合。新增可选属性通常向后兼容；把可选属性改为必填则破坏向后兼容；删除属性对使用 additionalProperties: false 的消费者是破坏性的。
四、兼容性级别与版本管理实践
Schema Registry 提供五种兼容性级别：BACKWARD（默认，新 Schema 可读旧数据）、FORWARD（旧 Schema 可读新数据）、FULL（双向）、NONE（不校验）、以及带传递性的 BACKWARD_TRANSITIVE / FORWARD_TRANSITIVE / FULL_TRANSITIVE。选择原则是：消费者先升级用 FORWARD，生产者先升级用 BACKWARD，无法协调升级顺序时用 FULL，但 FULL 会显著限制演进空间。
版本管理应遵循“Schema 先行”的发布顺序：先注册新版本 Schema 并确认兼容性通过，再发布生产者，最后升级消费者。回滚时不能简单回退 Schema 版本，因为 Registry 中已注册的版本不可删除（只能软删除），正确做法是发布一个与旧版本兼容的新版本。建议为每个 Topic 维护 subject 命名策略，默认 TopicNameStrategy 适合一 Topic 一 Schema；若同一 Topic 承载多种事件类型，应改用 RecordNameStrategy 或 TopicRecordNameStrategy。
curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" --data @schema.json http://registry:8081/compatibility/subjects/pay.order.v1-value/versions/latest 作为门禁，兼容性检查不通过则阻断合并。同时把 Schema 文件纳入 Git 仓库，与 Topic 创建脚本（如 Terraform 的 confluent_kafka_topic 资源）放在同一目录，实现基础设施与契约的同版本发布。
最后需要强调：Topic 参数与 Schema 版本不是一次性设计，而是持续演进的资产。每次变更都应记录变更原因、影响范围、兼容性结论与回滚方案，让 DataOps 的每一次发布都可追溯、可验证、可恢复。