📚 课程目录第3章 Schema格式与标准

3、Schema格式与标准：四大主流方案详解

说到Schema的具体格式，市面上主流的有四种：Avro、Protobuf、JSON Schema、Thrift。我这些年跟它们都打过不少交道，每种都有自己的脾气。今天咱们就一个一个掰开揉碎了讲清楚。

3.1 Avro Schema详解

Avro是Hadoop生态里出来的，我个人特别喜欢它的设计哲学——Schema和数据永远在一起。什么意思呢？就是Avro文件里，Schema是自描述的，你拿到一个Avro文件，就能直接读出它的结构。

核心特点：Avro使用JSON定义Schema，支持动态类型，序列化后的数据体积小，读写速度快。

来看一个典型的Avro Schema定义：

{
  "namespace": "com.example",
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "name", "type": "string"},
    {"name": "age", "type": "int"},
    {"name": "email", "type": ["null", "string"], "default": null}
  ]
}

注意看那个email字段，用了联合类型["null", "string"]。这是Avro处理可选字段的标准做法。我在项目中遇到过有人直接把字段设为nullable，结果序列化时各种报错——嗯，Avro里必须用这种联合类型来表示可空字段。

Avro的Schema演化规则

Avro的兼容性规则很清晰，我总结了一张表：

演化操作	向前兼容	向后兼容	说明
新增字段（有默认值）	✅	✅	必须提供default值
删除字段	✅	❌	旧数据无法读取新Schema
修改字段类型	❌	❌	除非使用联合类型
重命名字段	❌	❌	Avro不支持字段重命名

避坑指南：我曾经在线上环境直接删除了一个字段，结果下游消费方全部崩溃。后来我学乖了——删除字段前，先标记为deprecated，等所有消费者都升级了再删。

3.2 Protobuf Schema详解

Protobuf是Google家的，现在几乎成了微服务间通信的事实标准。它的Schema定义文件是.proto文件，语法比Avro更紧凑。

同样的User对象，用Protobuf写出来是这样的：

syntax = "proto3";

package com.example;

message User {
  string name = 1;
  int32 age = 2;
  optional string email = 3;
}

看到那个= 1、= 2、= 3了吗？这是字段编号，Protobuf用编号而不是字段名来标识字段。你想想看，这意味着什么？——字段名可以随便改，只要编号不变，序列化格式就兼容。

Protobuf的字段编号规则

这里有个坑，我刚开始用Protobuf时踩过。字段编号不是随便写的：

1-15：用1个字节编码，留给频繁使用的字段
16-2047：用2个字节编码
19000-19999：保留，不能用
最大：2^29 - 1，约5.3亿

我的建议：核心字段用1-15，扩展字段用16以上。我曾经见过有人把所有字段都从1开始编号，结果后来加了20个字段，前15个全是低频字段，浪费了宝贵的1字节编码空间。

Protobuf的兼容性规则

Protobuf的兼容性比Avro灵活一些：

演化操作	向前兼容	向后兼容	说明
新增字段	✅	✅	新字段使用新编号
删除字段	✅	❌	保留编号，标记为reserved
修改字段类型	❌	❌	类型必须严格匹配
重命名字段	✅	✅	编号不变即可

3.3 JSON Schema详解

JSON Schema跟前面两个不一样，它不是序列化格式，而是描述JSON数据结构的语言。说白了，就是用来校验你的JSON数据长什么样。

来看一个JSON Schema的例子：

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

JSON Schema的优势在于它的表达能力极强。你可以定义正则表达式、枚举值、条件约束、数组长度限制……几乎你能想到的所有校验规则，它都支持。

适用场景：JSON Schema最适合API网关的请求校验、配置文件校验、数据交换格式的契约定义。但它不擅长高性能序列化——毕竟JSON本身就有冗余。

JSON Schema的版本演进

JSON Schema有几个主流版本，我整理了一下：

版本	发布时间	主要特性
draft-04	2013年	基础校验、$ref引用
draft-06	2016年	const关键字、contains关键字
draft-07	2018年	if/then/else条件校验
2019-09	2019年	unevaluatedProperties、词汇表
2020-12	2020年	prefixItems、$defs替代definitions

注意：不同版本的JSON Schema实现不完全兼容。我曾经把一个draft-04的Schema直接升级到2020-12，结果exclusiveMinimum的行为变了——draft-04里它是布尔值，2020-12里它是数字。这种细节坑了不少人。

3.4 Thrift Schema详解

Thrift是Facebook开源的，后来进了Apache。它的Schema定义文件是.thrift文件，语法跟Protobuf有点像，但功能更丰富。

Thrift的Schema定义：

namespace java com.example

struct User {
  1: required string name,
  2: required i32 age,
  3: optional string email
}

service UserService {
  User getUser(1: i32 userId),
  void createUser(1: User user)
}

看到没？Thrift不仅能定义数据结构，还能直接定义服务接口。这是它跟Avro和Protobuf最大的区别——Thrift是一个完整的RPC框架，而不仅仅是序列化协议。

Thrift的数据类型

Thrift支持的数据类型比Protobuf更丰富：

类型	Thrift表示	说明
布尔	bool	true/false
字节	byte	8位有符号整数
16位整数	i16	短整型
32位整数	i32	标准整型
64位整数	i64	长整型
双精度浮点	double	64位浮点
字符串	string	UTF-8编码
二进制	binary	未编码字节序列
列表	list<type>	有序列表
集合	set<type>	无序不重复集合
映射	map<k,v>	键值对

Thrift的传输协议

Thrift支持多种传输协议，这也是它的一个特色：

TBinaryProtocol：二进制格式，紧凑但不可读
TCompactProtocol：更紧凑的二进制格式，体积更小
TJSONProtocol：JSON格式，可读性好但体积大
TSimpleJSONProtocol：只写JSON，不可反序列化

我的经验：内部服务间通信用TCompactProtocol，调试阶段用TJSONProtocol。我曾经在生产环境误用了TJSONProtocol，结果带宽直接翻了三倍——JSON的冗余在流量大的时候真的很要命。

3.5 四种Schema格式对比

说了这么多，咱们来个终极对比。我根据自己的使用经验，画了下面这张图：

3.6 如何选择？我的建议

说实话，没有银弹。我这些年换过好几次方案，总结下来就几条：

大数据场景：选Avro。Hadoop、Kafka、Spark这些生态对Avro支持最好。
微服务通信：选Protobuf。性能好，生态强，gRPC标配。
API校验/配置文件：选JSON Schema。表达能力最强，人类可读。
多语言RPC：选Thrift。如果你需要同时支持十几种语言，Thrift的代码生成最成熟。