4、兼容策略类型总览：七种策略，一张图说清楚

好，咱们进入正题。上一章聊了为什么需要兼容策略，这一章我把七种策略摆出来，挨个讲透。

说实话，我刚接触数据契约时，也被这七个名字绕晕过。BACKWARD、FORWARD、FULL、NONE，后面还带个 TRANSITIVE…… 你想想看，光记住名字就得花点功夫。但实际用起来，核心逻辑其实就两条：谁兼容谁，以及要不要传递。

4.1 四种基础策略

先看四个不带 TRANSITIVE 的。它们是地基，后面的传递版本只是在这基础上加了个「传递检查」。

策略	核心含义	谁兼容谁	典型场景
BACKWARD	向后兼容	新 Schema 兼容老 Schema	消费者先升级，生产者后升级
FORWARD	向前兼容	老 Schema 兼容新 Schema	生产者先升级，消费者后升级
FULL	完全兼容	双向兼容	生产者和消费者可任意顺序升级
NONE	不兼容	不检查任何兼容性	开发环境、一次性数据管道

嗯，这里要注意：BACKWARD 和 FORWARD 的方向正好相反。我见过不少团队把这两个搞混，结果上线后消费者直接报错。我个人习惯用一个记忆法——「向后看」：BACKWARD 是新的能看懂旧的，所以消费者可以先升级到新 Schema，老数据还能读。

4.2 三种传递策略

TRANSITIVE 版本是什么意思？说白了，就是不仅要检查相邻版本，还要检查所有历史版本。

举个例子：你有 V1、V2、V3 三个版本。非传递版本只检查 V2 和 V3 是否兼容；传递版本会检查 V1、V2、V3 三者之间两两兼容。这就像多米诺骨牌——非传递只推倒下一张，传递要确保整条链都站得住。

策略	检查范围	严格程度	适用场景
BACKWARD_TRANSITIVE	新 Schema 兼容所有历史 Schema	高	长期存储、归档数据
FORWARD_TRANSITIVE	所有历史 Schema 兼容新 Schema	高	消费者版本跨度大的场景
FULL_TRANSITIVE	所有版本两两兼容	最高	金融、医疗等强监管领域

我曾经在一个金融项目中用过 FULL_TRANSITIVE。当时觉得「反正多检查一下没坏处」，结果每次 Schema 变更都要跑十几分钟兼容性检查，开发效率直线下降。后来我学乖了——传递策略虽好，但别滥用。只有在 Schema 版本数量少（比如少于 20 个）或者合规要求极高时才用。

4.3 七种策略的关系图

光看表格可能还不够直观。我画了一张图，把七种策略的层级关系理清楚。你一看就明白。

这张图把七种策略分成了两组。左边是基础策略，右边是传递策略。箭头表示「可以扩展为」。你注意看，NONE 没有对应的传递版本——因为不兼容就是完全不检查，加传递没意义。

4.4 如何选择？我的经验法则

说了这么多，到底怎么选？我总结了一个简单的决策流程，你照着走就行：

1. 先问：允不允许不兼容？ 如果允许，直接选 NONE。开发环境、一次性任务、内部调试，用 NONE 省事。
2. 再问：生产者和消费者谁先升级？ 消费者先升级 → BACKWARD；生产者先升级 → FORWARD。
3. 再问：能不能双向兼容？ 能 → FULL。这是最省心的，但约束也最多。
4. 最后问：历史版本需要保护吗？ 需要 → 加 TRANSITIVE。不需要 → 用基础版本就行。

4.5 一个真实案例

我之前帮一个电商团队做数据治理。他们的订单系统有 30 多个微服务，每个服务都有自己的 Schema。一开始他们全部用 NONE，结果经常出现「消费者反序列化失败」的线上事故。

我去了之后，做了三件事：

• 核心订单流（订单创建、支付、退款）强制用 BACKWARD
• 日志和监控数据用 NONE（丢了也不影响业务）
• 历史归档数据用 BACKWARD_TRANSITIVE（保证 5 年前的订单还能查）

效果很明显。兼容性事故从每周 3-4 次降到了 0。嗯，这就是策略选对的价值。