技能介绍

这个技能解决什么问题

在 Kafka 生产环境里，schema 不兼容很少在写入那一刻暴露。它往往出现在消费者升级时，或者某个团队想改一个字段时。一次不兼容的 Avro schema 变更可能让老消费者反序列化直接失败，而且问题通常要等到消息被消费才被发现。靠人工 review 和经验做兼容性检查成本高，也容易漏掉边界情况。这个技能把判断交给 Confluent Schema Registry 的 REST API，在推送 schema 之前就能确认这次变更会不会破坏已有消费者。

它如何工作

核心流程分为三步：

提交候选 schema：把准备发布的 schema 版本发给 Schema Registry，请求做兼容性检查；
指定兼容模式：在 backward（新消费者能读旧数据）、forward（旧消费者能读新数据）、full（同时满足两者）之间选择本次要强制的模式；
解析检查结果：根据 REST API 的返回值决定是否放行，并对报出的 breaking change 定位到具体字段。

它覆盖 Avro、Protobuf 和 JSON Schema 三类 schema，模式判断全部由 Registry 服务端的规则完成。

适用边界与注意点

运行环境需要能访问 Schema Registry 的 REST endpoint，检查结果完全由服务端策略决定，本地规则无法替代；
兼容模式需要在请求中显式声明，或由 Registry 的配置决定；不声明就按默认策略处理；
技能基于 KafkaJS，一个 Node.js 的现代 Kafka 客户端，兼容 Kafka 0.10+ 并原生支持 0.11 特性，因此运行环境是 Node.js；
它只回答"这次 schema 变更是否兼容"，不负责生成迁移方案，也不校验消息内容本身；
只能检测 Schema Registry 认知到的变更，Registry 中未注册的 schema 无法纳入比较。