JSON 模式是一种方言，而非标准：你备选路径中的隐形崩溃
· 阅读需 13 分钟
我第一次看到备用路由引发的事故比它试图缓解的停机故障还要严重时，复盘文档的标题是这样写的：“主服务降级 11 分钟。备用服务导致我们的解析器降级了 6 天。” 没人写错代码。没人跳过 Schema 评审。18 个月前连接备用服务时的二级供应商集成测试还是通过的。其间发生的事情是，两个供应商之一悄悄收紧了其枚举强制转换（enum coercion）策略，而我们下游解析器所遵循的契约——我们认为“或多或少就是 JSON Schema”的契约——已经从共享标准漂移成了两个略微不兼容的方言。
这是我不断看到的失败模式，而且它总能让那些本该更明白的团队感到惊讶。“JSON 模式”听起来像是一个你开启的功能。其实不然。它是一个你需要维护的契约——针对你可能路由到的每一个供应商分别维护——而且随着供应商演进其结构化输出技术栈，这个契约每季度都会发生漂移。你签署合同时供应商文档中所暗示的“无缝替换”，在生产环境中其实是一个需要维护的转换层。如果没有这个层，你的备用路径就会变成一个纸面上的合规产物：存在于架构图中，但在你真正需要它的那天却是坏的。
