3. 数据契约生命周期：从设计到演进的完整闭环
数据契约不是写一份就完事的文档。它跟代码一样，有自己的生命周期。我见过不少团队，花两周时间把契约写得漂漂亮亮，然后往 wiki 上一扔，就再也没人管了。结果呢？三个月后，生产数据对不上，大家互相甩锅。
说白了，契约得「活」起来。它要经历设计、发布、绑定、监控、演进这五个阶段。每个阶段都有坑，咱们一个一个说。
3.1 契约设计：把共识变成结构
设计阶段，说白了就是「拉人对齐」。我个人的习惯是，先拉上数据生产方和消费方，开一个半小时的会。别开太久，超过两小时人就散了。
设计时要回答三个问题：
- 谁生产？ 哪个系统、哪个表、哪个字段？
- 谁消费？ 下游是实时流还是离线批？延迟要求多少？
- 怎么保证？ 字段不能为空？值域范围？更新频率？
举个例子，我曾经帮一个电商团队设计订单数据的契约。生产方是交易系统，消费方是实时大屏和离线报表。我们定了一个简单的契约：
{
"contract_id": "order_001",
"producer": "trade_system.order_topic",
"schema": {
"order_id": {"type": "string", "required": true},
"user_id": {"type": "string", "required": true},
"amount": {"type": "double", "min": 0.01, "max": 999999.99},
"status": {"type": "enum", "values": ["pending", "paid", "cancelled"]},
"event_time": {"type": "timestamp", "format": "yyyy-MM-dd'T'HH:mm:ss'Z'"}
},
"sla": {
"max_latency_seconds": 5,
"min_throughput": 100
}
}嗯，这里要注意：设计阶段不要追求完美。先定一个「够用」的版本，后面可以迭代。我见过有人花一个月设计契约，结果业务早就变了。
3.2 契约发布：让所有人都知道
设计完了，得发出去。发布不是往群里扔个 JSON 文件就完事了。我建议走正式的发布流程：
- 版本化：契约要有版本号，比如 v1.0.0。每次修改都要升版本。
- 审批：生产方和消费方各出一个负责人签字。别嫌麻烦，这是责任边界。
- 归档：发布到契约中心（比如 Schema Registry 或 Git 仓库），带上变更日志。
3.3 契约绑定：把规则写进代码
绑定阶段，就是把契约从「文档」变成「代码」。说白了，让系统强制执行契约规则。
常见的绑定方式有三种：
| 绑定方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Schema Registry | Kafka 消息 | 原生支持，性能好 | 只支持 Avro/Protobuf |
| API 网关校验 | HTTP 接口 | 灵活，可自定义规则 | 增加延迟 |
| 数据管道侧边校验 | Flink/Spark 流处理 | 实时拦截脏数据 | 需要额外开发 |
我个人比较推荐 Schema Registry + 数据管道侧边校验的组合。上游用 Registry 保证序列化格式正确，下游用管道校验保证业务语义正确。两条线，双保险。
3.4 契约监控：别等出事了再查
绑定完了，不代表万事大吉。你得盯着它。监控什么？我总结了三类指标：
- 合规率：有多少数据通过了契约校验？低于 99.9% 就要报警。
- 延迟：数据从生产到消费，花了多久？超过 SLA 阈值要追查。
- 变更频率：契约版本更新了多少次？频繁变更说明设计阶段没对齐。
我习惯在 Grafana 上拉一个「契约健康看板」，每天扫一眼。如果合规率突然掉到 95% 以下，不用想，肯定是上游改了逻辑没通知。
为什么会这样？因为生产方觉得「我就加个字段，不影响下游」，但下游的消费逻辑可能因为字段顺序变化就崩了。所以监控不只是看数据，更是看「人的行为」。
3.5 契约演进：拥抱变化，但要有章法
业务在变，契约也得变。但变不能乱变。我见过最离谱的事：有人直接在生产环境改了契约，下游消费全挂了。
契约演进要遵循几个原则：
- 向后兼容：新增字段用 optional，不要删字段，不要改字段类型。
- 灰度发布：先让 10% 的流量走新契约，观察没问题再全量。
- 废弃流程：旧版本要标记 deprecated，给下游至少两周的迁移窗口。
演进的核心是「可回滚」。每次变更都要想：如果出问题了，怎么退回去？
3.6 生命周期全景图
说了这么多，咱们用一张图把整个生命周期串起来。下面这张 SVG 图展示了五个阶段的流转关系：
这张图想表达的核心思想是：数据契约不是一条直线走到底，而是一个闭环。监控发现问题，演进调整方案，再回到设计阶段重新迭代。只有这样，契约才能跟上业务的变化。