共计 2682 个字符，预计需要花费 7 分钟才能阅读完成。
摘要：本期和大家简略聊聊在服务交互场景下应用服务契约的重要性，以及契约治理的必要性，最初简略介绍了下契约测试。
1、服务交互带来的问题
在上一篇文章中，咱们零碎的列举了 DevOps 各个流程中罕用的测试技术。
接着上一篇的图，咱们简略画下一个零碎利用的外部服务的调用关系：交付一个大的零碎可能波及到多家 ISV 进行集成，每家 ISV 本人又存在前端、网关、后端等多个微服务，且各自 ISV 或者服务均存在本人的 SE、开发和测试人员，都有本人绝对独立的版本演进，服务之间存在调用关系。
思考一下，这会带来哪些问题呢？
- 通过接口文档或者表格治理接口内容，服务交互单方、多方频繁对接交互调用的接口信息，频繁刷新，剪一直、理还乱，让人解体。
- 服务依赖导致必须期待底层服务先开发实现能力联调对接和集成测试，效率低下；
- 此时如果发现被调用服务接口不满足要求、接口缺失、接口无奈联调等问题时，须要从新期待版本联调，造成资源和工夫上的节约；
- 服务都在不停的向前演进，调用服务与被调用服务的版本会随着内部需要减少、Bug 批改、代码重构等等因素而导致接口产生变更，接口调用服务往往无奈及时获取接口变动而导致整体业务受损。
2、服务契约 – 服务交互问题的一种解决方案
如何解决服务间纷纷简单的联调问题呢？本章节咱们来聊一聊契约与契约测试。
顾明思义，契约就是一份由单方或多方独特订立的、具备强制听从性的信用文书。契约测试全称消费者驱动契约测试(Consumer Driven Contracts Testing)，最早见于 2011 年。“消费者驱动契约测试”名称中分明形容了“契约”、“谁提供契约”的问题。
一般来说，是消费者 (Consumer) 把本人对输出和输入的数据结构、性能曾经并发性等冀望以约定的格局通知服务提供者(Provider)，服务提供者签订批准，这就造成了一份服务契约，服务提供者对所有消费者的契约取并集进行服务能力开发，造成本人服务的对外承诺或者 schema。
模型如下：生产端服务 A、B、C 调用拜访服务提供端服务 A，生产端服务 A、C 服务提供端服务 B。服务提供端会依据生产端冀望别离生成 1 份契约文件，以满足生产端的诉求。
服务之间通过契约交互会带来哪些益处呢？
1）、应用契约，接口调用单方的对接、问题定界等都有“法律依据”，问题不会扯不清、道不明、来回甩锅。
2）、应用契约，就确定了交付单方的接口模式和入口与进口冀望，生产端和服务提供端能够并行开发服务，并且在开发过程中就利用契约进行预集成测试，不须要期待联调再来集成测试，大幅升高联调沟通老本。
3）、因为契约的存在，能够整体看到服务生产端的原有接口应用状况，让接口的变动有迹可循，即便变动也能够确保变动的安全性和准确性。
4）、生产端也能通过契约的变动获知服务端的 API 变动状况
3、契约交互的问题
在第二章节咱们看到契约的根本流程。在失常的契约测试流程中，契约由消费者提供，服务者听从，依据消费者的提供的契约实现服务测试。然而，大家思考下这种模式存在什么样的问题？咱们思考下一下的问题：
- 单方的契约有了，然而口头协定空口无凭，契约如何存储，以及如何能力防篡改？
- 邮件交互、会议纪要难以保护？
- 在敏感市场，消费者提供的契约是否合乎失常诉求与合规？
- 在多 ISV 服务商、多部门合作的利用零碎，消费者频繁刷新契约要求怎么办？
- 失常须要刷新契约怎么解决、契约怎么会退或者回溯？
- 生产端驱动，会不会造成生产端势力过大，话语权过重，倒逼服务提供端，最终也会导致整个零碎不三不四？
从下面的几个问题能够看出，因为契约很重要，那么设计和管控契约也就显得更加重要。
4、契约设计与契约治理的必要性
交互的问题并不像设想的那边简略，为了解决契约设计和管控的问题，咱们新增一个设计管控和契约治理的环节。
设计管控环节相似于议会这种机沟通和决策机构，用于调解和扫视契约的合理性、合规性和更改的必要性，且对于多消费者的契约做合并解决。
契约治理环节，解决契约存储、拜访认证和不可篡改性、可追溯性和可回退等问题。这样就防止了后面所说的问题，当然就义了肯定了灵活性，然而在大型零碎中，这样行为是值得的。
咱们看下，消费者的契约的生成和下载过程就变成如下流程：
同时，如果服务端要被动变更契约，也要失去生产端和扫视委员会的通过，审核通过合入后，消费者和服务提供者从契约治理平台下载契约应用。流程变得如下：
5、契约测试
后面的章节，咱们花了较多篇幅介绍了契约的生成和契约在服务交互过程中的作用以及重要性，那么对契约的测试也很重要。上面咱们简略聊聊如何对契约进行测试。
契约测试不是组件测试，契约测试和外围也是通过 API 来进行。每个消费者只会关注本人的冀望是否失去满足，所以只须要依据本人提供的、已审核通过的契约文件进行测试。而服务提供端则须要满足所有消费者的诉求，须要拿所有消费者的契约做测试，所有契约须要测试通过。如下所示：
因为理论开发中，契约签订之后，Consumer 和 Provider 是同步开发，所以 Consumer 和 Provider 也是别离测试。个别的契约测试过程如下：
Consumer 服务的测试环境，须要应用契约进行 Mock Provider 服务进行构建：
Provider 服务的测试环境，则须要依据和 Consumer 签订的契约文件生成的契约测试用例进行测试，通过测试契约用例验证本人提供的接口是否满足消费者须要，接口是否有变更。一旦接口产生变更，契约测试用例会执行失败。
后面所述，契约是消费者 (Consumer) 把本人对输出和输入的数据结构、性能曾经并发性等冀望以约定的格局通知服务提供者(Provider)，服务提供者签订批准后造成的，那边契约测试的次要内容也便是这几个方面：
反对契约测试的工具有 Pact、Pacto、Janus、CloudTest，Swagger 也能满足局部要求。一般来说，业界应用 Pact 工具的较多，简略说下 Pact 工具的过程，具体 Pact 用法请参照官网：
Consumer 测试：
Provider 测试：
咱们也补充下 Pact 工具的优缺点
6、微服务下的服务契约样例
契约个别是一个 yaml 文件或者 json 文件的格局，咱们以 CSE 微服务的契约为展现样例：
结语：本期和大家简略聊聊在服务交互场景下应用服务契约的重要性，曾经契约治理的必要性，最初简略介绍了下契约测试。契约测试工具用法的领导文档较多，本篇没有做开展。DevOps 下，契约测试也是须要集成到流水线中，欢送下来持续交换。
本文分享自华为云社区《聊聊 DevOps 下的测试技术（2）聊聊契约与契约测试》，原文作者：柳哥说。
点击关注，第一工夫理解华为云陈腐技术~
