4、Schema兼容性规则：向前兼容、向后兼容、完全兼容、破坏性变更的识别

Schema 兼容性，说白了就是「改了字段定义后，老数据还能不能读？老程序还能不能跑？」。

我见过太多团队，一上来就搞 Avro、Protobuf，结果上线第一天就因为改了字段类型导致全线崩溃。嗯，这里要讲清楚。

4.1 四种兼容性定义

先给个全景图。我习惯把这四种规则画成一张表，方便对照：

4.2 向后兼容（Backward Compatibility）

这是最常用的规则。新 Schema 能读老数据，消费者不用改代码。

我在项目中遇到过：一个订单系统，老版本只有必填字段，新版本加了 optional 的优惠券字段。消费者没升级，照样能消费老数据——因为新 Schema 读到老数据时，优惠券字段自动填 null。

4.3 向前兼容（Forward Compatibility）

老 Schema 能读新数据。说白了，生产者可以先升级，消费者慢慢跟。

你想想看，在微服务架构里，这招特别有用。比如数据平台要废弃一个字段，先让生产者停写，消费者那边老 Schema 读到新数据时，遇到不认识字段直接忽略——这就是向前兼容。

操作	向后兼容	向前兼容	完全兼容
新增 optional 字段	✅	❌	❌
删除 optional 字段	❌	✅	❌
新增 optional + 默认值	✅	✅	✅
修改字段类型（收紧）	❌	❌	❌
修改字段类型（放宽）	✅	❌	❌

4.4 完全兼容（Full Compatibility）

向后 + 向前同时满足。这是最严格的规则，适合核心业务契约。

我个人习惯在「订单状态」「用户等级」这类跨团队共享的 Schema 上启用完全兼容。代价是变更成本高，但换来的是上下游零协调。

4.5 破坏性变更的识别

破坏性变更，就是改了之后，老数据读不了，或者老程序跑不动。识别它其实有套路：

1. 删字段——老数据里还有这个字段，新 Schema 不认了，反序列化直接挂。
2. 改字段类型——比如 string → int，老数据是 "abc"，新 Schema 解析不了。
3. 收紧约束——optional → required，nullable → non-null。
4. 改字段名——除非框架支持别名映射，否则必挂。
5. 改 enum 值名称——序列化存的是 ordinal 或 name，改了就对不上了。

4.6 实战：如何选择兼容性策略

没有银弹。我一般按场景选：

• 核心业务契约（订单、支付、用户）：完全兼容。变更必须走审批 + 灰度。
• 内部数据管道（ETL、日志）：向后兼容。生产者先改，消费者慢慢跟。
• 事件溯源 / CDC：向前兼容。老消费者必须能读新事件。
• 快速迭代模块：破坏性变更 + 版本号 + 迁移窗口。但要提前通知所有消费者。

4.7 代码示例：Avro Schema 兼容性检查

以 Avro 为例，看看怎么用代码判断兼容性：

// 老 Schema
String oldSchemaStr = "{"
    + "\"type\": \"record\","
    + "\"name\": \"Order\","
    + "\"fields\": ["
    + "  {\"name\": \"id\", \"type\": \"string\"},"
    + "  {\"name\": \"amount\", \"type\": \"double\"}"
    + "]}";

// 新 Schema（加了 optional 的 coupon 字段）
String newSchemaStr = "{"
    + "\"type\": \"record\","
    + "\"name\": \"Order\","
    + "\"fields\": ["
    + "  {\"name\": \"id\", \"type\": \"string\"},"
    + "  {\"name\": \"amount\", \"type\": \"double\"},"
    + "  {\"name\": \"coupon\", \"type\": [\"null\", \"string\"], \"default\": null}"
    + "]}";

Schema oldSchema = new Schema.Parser().parse(oldSchemaStr);
Schema newSchema = new Schema.Parser().parse(newSchemaStr);

// 检查向后兼容
boolean backwardCompatible = SchemaCompatibility
    .checkReaderWriterCompatibility(newSchema, oldSchema)
    .getResult() == SchemaCompatibility.SchemaCompatibilityType.COMPATIBLE;

System.out.println("向后兼容: " + backwardCompatible); // true

为什么这样写？因为 Avro 的 checkReaderWriterCompatibility 方法，第一个参数是 reader（消费者），第二个是 writer（生产者）。新 Schema 作为 reader 去读老数据，能读通就是向后兼容。