用途
本技能用于在事件驱动系统中，让 schema 管理变得显式且可强制执行。它帮助智能体协调生产者变更、消费者兼容性、注册表策略，以及跨团队共享事件流的版本化契约。
适用场景
- 为事件驱动系统采用 schema registry
- 定义或修改 Avro、Protobuf 或 JSON Schema 定义
- 为主题或 subject 设置兼容性策略
- 协调生产者 schema 变更对多个消费者的影响
- 为多团队事件生态强制契约治理
不适用场景：schema 完全通过应用代码管理且没有共享注册表；或系统只有单一生产者-消费者对且没有演进顾虑。
工作流程
1. 定义 schema 归属与 subject 命名
需要包含：
- 每个 schema subject 的归属方（团队、服务、领域）
- subject 命名策略：TopicNameStrategy、RecordNameStrategy 或 TopicRecordNameStrategy
- schema 存储位置：Confluent Schema Registry、AWS Glue Schema Registry、Apicurio 或同类产品
- schema 事实来源：registry-first，或 code-first 配合 CI 同步
2. 有意识地选择 schema 格式
- Avro：生态支持强、二进制紧凑，反序列化需要注册表
- Protobuf：适合多语言团队，支持嵌套消息与服务
- JSON Schema：人类可读、类型约束较松、更易采用但保证较弱
需考虑：序列化体积、语言支持、工具成熟度、团队熟悉度。除非隔离绝对彻底，否则不要在单一领域内混用格式。
3. 定义并强制兼容性策略
- BACKWARD：新 schema 可读取旧数据（适合消费者优先演进）
- FORWARD：旧 schema 可读取新数据（适合生产者优先演进）
- FULL：双向兼容（最安全、限制最多）
- NONE：不做兼容性检查（仅用于开发或隔离主题）
按 subject 设置策略，而非全局设置——不同主题的演进需求不同。在发布 schema 变更前于 CI 中测试兼容性。
4. 规划生产者与消费者演进路径
- 增量变更（新增可选字段）：在向后兼容下安全
- 字段删除或重命名：在多数策略下为破坏性变更，需要迁移
- 类型变更：通常为破坏性变更，优先新增字段而非修改类型
- 记录升级顺序：哪一侧先部署（生产者还是消费者）
- 显式使用默认值以支持向后读取
5. 将 schema 校验集成到发布流程
- 在 CI 中使用注册表 API 或 CLI 工具校验 schema 兼容性
- 阻断违反兼容性策略的发布
- schema 与服务工作代码一同版本化，而非独立版本化
- 为发布门禁产出兼容性检查证据
- 定义回滚计划：旧 schema 版本能否安全重新注册
6. 处理多团队治理与 schema 发现
- 在事件目录或数据目录旁发布 schema 文档
- 让消费者依赖可见——谁读取哪些 schema 版本
- 为旧 schema 版本定义弃用流程
- 将 schema registry 可用性作为关键路径依赖进行规划
常见合理化借口与事实
- “只是加字段，可以自由演进 schema。”——即使增量变更，如果缺少默认值或字段语义在未通知的情况下改变，也可能破坏消费者。
- “注册表只是用于序列化，不是治理。”——注册表是跨团队契约的执行点。把它当作工具会忽视其治理价值。
- “JSON Schema 更简单，所以到处都用它。”——JSON Schema 提供的保证较弱，也没有二进制效率。格式选择应匹配系统的持久性、性能和类型需求。
- “开发期间兼容性可以设为 NONE，之后再收紧。”——团队很少事后收紧兼容性。尽早设置策略可防止破坏性变更累积。
危险信号
- 生产 subject 未定义兼容性策略
- schema 未经 CI 校验直接在注册表中修改
- 生产者与消费者同时部署且没有协调顺序
- 没有文档记录哪些消费者依赖哪些 schema 版本
- schema registry 是单点故障且没有可用性计划
- 字段语义变化却没有版本升级或消费者通知
- 已弃用的 schema 版本从未清理或记录
- 选择格式时未考虑跨语言或性能需求
验证清单
- schema 归属与 subject 命名策略已记录
- 格式选择（Avro、Protobuf、JSON Schema）已针对用例给出理由
- 兼容性策略按 subject 设置并在 CI 中测试
- 针对破坏性变更已定义生产者与消费者演进顺序
- schema 校验是发布流程的一部分，并在不兼容时阻断
- 消费者对 schema 版本的依赖可见且被跟踪
- schema registry 可用性与回滚流程已规划