4、Schema兼容性类型：向后兼容、向前兼容、完全兼容、不兼容、Transitive兼容性

聊到Schema治理，绕不开的一个核心话题就是兼容性。说白了，你改了Schema，到底会不会把线上正在跑的服务搞挂？我见过太多团队，因为对兼容性理解不透彻，上线前拍胸脯说“没问题”，结果凌晨三点被报警电话叫醒。

这一节，我把五种兼容性类型掰开揉碎了讲清楚。每种类型我都会结合真实项目里的场景，告诉你什么时候该用，什么时候千万别碰。

4.1 向后兼容（Backward Compatibility）

这是最基础、也是最常见的一种兼容性。定义很简单：新版本的Schema能正确读取旧版本Schema产生的数据。

举个例子，你有个用户信息Schema，旧版本有 name 和 age 两个字段。新版本加了一个 email 字段，并且标记为 optional。那么，用新Schema的消费者，读到旧Schema产生的数据时，email 字段为空，但程序不会报错。这就是向后兼容。

我在项目中遇到过最典型的场景是日志采集系统。采集端升级了Schema，加了几个新标签，但下游的ETL任务还没来得及更新。如果新Schema不向后兼容，整个数仓链路直接断掉。嗯，那场面，真是惨不忍睹。

4.2 向前兼容（Forward Compatibility）

向前兼容正好反过来：旧版本的Schema能正确读取新版本Schema产生的数据。

你想想看，这在实际中意味着什么？意味着你的消费者可以晚点升级，甚至不升级。这在微服务架构中特别有用。比如，你有一个下游服务，负责处理用户订单。上游的订单服务升级了Schema，加了几个字段。如果新Schema是向前兼容的，下游的老服务依然能正常处理新数据，只是忽略掉它不认识的字段而已。

我记得有一次，我们团队负责的支付网关需要紧急修复一个安全漏洞，必须升级Schema。但下游的对账系统因为排期问题，要两周后才能升级。怎么办？我们选择了向前兼容的方案。上游改了Schema，下游的老代码照常运行，只是新加的字段被忽略。两周后，下游升级，一切无缝衔接。

4.3 完全兼容（Full Compatibility）

完全兼容，就是同时满足向后兼容和向前兼容。说白了，新老Schema可以互相读取对方产生的数据，双向通行。

这是最理想的状态，但也是最难做到的。我个人的经验是，只有在Schema变更非常克制的情况下，才能维持完全兼容。比如，只新增optional字段，不改类型，不改字段名，不改默认值。

什么时候需要完全兼容？当你的系统中有多个服务，升级节奏不一致，而且你无法控制所有服务的升级时间时。比如，一个开放API平台，你的客户端成千上万，你不可能要求所有客户端同时升级。这时候，API的Schema必须保持完全兼容。

4.4 不兼容（Breaking Change）

不兼容，就是改了Schema之后，新老版本完全无法互通。这是最危险的一种情况，但有时候又不得不做。

什么情况下会出现不兼容？

• 删除字段（尤其是required字段）
• 修改字段类型（比如把int改成string）
• 修改字段名称
• 修改required/optional属性（把optional改成required）
• 修改默认值（导致语义变化）

我曾经在一个项目中，因为业务重构，需要把用户ID从int类型改成UUID字符串。这是不兼容的变更。我们当时做了几件事：

1. 提前一个月发公告，通知所有下游服务
2. 在灰度环境中先跑新版本，观察兼容性影响
3. 上线时采用蓝绿部署，新老版本同时运行，逐步切流
4. 准备好回滚方案，一旦出问题，立刻切回老版本

4.5 Transitive兼容性

Transitive兼容性，翻译过来就是“传递性兼容”。这个概念在Schema Registry中特别重要，尤其是在使用Avro或者Protobuf时。

定义是这样的：如果Schema V1兼容V2，V2兼容V3，那么V1和V3之间是否兼容？如果答案是肯定的，就说明兼容性具有传递性。

你想想看，为什么这个属性重要？因为在实际的Schema演进中，你不可能只做一次变更。Schema会经历V1→V2→V3→V4……的持续演进。如果兼容性不具有传递性，那么V1和V3之间可能就不兼容了，即使每一步都是兼容的。

举个例子：

• V1：有字段 name（string）
• V2：新增字段 age（int，optional），向后兼容V1
• V3：删除字段 name，向后兼容V2？不，V3不兼容V2，因为删除了字段

但如果V3不是删除，而是把 name 改名为 full_name，并且保留 name 作为别名。那么V3可能兼容V2，V2兼容V1，但V3和V1之间呢？如果V1的消费者不认识 full_name，只认识 name，那V3就不向前兼容V1。

所以，Transitive兼容性要求：每一次变更都必须同时考虑与所有历史版本的兼容性，而不仅仅是与上一个版本。

4.6 一张图看懂五种兼容性

下面这张图，我把五种兼容性的关系梳理了一下。你可以把它当作一个快速参考。

4.7 实战中的选择策略

说了这么多理论，到底在实际项目中怎么选？我总结了一个简单的决策树：

• 能选完全兼容，就选完全兼容。 这是最省心的方案，但代价是Schema演进速度慢。
• 如果做不到完全兼容，优先保证向后兼容。 因为消费者通常比生产者多，升级消费者成本更高。
• 只有在你能控制所有消费者升级节奏时，才考虑向前兼容。 比如，内部微服务，你可以强制要求所有下游在某个时间点前升级。
• 不兼容变更，能不做就不做。 实在要做，必须走变更评审流程，必须有版本号隔离，必须有回滚方案。
• 开启Transitive兼容性检查。 这是长期Schema治理的基石，能帮你避免“积小错成大错”。