背景

日常开发过程中，项目的接口通常由服务提供方约定和提供，微服务模式下接口被多个消费者调用更是常态，那么提供方接口的变更如何快速、高效、无遗漏的通知给消费者呢？另外，当一个service同时被多个使用者调用，如何保证对service的修改可以让其它所有使用者造成的影响都能被感知到？这些问题契约可以给你答案。另外，微服务模式下，接口是非常重要的手段，它在实际的项目中帮助验证微服务之间的协同和交互，大幅降低成本和提高效率方面提供了很大帮助，可以说接口是业务功能前置的助推器。因此，这里对这两种手段进行介绍。

接口和契约所处的阶段

在实际的工作中，结合随行付的实际情况我们对自动化金字塔原理进行了定制，加入契约自动化内容，形成如下新版自动化金字塔结构。

由图可知，一个项目的过程，从项目推进的维度，首先进行单元，其次接口自动化、契约，很后UI自动化和手工。

微服务模式下如何开展接口

接口属于集成范畴，他是单元的扩展和延续。它主要的关注点是内部接口功能实现是否完整，比如说内部逻辑是不是正常，异常处理是不是正确。它是单元和契约的过渡阶段，它是项目单个代码逻辑很终串联形成有价值业务逻辑的桥梁。因此，其作用举足轻重。随行付开展接口，采用的思路是规范和方法先行，其次是工具选择、人员培训，然后是实施和过程优化，很后常态化持续提效和质量保证的过程。

接口规范化要求

接口的质量保证和过程的流程化需要通过规范和方法进行指导和约束。我们定制了如下要求（部分内容）：

需求存在新增接口或者接口变更时，要求进行新增接口案例的编写或存量接口案例的维护；需求涉及到的存量接口需要进行回归；接口覆盖率要求达到100%；需求结束前至少进行一轮接口回归，且回归通过率达到100%

流程规范涉及从需求提出、脚本编写、执行到报告的各个过程。

接口文档。接口文档是接口案例设计的依据，接口文档的全面性和准确性决定了接口范围的全面性和接口结果的正确性、有效性。随行付采用swagger进行接口文档管理。接口用例设计。根据接口文档设计接口案例，接口案例通过接口平台进行编写，且需要满足不重不漏原则。接口用例评审。根据项目实际情况，接口案例编写完成后，需组织相关干系人进行案例评审，记录并发送会议纪要。接口用例执行。需求结束前接口案例至少在环境中执行了一次回归，要求案例执行通过率达到100%缺陷管理和报告。脚本纳入回归体系，定时回归，持续保障接口的质量，以及接口质量的持续和及时反馈。

脚本命名规范和编写规范如下（部分内容）：

接口命名要求：采用“接口名称_接口描述”进行命名，用于定义唯一接口。方法命名要求：采用“方法名_描述”进行命名，用于定义唯一方法。案例命名要求：采用“序号_场景操作_期望结果”进行命名，用于定义唯一案例。【强制】每个接口案例都必须包含至少一个断言；【强制】对于json格式的报文，接口入参和断言响应的预期值需要使用严格的json格式；【强制】swagger脚本导入到接口平台时，需要导入.json文件，且文件内容为无BOM的UTF-8编码；【强制】数据初始化和断言的sql必须带where条件，且能唯一定位到期望的数据；【强制】数据库回退的sql必须带where条件，且能唯一定位到需要回退的数据；【强制】影响公共表（如：T_BAP_CDE_BNK表）或者其他组数据库表（如：资金组）的sql，在数据初始化、回退、接口影响的数据回退、断言回退时必须严格审查；【强制】数据库断言sql中的where条件的主键组合需要放到前面，用于断言失败时快速定位问题；接口用例设计要求

为了保证接口的质量，需要进行全面的接口，因此在涉及接口用例时需要依赖方法，因此我们总结了接口用例的设计要求，如下图所示。

接口工具

