Schema Registry 是什么
Schema Registry 集中管理消息与事件的模式版本，生产者在发布前注册模式，注册中心按配置的兼容策略做校验，消费者按版本解析数据。它解决的是「谁改了什么、改了之后还能不能读」的问题：没有统一登记时，字段增删只在代码里体现，消费方往往在反序列化失败时才察觉。兼容策略决定允许的演进方式——向后兼容允许新增可选字段、向前兼容允许删除可选字段、全兼容要求双向都不出错。
基本信息
| 职责 | 集中存储模式版本、分配版本号、校验兼容性 |
|---|---|
| 注册时机 | 生产者发布前注册；不通过校验则不允许上线 |
| 兼容策略 | 向后、向前、全兼容与自定义策略 |
| 消费者侧 | 按模式 ID 解析消息，可拉取对应版本的模式 |
| 治理要求 | 兼容检查进流水线，而不是上线后事后补检 |
典型使用场景
- 事件驱动集成：多个服务订阅同一主题，模式变更需保证所有消费方不受影响
- 流式管道：Kafka 等平台上的消息载荷统一注册与版本管理
- 跨团队数据交换：以模式为契约，明确字段含义与必填性
- 数据入湖：落库前校验模式，避免脏数据进入分析层
- 灰度升级：生产方与消费方升级节奏不一致时，用兼容策略过渡
- 审计与追溯：查询某个时间点使用的模式版本，还原历史数据含义
兼容策略
| 策略 | 含义 | 允许的演进 |
|---|---|---|
| 向后兼容 | 新 schema 可读旧数据 | 新增可选字段；消费者先升级 |
| 向前兼容 | 旧 schema 可读新数据 | 删除可选字段；生产者先升级 |
| 全兼容 | 双向兼容 | 仅正交增删可选字段，限制最严 |
| 无兼容校验 | 不做校验 | 任意改动均可，风险由消费方承担 |
演进落地要点
演进落地要点
# 1 先确认消费方升级节奏：谁先升级决定选向后还是向前兼容
# 2 新增字段必须可选并带默认值：旧数据读取时有确定行为
# 3 删除字段分两步：先停用（标记废弃）并观察，确认无人使用后再移除
# 4 禁止复用字段编号与重命名后改语义，历史上已有数据会错读
# 5 兼容校验放流水线：不通过则阻断发布，不依赖人工评审提醒
# 6 版本登记与代码提交关联：出问题时能快速定位是哪个版本引入的模式演进要先确认各方升级节奏：生产方与消费方谁的发布更慢，决定选用向后、向前还是全兼容策略，策略选错等于把兼容性交给运气。
把必填字段加入既有事件是最常见的破坏性改动：旧生产者不会发送该字段，消费方立即失配；应改为可选字段加默认值。