如何用消费者驱动的合同测试微服务？

许多软件公司决定以分布式方式构建其应用程序。 这种方法提供了高可用性，并且从长远来看提高了开发速度。 设计分布式系统的最常见的架构模式是微服务。 微服务体系结构是关于将应用程序拆分为小型独立服务，每个独立服务在整个系统中都扮演着独立的角色。

想象您的客户想要建立一份工作公告。 该产品必须允许用户下达工作邀请，并向他们收取一小笔上市费用。 它还必须发送几种电子邮件通知。 实际上，它不是一个单一的应用程序，而是一个网页以及iPhone和Android应用程序。 首先需要确定我们将选择哪种架构。

整体架构的好处

整体方法促进了项目的开始。 无需定义复杂的集成测试和部署过程。 一切都被简化为一项服务。

优点：

• 单一代码库-易于开发（至少在一开始）。
• 无需验证与其他服务的集成，因为它们不存在。
• 相对简单的部署过程-只需部署一项服务。

缺点：

• 单点故障-如果一个应用程序关闭，则整个服务都关闭。
• 维护复杂性随时间而增长。
• 难以适应新技术。 通常，它需要从头开始重写应用程序。

微服务的好处

微服务比单片架构（单个应用程序负责整个系统）具有许多优势。 最重要的是：

• 没有单点故障。 当一项服务关闭时，用户仍可以使用该应用程序。 其他服务仍在工作。
• 可以扩展单个微服务以增加其容量和可用性。
• 安全性-大多数服务都没有暴露于Internet。
• 每个服务都可以独立于其他服务进行部署。 只要他们不违反API合同。

缺点：

• 建立基础需要投入大量工作。
• 部署过程更加复杂。 某些部署可能需要部署多个服务。
• DevOps上的大量工作。 尤其是在部署中……
• 处理集成测试。

大多数大型应用程序是由数百个开发人员开发的。 这就是为什么将应用程序拆分为较小的服务可以使工作变得更加轻松和快捷的原因。 对于大多数中型和大型应用程序而言，微服务架构是一个不错的选择，尽管最成功的初创公司以单片架构开始了其应用程序，后来又迁移到了微服务。

为职位发布应用程序设计微服务

让我们为作业公告考虑以下架构。 网站和移动应用通过API网关与服务进行通信。 API网关是从Internet访问服务的唯一方法。 服务在内部网络内部相互通信。

假设用户创建了一个新帐户。 他们进入网站，填写表格，然后将请求发送到API网关。 API网关将此请求传递给创建新帐户的用户服务。 创建帐户后，用户服务向电子邮件服务发送请求以发送激活电子邮件。 然后发送一封电子邮件，其中包含用户需要单击以激活其帐户的链接。

如您所见，电子邮件服务无法通过API网关使用。 这是因为只有内部服务才能触发电子邮件通知。

如何处理测试？

微服务始终会遇到测试问题—如何确认所有服务都协同工作？ 直接处理Monolith应用程序的测试。 该应用程序具有单一代码库，并且不依赖任何外部服务。 相反，微服务使所有服务都是分布式的。 它们依赖于来自其他人的信息，这意味着系统架构师必须找到方法来验证服务是否以相同的语言讲话。 通常，他们决定构建一个集成环境，在该环境中启动服务，并由测试人员运行测试。 不幸的是，这种方法非常低效且昂贵。 在我们的情况下，我们需要并行运行六个服务。 请记住，其中一些服务需要运行数据库或其他系统。

尽管增加整个应用程序堆栈所需的大量硬件，还是要考虑进行测试。 让我们假设预算对您的客户来说不是问题。 您拥有必要的硬件，并拥有一些DevOps来构建和维护集成环境。 运行所有测试需要花费很多时间……

…有时候很严重…

我们的某些服务看起来像运行cron和批处理作业。 您可以想象几乎不可能预测执行它们所需的时间，这意味着依赖于那些工作的测试可能很不稳定。

如果您的测试依赖cron作业处理的数据，并且将在cron作业完成之前尝试确认测试，该怎么办？ 您的测试失败，您需要再次重新运行测试…

…经过几次尝试后，您的构建就变成了绿色。 您在此上浪费了3个小时，但现在您可以合并更改并提供功能…

