3. 数据契约的 Schema 定义：Avro、Protobuf、JSON Schema 的选择与对比

说到数据契约，最核心的其实就是 Schema 定义。你想想看，契约双方要是连数据长什么样都说不清楚，那还怎么玩？我个人习惯把 Schema 比作「数据世界的身份证」——它规定了字段名、类型、是否必填，甚至版本号。

市面上主流的 Schema 语言有三家：Avro、Protobuf、JSON Schema。嗯，这里要注意，它们不是简单的「谁替代谁」的关系，而是各有各的适用场景。我在项目中遇到过不少团队，一上来就选 Protobuf，结果发现下游系统全是 HTTP 接口，硬生生多了一层序列化转换，得不偿失。

3.1 三者的核心差异

先看一张对比表，帮你快速建立认知：

说白了，选哪个取决于你的数据流场景。下面我展开聊聊每个方案的实战经验。

3.2 Avro：流式数据的老大哥

Avro 是我在 Kafka 生态里用得最多的 Schema 语言。它的设计哲学很特别——Schema 和数据是分开存的。你生产一条 Avro 消息，消息体里只有二进制数据，Schema 存在 Schema Registry 里。消费者拿到消息后，先去 Registry 拉 Schema，再反序列化。

这样做的好处是什么？Schema 可以独立演进。比如你给用户表加个 phone_number 字段，只要设置默认值，老消费者照样能读新数据。我曾经在一个实时数仓项目里，用 Avro 管理了 200 多个 Topic 的 Schema，兼容性从来没出过问题。

{
  "type": "record",
  "name": "UserEvent",
  "namespace": "com.example.avro",
  "fields": [
    { "name": "user_id", "type": "string" },
    { "name": "event_type", "type": "string" },
    { "name": "timestamp", "type": "long" },
    { "name": "ip_address", "type": ["null", "string"], "default": null }
  ]
}

注意看 ip_address 字段，我用了联合类型 ["null", "string"]，并给了默认值 null。这就是 Avro 的兼容性秘诀——新字段必须可空或有默认值。否则老消费者读到新数据会直接崩溃。

3.3 Protobuf：微服务间的性能之王

Protobuf 是 Google 的亲儿子，天生为 gRPC 设计。它的序列化速度比 Avro 快 20%-30%，体积也更小。但代价是——你得手动管理字段编号。

每个字段都要给一个唯一的数字编号，而且编号一旦发布就不能改。为什么？因为 Protobuf 的二进制格式里，字段是靠编号而不是名字来匹配的。你改了编号，老版本的数据就全乱套了。

Protobuf 的兼容性策略和 Avro 不太一样。它通过 optional 关键字和 reserved 关键字来管理。比如：

syntax = "proto3";

message UserEvent {
  string user_id = 1;
  string event_type = 2;
  int64 timestamp = 3;
  reserved 4;  // 曾经用过，现在废弃
  optional string ip_address = 5;
}

看到 reserved 4 了吗？这就是 Protobuf 的「墓碑机制」——你删掉一个字段后，要把它的编号标记为 reserved，防止后来的人误用。嗯，这个细节很容易被忽略，但踩过坑的人都知道它的重要性。

3.4 JSON Schema：REST API 的万金油

JSON Schema 和前两者完全不同。它不负责序列化，只负责描述和校验。你的数据还是 JSON 格式，但通过 Schema 来约束字段类型、范围、格式等。

它的优势是零学习成本——只要你会写 JSON，就会写 JSON Schema。而且它天然适合 HTTP 接口，因为请求体和响应体本身就是 JSON。

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "username": { "type": "string", "minLength": 3, "maxLength": 20 },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 }
  },
  "required": ["username", "email"]
}

但 JSON Schema 有个硬伤——没有原生的向前兼容机制。你给对象加个新字段，老消费者如果没做防御性编程，读到不认识字段时可能会报错。我建议的做法是：在 API 网关层做 Schema 校验，同时给消费者文档说明「遇到未知字段请忽略」。

3.5 如何选择？一张决策流程图

下面这张 SVG 图总结了我的选型逻辑，你可以直接拿来当团队决策参考：

3.6 我的最终建议

说了这么多，其实选型没那么复杂。我总结三条经验：

• 数据走 Kafka 或 Hadoop 生态 → 无脑选 Avro。Schema Registry 的兼容性管理太香了，你想想看，几百个 Topic 的 Schema 自动演进，省了多少人工审核。
• 微服务间用 gRPC 通信 → 选 Protobuf。性能优势明显，而且 Google 的生态工具链（如 protoc-gen-validate）能帮你自动生成校验代码。
• 对外暴露 REST API → 选 JSON Schema。别折腾，你的调用方可能连 Protobuf 都没装，JSON 才是通用语言。