1、服务交互带来的问题
我们简单画下一个系统应用的内部服务的调用关系：交付一个大的系统可能涉及到多家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变化情况。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