接口过程提效、过程自动化需要依赖自动化工具，武器不好很难打胜仗。经过调研，市面上很多接口自动化工具均无法满足所有的要求，因此我们自研了接口自动化平台。自动化平台具有如下能力：

案例自动生成。http/https接口案例自动化生成和导入。过程集中可视化管理。通过将自动化过程web化实现了自动化计划、自动化用例编写、自动化用例执行、自动化用例管理和自动化报告管理各个过程的可视化。模拟性能场景。自动化实现了通过接口案例模拟性能场景的能力。通过使用平台中提供的接口案例，进行并行执行模拟性能场景。多协议多报文类型支持。支持http/https协议、dubbo协议、socket协议、rabbitMQ协议等协议的自动化，并支持对协议的扩展。同时支持xml、json、sop、8583等多种报文类型以及报文类型的扩展。资产有效积累。自动化调度执行和邮件发送。自动化执行通过定时对案例进行调度执行，可对指定的构建版本对应的案例进行自动化的分批、定时调度执行并邮件发送报告。系统质量的可视化反馈。通过对自动化案例的执行结果统计，分析出系统的质量趋势，做到系统质量的持续化反馈。通过根因分析，统计系统问题的根本原因的比例，更有针对性的解决质量问题。

通过接口持续运行1年多的持续运营，随行付核心业务接口基本实现接口用例全覆盖，且均纳入到定期回归过程，持续为接口的质量保驾护航。

微服务模式下如何开展契约契约的价值

契约分两种类型，一种是消费者驱动，一种是提供者驱动。其中很常用的，是消费者驱动的契约（Consumer-Driven Contract Test，简称 CDC）。核心思想是从消费者业务实现的角度出发，由消费者端定义需要的数据格式以及交互细节，生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证该实现结果是否正确。对于基于Restful API的微服务来说，它的契约就是指 API 的请求和响应的规则。 如下图所示：

对于请求，包括请求 URL 及参数，请求头，请求内容等；对于响应，包括状态码，响应头，响应内容等。对于元数据，指对消费者与提供者间一次协作过程的描述。譬如消费者/提供者的名称、上下文及场景描述等。

那么契约能给微服务带来什么价值呢？文章开头已经提到了契约的一部分价值，即接口变更快速通知，servise修改的快速感知。除此之外，它还带来下列价值：

降低服务集成的难度。把服务集成这个过程分解成了更细的单元和接口，它从消费者的需求为出发点，把消费者的需求作为用例驱动实现一份契约，然后验证提供者端的功能。开发并行，提高开发效率。契约隔离了消费者和提供者，双方可以并行开展工作，开发过程中就利用契约进行预集成，不用等到联调再来集成调通接口，一旦成熟，在保证质量的前提下，联调的成本可以减低到几乎为0。确保变动的安全性和准确性。只要有变化，契约即可不错的时间发现，保证安全和对接的准确性。作为Mock server为消费者提供Mock服务。集成为服务者提供

微服务下如何开展契约

随行付采用在Spring Cloud Contract开展契约。其核心流程包括2步：

对消费者的业务逻辑进行验证时，先对其期望的响应做模拟提供者（Mock）；并将请求（消费者）-响应（基于模拟提供者）的协作过程，记录为契约；通过契约，对提供者进行回放，保证提供者所提供的内容满足消费者的期望。

下面用一个简单的例子说明设计契约的方法。这个例子中，一个微服务提供了一个包含三个字段（“IP”、“name”和“password”）的资源，供三个消费者微服务使用。这三个微服务分别使用这个资源中的不同部分。消费者 A 使用其中的 IP 和 name 这两个字段。因此，脚本中将只验证来自提供者的资源中是否正确包含这两个字段，而不需要验证 password 字段。消费者 B 使用 IP 和 password 字段，而不需要验证 name 字段。消费者 C 则需要确认资源中包含了所有这三个字段。现在，如果提供者需要将 name 分为姓（first name）和名（last name），那么就需要去掉原有的 name 字段，加入新的 first name 字段和 last name 字段。这时执行契约，就会发现消费者 A 和 C 的用例就会失败。用例 B 则不受影响。这意味着消费者 A 和 C 服务的代码需要修改，以兼容更新之后的提供者。修改之后，还需要对契约内容进行更新。

