2. 核心概念：消费者驱动契约、提供者契约、契约文件格式

在契约测试体系中，消费者驱动契约（Consumer-Driven Contract, CDC）与提供者契约（Provider Contract）构成了双向验证的基石。理解这两者的角色差异以及契约文件的序列化格式，是搭建可靠集成环境回放与事务排查能力的前提。

2.1 消费者驱动契约（CDC）

消费者驱动契约的核心思想是：由服务的调用方（消费者）定义其对提供者 API 的期望，并将这些期望以契约文件的形式发布。提供者必须通过验证这些契约，才能确认自身变更不会破坏已有消费者的兼容性。

2.2 提供者契约

提供者契约是服务提供方对外承诺的 API 行为规范，通常由提供者团队维护。与 CDC 不同，提供者契约更侧重于描述“我能提供什么”，而非“你需要什么”。在 Spring Cloud Contract 生态中，提供者契约常以 Groovy DSL 或 YAML 编写，并直接生成服务端桩代码与测试用例。

2.3 契约文件格式对比

业界主流的契约文件格式包括 Pact 规范与 Spring Cloud Contract 规范。两者在序列化结构、匹配机制、集成生态上存在显著差异。

2.4 Pact 契约文件结构示例

以下是一个典型的 Pact JSON 契约文件片段，展示了消费者定义的 HTTP 交互：

{
  "consumer": { "name": "OrderService" },
  "provider": { "name": "PaymentGateway" },
  "interactions": [
    {
      "description": "a request to process payment",
      "providerState": "user has sufficient balance",
      "request": {
        "method": "POST",
        "path": "/api/payments",
        "headers": { "Content-Type": "application/json" },
        "body": {
          "userId": "user-123",
          "amount": 100.50
        }
      },
      "response": {
        "status": 200,
        "headers": { "Content-Type": "application/json" },
        "body": {
          "transactionId": "txn-abc-456",
          "status": "success"
        },
        "matchingRules": {
          "$.body.transactionId": { "match": "type" }
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": { "version": "4.0" }
  }
}

2.5 Spring Cloud Contract 契约文件示例

Spring Cloud Contract 使用 Groovy DSL 定义契约，以下示例等价于上述 Pact 的交互：

Contract.make {
  description "a request to process payment"
  request {
    method POST()
    url "/api/payments"
    headers {
      contentType applicationJson()
    }
    body([
      userId  : "user-123",
      amount  : 100.50
    ])
  }
  response {
    status OK()
    headers {
      contentType applicationJson()
    }
    body([
      transactionId: "txn-abc-456",
      status       : "success"
    ])
  }
}

2.6 契约驱动流程总览

下图展示了从消费者编写契约到提供者验证的完整闭环，以及契约文件在集成环境回放中的核心位置：

2.7 契约在事务回放中的关键作用

• 期望定义：契约文件精确描述了每次交互的请求结构与期望响应，是回放引擎判断“事务是否通过”的基准。
• 动态匹配：通过匹配规则（如 Pact 的 matchingRules 或 Spring Cloud Contract 的 bodyMatchers），回放引擎可以忽略时间戳、ID 等动态字段的精确差异，聚焦于业务语义。
• 状态回调：提供者状态（Provider State）机制允许回放引擎在重放前预置数据环境，确保事务的上下文一致性。
• 版本追溯：契约文件的版本化存储（如 Pact Broker 的标签与分支）使得回放引擎可以针对特定版本的事务日志进行精确重放，避免版本错配导致的误报。