好极了！ 生活很好！

…不幸的是，有人在两分钟前合并了某些内容，因此您需要合并这些更改并再次运行所有测试…

消费者驱动的合同

不要在所有服务之间运行集成测试，而要摆脱它们。 所有服务都通过RESTful API进行通信。 这意味着，如果我们在API之间定义了紧密的“合同”，则无需启动整个平台。 验证其他服务的要求满足就足够了。

示例代码可以在Github上找到 。

怎么运行的？

有两个对等方：消费者（客户端）和提供者（服务）。 作为开发人员，我们希望确认它们彼此兼容； 这就是为什么我们在消费者方定义API合同的原因。 合同必须在服务提供商上执行。

使用什么工具？

在本文中，我使用的是Pact 。 我还没有找到其他可以与Pact竞争的产品。 Pact支持多种语言 ，并且被Atlassian等知名公司使用。

您可能还需要考虑Dredd 。

什么是消费者？

使用者是希望从其他服务（例如，Web前端或消息接收端点）接收某些数据的客户端。 它们定义了对端点的要求，例如HTTP标头，状态代码，有效负载和响应。 合同是在单元测试运行时生成的。 在所有测试成功之后，pact将创建包含有关HTTP请求信息的json文件。 这是示例合同：

什么是提供者？

提供程序是提供数据的服务或服务器（例如，服务器上提供客户端所需数据的API或发送消息的服务）。 用于验证与提供者的合同的工具称为Pact Provider Verifier 。 验证程序根据使用者创建的合同运行HTTP请求。 如果服务器响应采用使用者期望的形式，则测试通过。

如果提供者不符合期望，他们就会失败…

请稍等...那么，如何将合同交付给所有同行？

消费者方的所有测试成功后，将创建包含合同的json文件。 我们的工作是将它们交付给提供者以验证合同。 有几种方法可以做到这一点：

• 一个Git存储库，用于存储契约，并使用git子模块将它们包含到每个项目中。 我认为最好的方法是
• 文件系统。
• 契约经纪人。

Pact Broker是用于共享消费者驱动的合同和验证结果的应用程序。 我们可以将合同推到那里，并允许服务提供商下载它们，并对它们进行测试。

DiUS提供了Pact Broker的云版本，因此，也许您可​​以看看并使用它。 在运行自己的Pact Broker时，我看不出太多优势。 最后，这是又一项服务，需要DevOps进行维护。 如果您想自己运行， 这里是Docker镜像 。

我认为将合同存储在单独的git存储库中就足够了。 我个人将在集成管道中创建它们，并在同一集成作业内的服务提供商上运行测试， 例如此处的集成管道 。

为什么不昂首阔步？

Swagger是用于记录API的定义格式。 它通过映射所有资源和相关操作来创建用于开发和使用API​​的接口。 人们（通过网站）和机器（通过yaml和json文件）可以理解输出。 不幸的是，Swagger并不是要用于测试。 Swagger生成的模拟服务器不验证请求有效负载，验证由前端处理。

这并不意味着您完全不应该使用Swagger，因此强烈建议您使用它。 如果您使用Microservics，则很有可能它们是由许多团队开发并由其他团队（有时是外部团队）使用的。 将文档链接到您的API可以加快开发速度，因为开发人员无需弄清楚如何使用端点。 他们可以阅读并在文档页面上尝试。

您可能需要阅读更多有关Swagger Mock Validator的信息 ； 该工具可让您根据Swagger文件验证合同。

摘要

测试微服务是一个复杂的问题。 没有神奇的子弹，也没有一套可以在任何情况下轻松使用的规则。 我写这篇文章是为了向您展示我所服务的团队是如何决定解决这个问题的。

如果您对以消费者为主导的合同感兴趣，我强烈建议您观看Atlassian的 Mauri Edo和Ben Sayers的演讲。

我决定将所有代码保留在我的Github上 ，因此文章更易于阅读。

如果您有任何问题或建议，请写评论。

您可以通过Medium和Twitter与我联系。

From: https://hackernoon.com/how-to-test-microservices-with-consumer-driven-contracts-9bf5c2c05349