下面以一个例子介绍如何使用Spring Cloud Contract开展契约的。

Spring Cloud Contract契约是用基于Groovy的DSL定义的，下面是一个契约的代码段

package contracts

org.springframework.cloud.contract.spec.Contract. ** ke {

request {

method 'PUT'

url '/fraudcheck'

body([

"client.id": $(regex('[0-9]{10}')),

loanAmount: 99999

])

headers {

contentType('application/json')

}

}

response {

status OK()

body([

fraudCheckStatus: "FRAUD",

"rejection.reason": "Amount too high"

])

headers {

contentType('application/json')

}

}

}

服务方-server (HTTP) / producer (Messaging) 端增加Spring Cloud Contract Verifier的gralde插件，它用于解析契约文件生成。生成的命令。

./gradlew generateContractTests

下面是自动生成的脚本

@Test

public void validate_shouldMarkClientAsFraud() throws Exception {

//given:

MockMvcRequestSpecification request = given()

.header("Content-Type", "application/vnd.fraud.v1+json")

.body("{"client.id":"","loanAmount":99999}");

//when:

ResponseOptions response = given().spec(request)

.put("/fraudcheck");

//then:

assertThat(response.statusCode()).isEqualTo(200);

assertThat(response.header("Content-Type")). ** tches("application/vnd.fraud.v1.json.*");

//and:

DocumentContext parsedJson = JsonPath.parse(response.getBody().asString());

assertThatJson(parsedJson).field("['fraudCheckStatus']"). ** tches("[A-Z]{5}");

assertThatJson(parsedJson).field("['rejection.reason']").isEqualTo("Amount too high");

}

这个一个标准的JUnit,用RestAssured来启动Spring的webApplicationContext。

@Before

public void setup() {

RestAssuredMockMvc.webAppContextSetup(webApplicationContext);

}

调用方-在服务方通过命令生成Stub服务的Jar包

./gradlew verifierStubsJar

Spring Cloud Contract Stub Runner在集成中通过运行WireMock实例或者消息路由模拟真实的服务。 因此在运行之前，需要将依赖加入到gralde中,当然可以把他加到私服仓库中。

spring-cloud-starter-contract-stub-runner

对于调用方,Spring Cloud Contract提供了StubRunner来简化Stub的使用。现在可以使用@AutoConfigureStubRunner注解.为了SpringCloud Contract Stub Runner运行stubs注解中增加了group-id和artifact-id，举例如下：

@RunWith(SpringRunner.class)

@SpringBootTest(webEnvironment=WebEnvironment.NONE)

@AutoConfigureStubRunner(ids = {"cn.vbill.service:test-client-stubs:1.5.0-SNAPSHOT:stubs:6565"},

stubsMode = StubRunnerProperties.StubsMode.LOCAL)

public class LoanApplicationServiceTests {

......

}

注解AutoConfigureStubRunner，里面设置了下载Stub Jar包的私库地址以及包的完整 ID，很后的6565就是指定Stub运行的本地端口。的时候访问Stub端口，就会根据契约返回内容。

由于随行付微服务是基于spring cloud技术栈，因此采用spring cloud contract进行微服务下的契约使得过程更流畅，更顺利，同时Spring Cloud Contract和SpringBoot以及 Junit的集成更简单方便。相信随着spring cloud contract版本的优化，契约可以做的更好。

总结

本篇分别从微服务模式下如何开展接口自动化，契约的价值以及如何开展契约角度进行了介绍，微服务模式下，服务间的调用关系复杂，接口和契约是保证服务提高质量的重要手段，因此要充分利用。