发布于 由admin

微服务契约测试接口演进不兼容？Spring Cloud Contract stubs与consumer-driven验证

微服务契约测试：接口演进的兼容性保障

大家好！今天我们来深入探讨微服务架构下，接口演进过程中如何保障兼容性，以及如何利用Spring Cloud Contract (SCC) 中的 stubs 和 Consumer-Driven Contracts (CDC) 验证机制来解决这个问题。

微服务架构的优势在于其独立部署、独立扩展的特性，但也带来了新的挑战，其中一个重要的挑战就是服务之间的依赖关系管理和接口演进的兼容性保障。当 provider 服务的接口发生变更时，如何确保 consumer 服务不受影响，或者能够及时发现并适应这些变更，是我们需要认真考虑的问题。

微服务架构下的接口演进问题

在传统的单体应用中，接口变更通常发生在同一个代码库中，可以通过编译时检查、单元测试等手段来尽早发现问题。但在微服务架构下，provider 和 consumer 服务可能由不同的团队开发和维护，部署周期也可能不同步。这就使得接口变更的影响范围变得难以预测，风险也大大增加。

以下是一些常见的接口演进问题：

  • 字段类型变更: 例如将一个整型字段改为字符串类型。
  • 字段重命名: 将一个字段的名称修改为另一个名称。
  • 字段移除: 删除一个不再使用的字段。
  • 接口地址变更: 修改 API 的 URL 地址。
  • 数据格式变更: 例如从 XML 格式改为 JSON 格式。
  • 新增字段: 在响应中添加新的字段。

这些变更都可能导致 consumer 服务无法正确解析 provider 服务返回的数据，从而引发错误。

契约测试的必要性

为了解决接口演进带来的兼容性问题，我们需要引入契约测试。契约测试是一种验证 provider 服务是否符合 consumer 服务期望的测试方法。其核心思想是，consumer 服务定义一份 "契约"，provider 服务需要根据这份契约来开发和测试。

契约测试的好处在于：

  • 提前发现问题: 在 provider 服务部署之前，就可以通过契约测试发现与 consumer 服务的兼容性问题。
  • 提高开发效率: provider 服务可以根据契约来开发，避免了因接口理解偏差而导致的返工。
  • 增强服务可靠性: 通过持续的契约测试，可以确保 provider 服务在演进过程中始终与 consumer 服务保持兼容。

Consumer-Driven Contracts (CDC) 简介

Consumer-Driven Contracts (CDC) 是一种契约测试的模式，它强调由 consumer 服务来定义契约。

CDC 的基本流程如下：

  1. Consumer 定义契约: consumer 服务定义一份契约，描述其期望的 provider 服务的行为。这个契约通常包括 API 的请求格式、响应格式、以及一些业务规则。
  2. Provider 验证契约: provider 服务根据 consumer 提供的契约来验证自己的实现。如果 provider 服务的实现不符合契约，则测试失败。
  3. 共享契约: 将 consumer 定义的契约共享给 provider 服务。这可以通过多种方式实现，例如使用版本控制系统、共享存储、或者专门的契约管理工具。

Spring Cloud Contract (SCC) 介绍

Spring Cloud Contract (SCC) 是一个用于实现 CDC 的框架。它提供了一套工具和规范，帮助我们轻松地定义、验证和共享契约。

SCC 的核心组件包括：

  • Contract Definition Language (CDL): 一种用于定义契约的领域特定语言 (DSL)。
  • Contract Verifier: 一个用于验证 provider 服务是否符合契约的工具。
  • Stub Runner: 一个用于生成 provider 服务 stub 的工具。stub 是一个模拟的 provider 服务，可以用来在 consumer 服务中进行集成测试。

使用 Spring Cloud Contract 实现契约测试

下面我们通过一个简单的例子来说明如何使用 Spring Cloud Contract 来实现契约测试。

场景:

假设我们有两个服务：

  • Order Service (Provider): 提供订单查询接口。
  • Customer Service (Consumer): 调用 Order Service 查询订单信息。

1. Consumer 定义契约:

在 Customer Service 项目中，我们需要创建一个 contracts 目录，并在该目录下创建契约文件。契约文件使用 Groovy 语法编写，例如 contracts/order-service/order-details.groovy:

import org.springframework.cloud.contract.spec.Contract

