4. Schema Registry 核心概念：注册表、兼容性策略、版本号、全局与主题级配置
在 Kafka 生态中，Schema Registry 是契约管理的核心组件。它负责存储、检索和演化 Avro、Protobuf 或 JSON Schema 定义，确保生产者和消费者之间的数据格式始终兼容。理解注册表、兼容性策略、版本号以及配置作用域，是实施契约校验的基础。
4.1 Schema Registry 注册表结构
注册表本质上是一个集中式 Schema 存储库，以 主题（Subject） 为逻辑单元组织 Schema。每个 Subject 对应一个 Kafka 主题（Topic）或一组消息类型，并维护该主题下所有 Schema 版本的线性历史。
核心实体：
- Subject：Schema 的逻辑分组，通常命名为
<topic-name>-value或<topic-name>-key。 - Schema：具体的序列化定义（Avro .avsc、Protobuf .proto、JSON Schema）。
- Version：每个 Schema 在 Subject 内的整数版本号，从 1 开始递增。
- Compatibility：控制 Schema 演化规则的策略。
4.2 兼容性策略详解
兼容性策略定义了 Schema 演化时，新版本与旧版本之间的契约约束。Schema Registry 内置 5 种策略，每种策略对生产者和消费者的影响不同。
| 策略名称 | 含义 | 生产者约束 | 消费者约束 | 典型场景 |
|---|---|---|---|---|
| NONE | 不检查兼容性 | 可任意修改 Schema | 必须与生产者版本完全一致 | 开发调试、一次性数据 |
| BACKWARD | 新 Schema 可以读取旧数据 | 只能添加可选字段，不能删除/修改必填字段 | 使用新 Schema 的消费者可以处理旧数据 | 消费者先升级的场景 |
| FORWARD | 旧 Schema 可以读取新数据 | 只能删除字段或添加默认值 | 使用旧 Schema 的消费者可以处理新数据 | 生产者先升级的场景 |
| FULL | 同时满足 BACKWARD 和 FORWARD | 只能添加/删除可选字段 | 新旧 Schema 双向兼容 | 长期演化的核心契约 |
| FULL_TRANSITIVE | 传递性 FULL 兼容 | 新 Schema 必须与所有历史版本兼容 | 所有历史版本均可互读 | 严格契约、审计合规 |
实践建议：生产环境推荐使用 BACKWARD 或 FULL 策略。BACKWARD 允许消费者先升级，减少线上风险；FULL 提供双向保障，适合核心业务主题。
4.3 版本号机制
每个 Subject 下的 Schema 版本号是一个从 1 开始的单调递增整数。版本号由 Schema Registry 自动分配，不可手动修改。版本号与 Schema 内容构成一一映射：相同内容的 Schema 提交到同一 Subject 时，返回已有版本号，不会创建新版本。
版本号生命周期：
- 注册：首次提交 Schema，版本号 = 1。
- 演化：提交兼容的新 Schema，版本号 +1。
- 查询：通过
GET /subjects/{subject}/versions/{version}获取指定版本。 - 最新：
GET /subjects/{subject}/versions/latest获取当前最新版本。 - 软删除：版本可被标记为删除，但版本号不会复用。
4.4 全局与主题级配置
Schema Registry 支持两级配置作用域：全局（Global） 和 主题级（Subject-level）。全局配置作为默认值，主题级配置可以覆盖全局配置，实现细粒度控制。
| 配置层级 | 作用范围 | 配置项 | 优先级 |
|---|---|---|---|
| 全局 | 所有 Subject | compatibility.level（默认 BACKWARD） |
最低（默认值） |
| 主题级 | 单个 Subject | compatibility.level（可独立设置） |
最高（覆盖全局） |
配置优先级规则：
- 如果 Subject 未设置兼容性策略，则继承全局配置。
- 如果 Subject 显式设置了策略，则使用主题级配置，忽略全局配置。
- 修改全局配置不会影响已设置主题级策略的 Subject。
- 删除主题级策略后，该 Subject 回退到全局配置。
4.5 配置管理最佳实践
在实际项目中，合理规划全局与主题级配置可以降低维护成本，同时满足不同主题的演化需求。
推荐策略：
- 全局设置 BACKWARD：作为安全默认值，确保大多数主题的消费者可以安全升级。
- 核心业务主题使用 FULL：对订单、支付等关键数据流，启用 FULL 兼容性，避免双向不兼容。
- 临时或调试主题使用 NONE：开发环境或一次性数据流，关闭兼容性检查以提高迭代速度。
- 审计合规主题使用 FULL_TRANSITIVE：需要保留完整演化历史的场景，确保所有历史版本均可互读。
常见陷阱：
- 不要在生产环境中随意修改全局兼容性策略，可能导致已有 Subject 行为突变。
- 主题级策略一旦设置，建议通过 IaC（基础设施即代码）管理，避免手动误操作。
- 版本号不可回退，如果提交了不兼容的 Schema，只能通过创建新版本修复，无法删除历史版本。