一、数据契约基础：从“口头约定”到“书面合同”

大家好，我是老赵。今天咱们聊聊数据契约。这词儿听起来挺正式，对吧？其实说白了，它就是微服务之间关于数据交换的一份“书面合同”。

我在2018年刚接触微服务改造那会儿，团队里全是“口头约定”。A服务给B服务传个JSON，字段名改了也不通知，B服务半夜就挂了。嗯，那场面，运维小哥的头发就是这么没的。

数据契约要解决的，就是这种混乱。它把服务间的数据依赖关系，用明确的、可验证的方式固定下来。

1.1 什么是数据契约？

数据契约，是数据生产者（Provider）和数据消费者（Consumer）之间达成的、关于数据交换格式、质量、时效和语义的正式约定。

你可以把它想象成API文档的“升级版”。API文档只告诉你接口长什么样，数据契约还告诉你：

• 这个字段到底是什么意思（语义）
• 数据多久必须到达（SLA）
• 字段能不能为空（Schema约束）

1.2 数据契约的三大组成要素

我个人习惯把数据契约拆成三块：Schema、SLA、语义。缺一个，这契约就不完整。

1.2.1 Schema：数据的“骨架”

Schema定义了数据的结构和类型。它是最基础、最容易理解的部分。

举个例子，一个用户信息的Schema可能是这样的：

{
  "type": "object",
  "properties": {
    "userId": { "type": "string", "format": "uuid" },
    "userName": { "type": "string", "maxLength": 50 },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 },
    "email": { "type": "string", "format": "email" }
  },
  "required": ["userId", "userName"]
}

这里规定了：userId必须是UUID格式，userName不能超过50个字符，age必须在0-150之间。消费者拿到数据，直接按这个结构解析就行。

1.2.2 SLA：数据的“时效与质量承诺”

SLA（Service Level Agreement）是数据契约里最容易被人忽略的部分。它回答了几个关键问题：

• 时效性：数据多久更新一次？是实时、准实时（秒级）、还是T+1？
• 可用性：数据接口的可用性是多少？99.9%还是99.99%？
• 完整性：数据必须100%到达，还是允许一定比例的丢失？
• 一致性：是最终一致性还是强一致性？

我建议用表格把SLA指标列清楚：

SLA指标	描述	典型值
数据延迟	从数据产生到消费者可见的时间差	≤ 5秒（准实时）
接口可用性	数据接口在统计周期内的正常响应比例	≥ 99.95%
数据完整性	成功传输的数据记录占总记录的比例	≥ 99.99%
数据新鲜度	数据仓库中数据与源系统的时间差	≤ 1小时（离线场景）

1.2.3 语义：数据的“灵魂”

语义是最难定义、也最容易出问题的部分。它规定了数据字段的业务含义。

举个例子，“订单状态”这个字段：

• 生产者A：0=待支付，1=已支付，2=已发货
• 生产者B：0=已创建，1=待支付，2=支付中，3=已支付

你看，同样是“0”，含义完全不同。这就是语义冲突。

语义契约通常包含：

• 字段定义：每个字段的业务含义，最好有业务术语表
• 枚举值映射：所有枚举值的业务含义，不能有歧义
• 单位说明：金额是分还是元？时间是UTC还是本地时间？
• 空值含义：null代表“未设置”还是“数据不存在”？

1.3 数据契约在微服务中的作用

你想想看，微服务架构最大的痛点是什么？是服务之间的耦合。数据契约就是解耦的利器。

它的作用主要体现在三个方面：

1. 解耦生产者和消费者：双方只依赖契约，不依赖对方的内部实现。生产者改了内部表结构，只要契约不变，消费者就不需要改代码。
2. 提供兼容性保障：契约定义了哪些变更向后兼容，哪些不兼容。比如新增一个可选字段是兼容的，删除一个必填字段就是不兼容的。
3. 作为测试和验证的依据：消费者可以基于契约生成Mock数据，进行独立测试。生产者的变更也可以通过契约验证，确保不破坏现有消费者。

下面这张图，展示了数据契约在微服务架构中的核心位置：

你看，生产者只负责发布契约，消费者只负责订阅契约。双方不直接依赖，而是通过契约这个“中间层”进行交互。这样，只要契约不变，任何一方的内部改动都不会影响对方。