正文
它们是消费和提供服务彼此如何交互的一种描述方式，但在这里，消费服务是通信的驱动方。
这种方式有几个关键的好处。第一，它们可以使服务独立地部署。你不再需要拥有一个具备所有服务的质保环境了，不再需要用它将所有服务作为一个整体来运行以去测试应用的运转了。你不需要做长长的、脆弱的、昂贵的流程测试以确保服务可以启动和通信。
另一个关键好处是，这种契约可以由一个服务独立地生成。假想一下，你需要一个用于提供服务新端点。你知道它大概应该是什么样的，以及新的消费者将需要的确切数据。
那么就可以为提供者团队生成消费者驱动契约让他们去实现了。你可以放心，只要提供团队遵循这个消费者驱动契约，那么所有东西都可以正常工作。这种方式非常适用于分布式团队。这份消费者驱动契约形成之后，消费团队和提供团队就可以同时去忙自己的代码了，这时，整个世界是分离开来的。
最后，消费者驱动契约更微妙的地方在于，它们能让你验证正在做的东西。从提供者的视角你不能 100% 地确保所提供的服务实际会满足消费者的需要。通过从消费者的视角出发，你可以定义应提供什么，以及应采用什么样的格式。
同时，消费服务使用任何数据都不应需要任何额外的逻辑或转换，因为契约已经从消费者的视角定义了格式。
消费者驱动契约不是银弹. 有许多东西消费者驱动契约都未涉及。首先，它们不是业务逻辑的测试。这些应由服务的单元测试来覆盖。
如果你打算改动一个端点潜在的业务逻辑，但不改变其返回的数据格式，那么就应该没问题，因为消费服务不必担心数据是如何创建或交付的。如果消费服务介意数据是如何形成的，那么就说明业务边界未得到适当地定义。然而，就所有事情一样，变更时团队间的沟通还是必要的。
消费者驱动契约也不是服务间的服务层协议（SLA）。它们不声明一项服务应有多久的有效期，每分钟要能处理多少请求。
还要注意的是，消费者驱动契约不能验证外部 API 服务响应。例如，消费者驱动契约不能验证谷歌地图。如果外部来源决定改变他们的格式，那这是人家的权力。和第三方合作伙伴保持沟通总是件有益无害的事，需要时就做好迁移的准备。
Rightmove 是英国最大的房地产门户网站，每天的请求数超过 5 千万。我们帮人们找到他们的梦想家园，无论它是古老的农舍，还是流行的伦敦公寓。在 Rightmove ，我们有许多已经集成和部署的微服务。这就产生了大量的挑战和协调，从而促使我们使用了消费者驱动契约。
在 Rightmove 内部使用了消费者驱动契约之后，我们提出了一个愿望清单，这样我们就可以更容易地分享我们出于任何原因所做的任何事情了。
消费者驱动契约愿望清单是：
消费者驱动契约是一个概念，所以要用的话就需要一个已定义的、共同约定的格式。其本质，无非就是这样的一种陈述：“如果我发送这种请求，预期得到这种结果”。于是，轮到 Pact Foundation 出面了。他们创建了一种用于描述请求和响应的一致的 JSON 格式。在 Pact，契约被称为条约（pact），它们是简单的 JSON 文件，包含请求和预期的响应。如果你的服务发送一个 HTTP GET 请求到 /user/125sb45sd，预期得到 200 Ok 返回码和一个 JSON 报文，以及其他预期的报头。
