4、数据契约的生命周期：设计、发布、订阅、消费、废弃
数据契约不是写一次就完事的文档。它有自己的生命周期，从出生到消亡，每个阶段都有坑。我见过太多团队把契约当静态文件管理，结果上线三个月就没人看了。
说白了，数据契约的生命周期就是五个阶段：设计 → 发布 → 订阅 → 消费 → 废弃。每个阶段都有对应的职责和检查点。下面我逐个拆解。
核心观点：数据契约的生命周期管理，本质上是把「口头约定」变成「可执行、可追溯、可废弃」的工程规范。缺少任何一个阶段，契约都会沦为摆设。
4.1 设计阶段：别急着写代码
设计阶段最容易犯的错，就是产品经理拍脑袋，开发直接上手写 Schema。我遇到过好几次，上线后才发现字段含义对不上，消费者拿到的数据跟预期完全两码事。
我个人习惯，设计阶段至少要做三件事：
- 明确数据域和实体——这个数据属于哪个业务域？是订单、用户还是库存？
- 定义字段语义和约束——字段类型、是否必填、取值范围、枚举值列表。
- 约定 SLA 承诺——数据延迟多久？可用性几个9？峰值 QPS 多少？
我的小技巧：设计阶段拉上消费者一起评审。别自己闷头写，等发布后再改就晚了。我曾经因为没拉业务方评审，把「订单状态」的枚举值写错了，上线后数据对不上，回滚花了整整两天。
设计阶段的产出物，通常是一份契约草案。我建议用 YAML 或 JSON Schema 来写，别用 Word 文档。机器可读，才能自动化。
# 示例：订单数据契约草案（简化版）
schema:
name: order_created
version: 1.0.0
fields:
- name: order_id
type: string
required: true
description: "订单唯一标识"
- name: user_id
type: string
required: true
- name: total_amount
type: decimal(10,2)
required: true
- name: status
type: string
enum: ["pending", "paid", "shipped", "cancelled"]
required: true
sla:
max_latency_seconds: 30
availability: 99.9
peak_qps: 5000
4.2 发布阶段：版本控制是底线
设计评审通过后，就该发布了。发布不是把文件扔到 Git 仓库就完事。你需要一个契约注册中心（Schema Registry），让所有消费者能发现、能订阅。
我见过最坑的做法：把契约文件放在某个同事的网盘里，或者写在 Wiki 上。一旦那人离职，契约就失联了。
发布阶段的核心要点：
- 版本号管理——语义化版本（SemVer），主版本号变更意味着不兼容。
- 兼容性检查——发布前自动检查新版本是否向后兼容。不兼容的变更必须走审批流程。
- 发布通知——通过 Webhook 或消息队列通知所有已订阅的消费者。
注意：发布不兼容版本时，一定要给消费者留出迁移窗口。我曾经在项目中直接发布了 v2.0.0，把字段类型从 string 改成了 int，结果下游 20 多个服务全部报错。那场面，真是惨不忍睹。
4.3 订阅阶段：双向确认
订阅不是消费者单方面说「我要了」就完事。我建议做双向确认：生产者确认「我能提供」，消费者确认「我收到了」。这样双方都有记录，出了问题好追溯。
订阅阶段需要明确：
| 项目 | 说明 |
|---|---|
| 订阅方式 | Pull（消费者主动拉取）还是 Push（生产者主动推送）？ |
| 数据格式 | JSON、Avro、Protobuf？消费者端是否支持？ |
| 回调地址 | Push 模式下，消费者提供接收端点。 |
| 订阅有效期 | 长期订阅还是临时测试？过期后自动取消。 |
我个人习惯，订阅完成后生成一份订阅确认书，包含双方负责人、SLA 承诺、联系方式。别小看这一步，出问题的时候能省去大量扯皮时间。
4.4 消费阶段：监控是眼睛
消费阶段是契约真正发挥价值的地方。生产者按契约推送数据，消费者按契约解析数据。但现实往往没那么美好。
我遇到过的情况：
- 生产者偷偷改了字段含义，没更新契约。
- 消费者没按契约做校验，数据格式错了也不报错。
- 网络抖动导致数据延迟，SLA 被打破。
消费阶段必须做三件事：
- 数据质量监控——字段缺失率、格式错误率、枚举值合规率。
- SLA 监控——延迟、吞吐量、可用性。
- 契约合规审计——定期检查实际数据是否与契约一致。
避坑指南：我曾经在消费端只做了「数据能收到就行」的检查，结果生产端把金额字段的单位从「分」改成了「元」，我们整整跑了一周才发现。从那以后，我强制要求消费端做字段级校验，哪怕多花点性能，也比数据错了强。
4.5 废弃阶段：好聚好散
废弃是最容易被忽略的阶段。很多团队的契约越积越多，最后没人知道哪些还在用、哪些已经死了。
废弃不是直接删掉。我建议按这个流程走：
- 废弃通知——提前至少 30 天通知所有订阅者。
- 兼容期——旧版本继续运行，但标记为「即将废弃」。
- 迁移方案——提供新版本的迁移指南和工具。
- 清理记录——废弃后保留历史记录，方便追溯。
血的教训：我曾经直接废弃了一个老版本的契约，没通知任何人。结果有个离线任务还在用那个版本，第二天数据全挂了。从那以后，我定了一条铁律：废弃必须走审批，必须通知所有订阅者，必须留 30 天缓冲期。
废弃完成后，在注册中心里标记为「已废弃」，但不要物理删除。历史数据查询和审计可能还需要用到。
数据契约的生命周期，说白了就是一套从生到死的管理规范。设计要严谨，发布要可控，订阅要确认，消费要监控，废弃要体面。每个阶段都有对应的工具和流程，缺一不可。
嗯，这一章的内容就到这里。记住，契约不是写给别人看的，是写给自己和团队用的。管理好生命周期，数据治理就成功了一半。