Apache Kafka 模式提取器

解决什么问题

在 Kafka 生态里，生产者和消费者很容易写出「各自硬编码字段」的代码：同一条订单消息，上游用 UserId，下游还在读 userId，等测试环境才发现字段对不上。Schema Registry 里躺着 Avro、Protobuf、JSON Schema 三种定义，但它们不会自动变成代码里的类型——要么手工维护一份模型，要么让转换脚本在每次 schema 变更时悄悄过期。这个技能要解决的就是从 Registry 的定义到工程可用的类型模型之间那一段重复劳动。

它如何工作

核心能力是围绕 Schema Registry 的 REST API 展开的：

• 拉取指定 subject 的 schema 定义，支持 Avro、Protobuf、JSON Schema 三种格式；
• 把定义转换为可用的类型化数据模型，而不是只吐出原始字符串；
• 调用兼容性检查能力，在 schema 演进（新增字段、修改默认值等）时判断新定义与已有数据是否兼容。

典型的使用路径是：先指定 Registry 地址和 subject，技能通过 API 取回 schema；接着完成格式解析与模型转换，产出可直接落到工程里的类型描述；最后在写入或发布前跑一次兼容性校验，把「改了 schema 但忘了确认下游」的风险拦在上线前。

适用边界

• 它只负责提取、转换与兼容性校验，不替代 schema 注册流程本身——写入 Registry 仍需走你们既有的发布通道。
• 兼容性结论以 Schema Registry 配置的兼容性模式为准（如 BACKWARD、FULL），不同模式的判定结果不同，需要结合团队约定解读。
• 多环境（dev/staging/prod）通常对应多个 Registry 实例或 context，跨环境拉取时注意 subject 命名空间不要混用。
• 如果仓库地址不可达或 subject 不存在，技能会直接失败——这也是期望行为，静默降级反而会掩盖配置漂移。