📚 课程目录第2章数据契约生命周期

数据契约生命周期：从生到死的治理之道

数据契约不是写一次就完事的静态文档。它跟咱们写的代码一样，有创建、有版本、有审批、有发布，最后还得有废弃。我见过太多团队把契约当成「一次性交付物」，结果半年后没人知道哪个版本在生效，生产环境跑着跑着就崩了。

这一章，咱们就把契约的完整生命周期掰开揉碎讲清楚。你想想看，一个契约从想法到退休，到底要经历哪些阶段？

  核心观点：数据契约的生命周期管理，本质上是「变更管理」在数据治理领域的落地。没有生命周期，契约就是一张废纸。

1. 契约创建：从零到一

创建契约，说白了就是「把口头约定变成书面规范」。我个人习惯用 YAML 或 Protobuf 来写，因为这两种格式对代码生成最友好。举个例子：

# data_contracts/user_profile_v1.yaml
version: "1.0.0"
kind: "DataContract"
metadata:
  name: "user_profile"
  domain: "user"
  owner: "team-user"
  producer: "user-service"
  consumers:
    - "recommendation-engine"
    - "analytics-dashboard"
spec:
  schema:
    fields:
      - name: "user_id"
        type: "string"
        required: true
        description: "用户唯一标识"
      - name: "email"
        type: "string"
        required: true
        format: "email"
      - name: "age"
        type: "integer"
        required: false
        constraints:
          minimum: 0
          maximum: 150
  sla:
    freshness: "5min"
    availability: "99.9%"

嗯，这里要注意：创建阶段最容易犯的错误是「过度设计」。我在项目中遇到过，业务方一口气定义了 50 个字段，结果上线后发现一半字段根本没人用。我的建议是——从核心字段开始，逐步迭代。

实战技巧：创建契约时，先问三个问题：谁生产？谁消费？最关键的 5 个字段是什么？其他字段可以后续版本追加。

2. 版本管理：契约的「Git 化」

契约跟代码一样，必须做版本管理。为什么？因为数据生产者和消费者可能不在同一个发布节奏上。你想想看，用户服务升级了接口，推荐引擎还在用老版本，这时候没版本管理就是灾难。

我推荐使用语义化版本号（SemVer）：

版本号	变更类型	示例
MAJOR	不兼容的变更	删除字段、修改字段类型
MINOR	向后兼容的新增	新增可选字段、新增枚举值
PATCH	向后兼容的修复	修正描述、调整约束范围

举个例子：v1.2.3 → v2.0.0 意味着消费者必须改造代码；v1.2.3 → v1.3.0 则消费者可以无缝升级。

避坑指南：我曾经见过一个团队，所有契约版本都叫「v1」，每次变更直接覆盖。结果三个月后，没人知道线上跑的是哪个版本。记住：版本号是契约的身份证，不能重复使用。

3. 审批流程：三权分立

契约不是一个人拍脑袋就能发布的。我建议设置三道关卡：

技术审核：检查 schema 是否合理、类型是否正确、约束是否可行。通常由数据架构师或 Tech Lead 负责。
业务审核：确认字段定义是否满足业务需求、SLA 是否合理。由业务负责人或产品经理负责。
安全审核：检查是否有敏感数据泄露风险、权限设置是否合规。由安全工程师或 DPO 负责。

这三道关卡可以并行，也可以串行。我个人习惯用并行 + 超时自动通过的模式——如果 48 小时内没人驳回，默认通过。不然的话，一个审批拖两周，业务早就凉了。

  关键原则：审批流程要「严而不死」。严是指关键变更必须有人把关；不死是指流程不能成为瓶颈，要有自动化和超时机制。

4. 发布：契约生效的时刻

审批通过后，契约进入发布阶段。发布不仅仅是「把文件存到 Git 仓库」，还包括：

注册到契约中心：让所有消费者能发现新版本
生成代码桩：自动生成生产者和消费者的接口代码
通知所有消费者：邮件、IM 或 Webhook 推送变更
启动兼容性检查：确保现有消费者不会因为新版本而报错

我记得有一次，我们发布了一个 MAJOR 版本，但忘了通知消费者。结果推荐引擎在凌晨三点突然报错，线上故障持续了 40 分钟。从那以后，我强制要求：发布前必须确认所有消费者已收到通知。

自动化建议：用 CI/CD 流水线自动执行发布步骤。Git push 到特定分支 → 自动审批 → 自动注册 → 自动通知。全程不需要人工干预。

5. 废弃：体面地退出

契约也有退休的一天。可能是业务下线了，可能是被新契约替代了。废弃不是「直接删掉」，而是要有优雅的退出策略：

标记为 deprecated：在契约中心打上「已废弃」标签，但保留历史数据
设置宽限期：给消费者至少 30 天迁移时间
监控消费情况：如果还有消费者在调用，自动提醒迁移
最终删除：确认零消费后，归档并删除

嗯，这里有个坑：不要轻易删除旧版本。我曾经手快删了一个废弃契约，结果半年后审计要求查历史数据，我们花了三天才从备份里捞出来。现在我的做法是：废弃的契约只做逻辑删除，物理保留至少一年。

硬规则：废弃契约必须满足以下条件才能最终删除：
1. 所有消费者已确认迁移
2. 宽限期已过（至少 30 天）
3. 审计日志已备份
4. 相关代码桩已清理

小结：生命周期管理的核心原则

讲到这里，你应该能感受到：契约的生命周期管理，本质上就是变更管理。每一阶段都要有明确的输入、输出、责任人和自动化检查。我见过太多团队在「创建」阶段花大量时间画流程图，却在「废弃」阶段草草了事——结果就是历史包袱越来越重。

记住一句话：契约的生命周期，决定了数据治理的成败。从创建到废弃，每一步都要有章可循。