Contract.make {
    description "Should return order details for a given order id"
    request {
        method 'GET'
        url '/orders/123'
        headers {
            contentType(applicationJson())
        }
    }
    response {
        status 200
        headers {
            contentType(applicationJson())
        }
        body(
            orderId: 123,
            customerId: 456,
            totalAmount: 100.00
        )
    }
}

这个契约文件描述了 Customer Service 对 Order Service 的期望：

  • 当 Customer Service 向 /orders/123 发送一个 GET 请求时，
  • Order Service 应该返回一个 HTTP 状态码为 200 的响应，
  • 响应的 Content-Type 应该是 application/json，
  • 响应体应该包含 orderId、customerId 和 totalAmount 三个字段。

2. Provider 验证契约:

在 Order Service 项目中，我们需要添加 Spring Cloud Contract 的依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-contract-verifier</artifactId>
    <scope>test</scope>
</dependency>

然后，我们需要创建一个测试类，用于验证 Order Service 是否符合契约。这个测试类需要继承 ContractVerifierBase 类，并实现一个用于设置测试上下文的方法。

import io.restassured.module.mockmvc.RestAssuredMockMvc;
import org.junit.jupiter.api.BeforeEach;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.cloud.contract.verifier.messaging.boot.AutoConfigureMessageVerifier;
import org.springframework.test.annotation.DirtiesContext;
import org.springframework.test.context.TestPropertySource;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)
@DirtiesContext
@AutoConfigureMessageVerifier
@TestPropertySource(properties = "spring.cloud.stream.bindings.output.destination=test-topic")
public class ContractVerifierBase {

    @Autowired
    private WebApplicationContext context;

    @BeforeEach
    public void setup() {
        RestAssuredMockMvc.mockMvc(MockMvcBuilders.webAppContextSetup(context).build());
    }
}

接下来，我们需要创建一个 Controller，用于处理 /orders/{orderId} 请求。

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

import java.util.HashMap;
import java.util.Map;

@RestController
public class OrderController {

    @GetMapping("/orders/{orderId}")
    public Map<String, Object> getOrderDetails(@PathVariable Integer orderId) {
        Map<String, Object> orderDetails = new HashMap<>();
        orderDetails.put("orderId", orderId);
        orderDetails.put("customerId", 456);
        orderDetails.put("totalAmount", 100.00);
        return orderDetails;
    }
}

运行测试类，Spring Cloud Contract Verifier 会自动扫描 contracts 目录下的契约文件，并根据契约文件生成测试用例。如果 Order Service 的实现不符合契约，则测试用例会失败。

3. Stub 生成和 Consumer 使用:

在 Order Service 项目中，我们可以使用 Spring Cloud Contract 的 Stub Runner 来生成 stub。Stub Runner 会根据契约文件生成一个模拟的 Order Service，它可以用来在 Customer Service 中进行集成测试。

为了生成 Stub，我们需要在 Order Service 的 pom.xml 文件中添加以下插件：

<plugin>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
    <version>${spring-cloud-contract.version}</version>
    <extensions>true</extensions>
    <configuration>
        <baseClassForTests>com.example.orderservice.ContractVerifierBase</baseClassForTests>
    </configuration>
</plugin>

运行 mvn package 命令，Spring Cloud Contract Maven 插件会自动生成 stub，并将其打包成一个 JAR 文件。

在 Customer Service 项目中，我们可以使用 Stub Runner 来启动 stub，并使用 stub 来进行集成测试。

首先，我们需要在 Customer Service 的 pom.xml 文件中添加以下依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-contract-stub-runner</artifactId>
    <scope>test</scope>
</dependency>

然后，我们需要在测试类中使用 @AutoConfigureStubRunner 注解来启动 stub。

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.cloud.contract.stubrunner.spring.AutoConfigureStubRunner;
import org.springframework.cloud.contract.stubrunner.spring.StubRunnerProperties;
import org.springframework.web.client.RestTemplate;

import java.util.Map;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
@AutoConfigureStubRunner(ids = "com.example:order-service:+:stubs:8080", stubsMode = StubRunnerProperties.StubsMode.LOCAL)
public class CustomerServiceIntegrationTest {

    @Autowired
    private RestTemplate restTemplate;

