4、数据契约注册中心：Schema Registry 原理

好，咱们进入第四章节。前面聊了契约怎么定义、怎么变更，那这些契约到底存在哪儿？谁来管它们的版本？谁来保证生产者和消费者用的 schema 是同一个？

答案就是——Schema Registry。说白了，它就是一个专门存 schema 的数据库，外加一套版本管理和兼容性检查的引擎。我最早接触它是在做 Kafka 消息治理的时候，那时候团队里经常出现“消费者反序列化失败”的线上事故，后来上了 Confluent Schema Registry，这类问题基本绝迹了。

4.1 为什么需要 Schema Registry？

你想想看，如果没有注册中心，会怎样？

• 生产者改了字段类型，消费者不知道，直接报错。
• 同一个 topic 里混了三种版本的 schema，消费端根本没法统一处理。
• 想回滚到上一个版本？没人记得上一版长什么样。

我在项目中遇到过最典型的一个场景：业务方为了加一个字段，直接把 Avro schema 里的字段顺序调了一下，结果下游所有消费者全部挂掉。为什么？因为 Avro 的默认反序列化是位置匹配，不是名称匹配。这种坑，没有 Schema Registry 的校验，光靠口头约定根本防不住。

所以，Schema Registry 要解决三个核心问题：

1. 统一存储：所有 schema 集中管理，谁也别自己存一份。
2. 版本追溯：每次变更都生成新版本，随时可以回看。
3. 兼容性校验：变更前先检查，不兼容就不让过。

4.2 Confluent Schema Registry 架构

Confluent Schema Registry 是目前最主流的实现。它本身是一个独立的 REST 服务，后端可以挂 Kafka、内存或数据库。我习惯用 Kafka 做后端存储，因为这样 schema 的变更历史本身也变成了一个不可变日志，跟数据契约的审计需求天然吻合。

它的核心组件就三块：

下面这张图是我自己画的一个简化流程，你看一眼就明白了：

流程其实很简单：生产者先把 schema 注册到 Registry，Registry 存下来并返回一个全局唯一的 ID。之后生产者发消息时，只带这个 ID，不带完整的 schema。消费者拿到消息后，用 ID 去 Registry 拉 schema，然后反序列化。

这样做的好处很明显——消息体变小了，而且 schema 的变更对消费者是透明的。只要兼容性检查过了，消费者那边自动适配。

4.3 注册流程详解

注册一个 schema 的 REST 调用长什么样？我给你看个实际例子：

POST /subjects/order-event/versions
Content-Type: application/vnd.schemaregistry.v1+json

{
  "schema": "{\"type\":\"record\",\"name\":\"OrderEvent\",\"fields\":[{\"name\":\"orderId\",\"type\":\"string\"},{\"name\":\"amount\",\"type\":\"double\"}]}"
}

返回结果：

{
  "id": 101,
  "version": 3,
  "schema": "{...}"
}

这里有几个关键点：

• subject：相当于 schema 的命名空间，通常一个 topic 对应一个 subject。
• version：从 1 开始递增，每次注册新 schema 就加 1。
• id：全局唯一，跟 subject 无关。同一个 schema 内容在不同 subject 下可能共享同一个 id。

4.4 兼容性检查策略

这是 Schema Registry 最核心的功能。它支持几种策略，我列个表对比一下：

我个人习惯在生产环境用 FULL_TRANSITIVE。为什么？因为数据契约一旦发布，生产者和消费者可能不在同一个发布周期里。你永远不知道哪个消费者还在用哪个老版本。双向传递兼容，是最省心的选择。

4.5 版本存储与生命周期

每个 schema 版本在 Registry 里是永久保存的。默认不会自动删除。我见过有些团队因为磁盘不够，直接删历史版本，结果出问题想回滚，发现回不去了。

版本存储的结构大致是这样：

subject: order-event-value
  ├── version 1: {orderId: string, amount: double}
  ├── version 2: {orderId: string, amount: double, userId: string}
  └── version 3: {orderId: string, amount: double, userId: string, timestamp: long}

每次查询时，你可以按版本号查，也可以按全局 ID 查。我建议在应用层缓存 Schema ID 到 Schema 的映射，避免每次反序列化都去请求 Registry，能省不少延迟。

另外，Registry 还支持 schema 演进的概念。什么意思呢？就是同一个 subject 下的 schema 版本之间，必须满足你设定的兼容性策略。如果你试图注册一个不兼容的 schema，Registry 会直接拒绝：

HTTP/1.1 409 Conflict
{
  "error_code": 409,
  "message": "Schema being registered is incompatible with an earlier schema"
}