2. Schema 基础：Avro、Protobuf、JSON Schema 对比与选型
聊到 Schema Registry，绕不开的一个问题就是：到底用哪种 Schema 格式？
我见过不少团队，一上来就拍脑袋选 Protobuf，理由是“性能好”。也有人死守 JSON Schema，觉得“大家都懂 JSON”。说实话，选型这事没有银弹。每种格式都有自己的脾气，选对了事半功倍，选错了……嗯，后面改起来挺痛苦的。
2.1 三大 Schema 格式速览
先简单过一遍这三位的背景，后面再深入对比。
| 特性 | Avro | Protobuf | JSON Schema |
|---|---|---|---|
| 出身 | Apache Hadoop 生态 | Google 内部 → 开源 | IETF 标准 |
| 序列化格式 | 二进制（紧凑） | 二进制（紧凑） | 文本（JSON） |
| Schema 定义语言 | JSON 或 IDL | .proto 文件 | JSON |
| 是否需要 IDL 编译器 | 可选（动态类型友好） | 必须（生成代码） | 不需要 |
| Schema 演化 | 原生支持，规则清晰 | 支持，但需注意兼容性 | 支持，但实现差异大 |
一句话总结：Avro 是“数据湖亲儿子”，Protobuf 是“微服务标配”，JSON Schema 是“人类可读的瑞士军刀”。
2.2 Avro：为大数据而生
我个人最早接触 Avro 是在做 Hadoop 数据管道的时候。那时候 Hive 表用 Avro 存，Spark 作业直接读，爽得很。
Avro 的核心设计哲学：Schema 和数据一起传输。你没看错，Avro 文件头里就嵌着 Schema。这意味着什么？意味着你拿到一个 Avro 文件，不需要额外去查元数据，自己就能解析。
// Avro Schema 示例（JSON 格式）
{
"type": "record",
"name": "User",
"namespace": "com.example",
"fields": [
{"name": "id", "type": "int"},
{"name": "name", "type": "string"},
{"name": "email", "type": ["null", "string"], "default": null}
]
}注意上面那个 email 字段，类型是 ["null", "string"]，这是 Avro 的联合类型写法。加上 default: null，就表示这个字段可以缺失——这是 Avro 演化能力的基石。
我的经验：Avro 的 Schema 演化规则非常严谨。比如删除字段必须设置 default，新增字段不能是 required。我曾经在线上改过一个字段类型，从 int 改成 long，结果老数据读出来全乱了。后来老老实实加了新字段，废弃旧字段。
2.3 Protobuf：微服务界的宠儿
Protobuf 是 Google 的杰作。你想想看，Google 内部每天处理多少 RPC 调用？没有一套高效的序列化方案根本扛不住。
Protobuf 的强项在于：代码生成 + 强类型。你写一个 .proto 文件，编译器直接给你生成 Java、Go、Python 等语言的类。调用方和提供方都用同一套代码，类型安全有保障。
// Protobuf Schema 示例
syntax = "proto3";
package com.example;
message User {
int32 id = 1;
string name = 2;
optional string email = 3;
}看到那个 = 1、= 2 了吗？这是字段编号。Protobuf 用编号而不是字段名来编码，所以序列化后的体积非常小。但这也带来一个问题：字段编号一旦用了就不能改。我见过有人把字段 2 删了，后来新加字段又用了编号 2，结果老数据反序列化时字段全对不上……
避坑指南：Protobuf 的字段编号是稀缺资源。1-15 号只占 1 个字节，16-2047 号占 2 个字节。高频字段尽量用小编号。我曾经在一个 .proto 文件里看到有人把字段编号从 1 排到 500，中间跳了很多号，白白浪费了空间。
2.4 JSON Schema：人类可读的妥协
JSON Schema 跟前面两位不一样。它不是序列化格式，而是描述 JSON 数据结构的规范。说白了，它只负责告诉你“数据长什么样”，不负责怎么存、怎么传。
// JSON Schema 示例
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"id": {"type": "integer"},
"name": {"type": "string"},
"email": {"type": "string", "format": "email"}
},
"required": ["id", "name"]
}JSON Schema 最大的优势是零学习成本。你的团队如果全是前端或全栈工程师，让他们去学 .proto 语法或者 Avro IDL，可能有点抵触。JSON Schema 直接用 JSON 写，谁都会。
但代价也很明显：性能差。JSON 序列化后的体积比 Avro 和 Protobuf 大 3-5 倍，解析速度也慢一个数量级。而且 JSON Schema 的演化规则没有统一标准，不同库的实现差异很大。
2.5 核心对比：选型决策矩阵
下面这张表是我自己总结的，每次做技术选型都会拿出来对照一下。
| 评估维度 | Avro | Protobuf | JSON Schema |
|---|---|---|---|
| 序列化性能 | ★★★★☆ | ★★★★★ | ★★☆☆☆ |
| Schema 演化 | ★★★★★ | ★★★★☆ | ★★★☆☆ |
| 跨语言支持 | ★★★★☆ | ★★★★★ | ★★★★★ |
| 人类可读性 | ★★★☆☆ | ★★☆☆☆ | ★★★★★ |
| 生态成熟度 | ★★★★☆ | ★★★★★ | ★★★★☆ |
| 学习曲线 | ★★★☆☆ | ★★★★☆ | ★★☆☆☆ |
选型建议：
- 数据管道 / 数据湖场景 → Avro。Schema 随数据存储，演化灵活，Hadoop/Spark 原生支持。
- 微服务 RPC 调用 → Protobuf。性能极致，代码生成保证类型安全，gRPC 标配。
- API 网关 / 配置文件 / 日志 → JSON Schema。人类可读，调试方便，不需要高性能序列化。
2.6 一张图看懂选型逻辑
下面这张 SVG 图是我手绘的选型决策流程，你可以顺着箭头找到适合自己的方案。
2.7 实战中的选型考量
理论说完了，聊聊我在实际项目中踩过的坑。
场景一：Kafka 消息队列
Kafka 官方推荐 Avro，原因很简单：Avro 的 Schema 可以注册到 Schema Registry，消费者拿到消息后自动去 Registry 拉 Schema 来反序列化。Protobuf 也能用，但需要额外配置。JSON Schema 嘛……Kafka 消息量大的时候，JSON 的体积会让你怀疑人生。
场景二：跨团队接口对接
我曾经在两个团队之间做接口联调。A 团队用 Java，B 团队用 Go。一开始他们用 JSON Schema 对接口，结果每次字段变更都要两边改代码，还经常因为类型不一致出 bug。后来我建议换成 Protobuf，.proto 文件作为契约，两边各自生成代码，问题迎刃而解。
场景三：数据归档与回溯
数据存到 HDFS 或者 S3 里，几年后还要能读出来。这时候 Avro 的优势就体现出来了——Schema 就在文件头里，不需要依赖外部系统。Protobuf 如果丢了 .proto 文件，数据就废了。JSON Schema 虽然也能读，但存储成本高得吓人。
我的建议：如果你们团队刚开始接触 Schema Registry，可以从 Avro 入手。原因有三：一是 Avro 和 Schema Registry 的集成最成熟；二是 Avro 的演化规则最清晰，不容易踩坑；三是大数据生态（Kafka、Spark、Flink）对 Avro 支持最好。等团队经验丰富了，再根据具体场景考虑 Protobuf 或 JSON Schema。
2.8 小结
这一章我们聊了 Avro、Protobuf、JSON Schema 三种格式的核心差异和选型思路。说白了，没有完美的 Schema 格式，只有最适合你场景的选择。Avro 适合数据管道，Protobuf 适合微服务，JSON Schema 适合人类可读的场景。