    @Test
    public void shouldReturnOrderDetails() {
        Map<String, Object> orderDetails = restTemplate.getForObject("http://localhost:8080/orders/123", Map.class);
        assertThat(orderDetails.get("orderId")).isEqualTo(123);
        assertThat(orderDetails.get("customerId")).isEqualTo(456);
        assertThat(orderDetails.get("totalAmount")).isEqualTo(100.00);
    }
}

@AutoConfigureStubRunner 注解的 ids 属性指定了 stub 的坐标。stubsMode 属性指定了 stub 的运行模式。StubsMode.LOCAL 表示从本地 Maven 仓库加载 stub。

运行测试类，Stub Runner 会自动启动 stub，并将 stub 暴露在 8080 端口。Customer Service 可以通过 RestTemplate 调用 stub，并验证其是否符合预期。

接口演进策略与契约更新

当 provider 服务的接口需要进行演进时，我们需要考虑如何保持与 consumer 服务的兼容性。以下是一些常见的接口演进策略：

  • 兼容性演进: 在 provider 服务的接口中添加新的字段，但保持原有字段的兼容性。
  • 版本控制: 为 provider 服务的接口引入版本号，consumer 服务可以选择使用哪个版本的接口。
  • 并行部署: 同时部署新旧两个版本的 provider 服务，consumer 服务可以逐步迁移到新版本。

无论采用哪种演进策略，都需要更新契约文件，并通知 consumer 服务进行相应的调整。

示例：兼容性演进

假设我们需要在 Order Service 的响应中添加一个 orderDate 字段。

首先，我们需要更新契约文件 contracts/order-service/order-details.groovy：

import org.springframework.cloud.contract.spec.Contract

Contract.make {
    description "Should return order details for a given order id"
    request {
        method 'GET'
        url '/orders/123'
        headers {
            contentType(applicationJson())
        }
    }
    response {
        status 200
        headers {
            contentType(applicationJson())
        }
        body(
            orderId: 123,
            customerId: 456,
            totalAmount: 100.00,
            orderDate: "2023-10-27"
        )
    }
}

然后，我们需要更新 OrderController：

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

import java.util.HashMap;
import java.util.Map;

@RestController
public class OrderController {

    @GetMapping("/orders/{orderId}")
    public Map<String, Object> getOrderDetails(@PathVariable Integer orderId) {
        Map<String, Object> orderDetails = new HashMap<>();
        orderDetails.put("orderId", orderId);
        orderDetails.put("customerId", 456);
        orderDetails.put("totalAmount", 100.00);
        orderDetails.put("orderDate", "2023-10-27");
        return orderDetails;
    }
}

最后，我们需要重新运行契约测试，确保 Order Service 的实现符合新的契约。

如果 Customer Service 不需要使用 orderDate 字段，则它可以忽略这个字段。如果 Customer Service 需要使用 orderDate 字段，则它需要更新自己的代码来解析这个字段。

Spring Cloud Contract 的高级特性

除了基本的契约验证和 stub 生成功能外，Spring Cloud Contract 还提供了一些高级特性，例如：

  • Message-Driven Contracts: 用于测试基于消息队列的服务的契约。
  • Contract DSL Extensions: 可以自定义 Contract DSL，以支持更复杂的契约定义。
  • Custom Contract Verifier: 可以自定义 Contract Verifier，以支持更复杂的契约验证逻辑。

契约测试的最佳实践

以下是一些契约测试的最佳实践：

  • 尽早开始: 在项目初期就应该引入契约测试，尽早发现潜在的兼容性问题。
  • 保持契约的简洁性: 契约应该只包含 consumer 服务真正需要的字段和行为。
  • 自动化契约测试: 将契约测试集成到 CI/CD 流程中，确保每次代码变更都会自动运行契约测试。
  • 定期更新契约: 当 consumer 服务的需求发生变化时，应该及时更新契约。
  • 沟通与协作: provider 和 consumer 团队应该保持密切的沟通与协作，共同维护契约。

总结

我们深入探讨了微服务架构下接口演进的兼容性问题，以及如何利用 Spring Cloud Contract 来实现 Consumer-Driven Contracts。通过契约测试，我们可以提前发现 provider 服务与 consumer 服务的兼容性问题，提高开发效率，增强服务可靠性。

希望今天的分享能够帮助大家更好地理解和应用契约测试，构建更加健壮的微服务架构！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注