原文链接https://codefresh.io/docker-tutorial/how-to-test-microservice-integration-with-pact/

挑战：微服务集成测试

迁移到微服务对测试我们的系统产生了新的挑战。理论上每个微服务都应该是隔离的并可以独立操作。但在实践中一个服务如果没有其他部分通常没什么用。另一方面 - 为一个服务拉起整个系统的拓扑进行测试抵消了微服务期望带来的模块化和封装。

挑战在于如何检验与其他服务集成后没有问题。我们希望越早越好。而且我们不想将复杂的生产环境重现一遍。一般来说这种检验是集成功能测试或叫端到端测试。但实际是当我们的系统越来越复杂 - 端到端带来的收益越少。大量的相互依赖导致误报和很长的执行周期。使得测试变得很难管理与调试。

这甚至有一个测试金字塔理论（最初由Mike Cohn在他的著作‘Succeeding with Agile’中提到）讲述了为了优化你的投入，你需要更少的高层次的端到端测试，写更多的低层次的单元测试。

请阅读本文并看看Codefresh(https://codefresh.io/codefresh-signup/?utmsource=Blog&utmmedium=Post&utm_campaign=pactT)，他是对于Docker最好的CI。

单元测试很好！但在它带来的所有收益中 - 他们对测试与其他服务的集成没什么作用。

那我们怎样保证每个服务团队可以独立的迭代但又能保证整体系统的健康呢？我们如何实现持续交付，小批量生产，快速反馈，而又不会在每次变更时引起服务出问题呢？

一个可能的答案是Consumer-Driven Contract(CDC) 测试。这种测试策略是基于一种多年前就定义的服务进化模式。它现在分布式系统变得更常见后变得更适合了。

Consumer-Driven Contracts：

我尝试简单解释一下。 Consumer-Driven Contracts实际就是面向服务与服务关系的合约。意思就是不想以前是provider提供方定义接口与服务级别是什么样(同事消费者consumer尽量适配) - 现在消费者来领舞。每个消费者来定义它期望服务提供方需要交付与需要检查的。这就将集成的责任转移到服务提供方。

那就变成以下流程：在商务合约上者通常描述成‘将消费者放在第一位’ 或‘倾听你的客户’。因为想要提供最好的服务我们需要尽量做到客户期望和需要的。而不是我们假设对的事。

当讨论微服务进化时 - 在那种每个服务都有一个独立团队开发的大型企业里尤其重要。有时这些团队也可能在不同的地理位置和区域。这影响了即时沟通和让业务功能进化更有挑战性。

合约测试框架

消费者驱动合约当然可以通过投资团队间的沟通与协作来管理。也可以通过使用结构化的系列化格式如protobuf，thrift或messagepack消息体来解决。但如果要管理一个定义好的流程 - 最好使用框架，尤其如果是个开源的。

这种框架已经出现了。这其中最杰出和活跃的是Pact和Spring Cloud Contract。后者只针对使用JVM的项目。而Pact使用Ruby写的但可以支持很多语言，包括Java，Go，Python，Javascript。让它很适合在复杂，多样性的微服务系统中使用。

今天我们会看看如何在两个服务间定义和校验合约。消费者服务是用Python写的。而提供方服务是用Go写的。测试会在我们的CI/CD流程中进行 - 也就是在Codefresh流水线里面。

Pact

所以，Pact怎么工作的？它开始于消费者。

消费者服务的开发写一个测试。测试定义了与提供方的集成。这包括了提供方需要的状态，请求的消息体和期望的结果。基于这个定义Pact建立和运行一个提供方的桩来进行测试。这个测试的输出回事一个或多个json文件，一般是这样的：

{"consumer": {"name": "billy"},"provider": {"name": "bobby"},"interactions": [{"description": "My test","providerState": "User billy exists","request": {"method": "POST","path": "/users/login","headers": {"Content-Type": "application/json",},"body": {"username":"billy","password":"issilly"}},"response": {"status": 200,}},],"metadata": {"pactSpecification": {"version": "2.0.0"}}
}

这就是合约，这就是pact。现在他们被传给服务提供方。也可以被提交给共享的git仓库，或通过Pact Broker应用上传到共享的文件存储。

一旦合约更新过了 - 提供方需要对其进行测试验证是否仍符合要求。它通过使用共享的pact文件运行它自己的校验测试而不是真实版本的服务。如果所有的交互是符合预期的并测试通过了 - 我们就可以继续了。如果不 - 提供方的开发需要通知消费方的开发。然后，他们可以一起分析什么导致了合约的失败。

文章来自微信平台「麦芽面包」微信公众号「darkjune_think」转载请注明。微信扫一扫关注公众号。

如何用Pact进行微服务集成测试相关推荐

如何用Pact进行微服务集成测试(二)
我们的例子: 我们会测试2个小服务的集成. 服务provider是我们在jenkins plugin例子里使用过的相同的服务.它叫'bringon',是用Go写的一个是用mongoDB的保存软件构建信 ...
51信用卡微服务集成测试自动化探索
1 简介 51信用卡管家自2015年开始实施微服务架构,是业界较早尝试微服务架构的技术团队,整个团队有幸见证了微服务从最初的个服务试点到全面铺开的过程.架构的演变也催生了自动化测试框架和策略的演变,测 ...
51信用卡的微服务集成测试自动化探索
51信用卡自2015年开始实施微服务架构,是业界较早尝试微服务架构的技术团队,整个团队有幸见证了微服务从最初的几个服务试点到全面铺开的过程.架构的演变也催生了自动化测试框架和策略的演变,测试团队通过持 ...
dbnetlib不存在或拒绝访问_idou老师教你学Istio 16：如何用 Istio 实现微服务间的访问控制...
本文由华为云容器Istio团队撰稿,未经允许谢绝转载. 摘要使用 Istio 可以很方便地实现微服务间的访问控制.本文演示了使用 Denier 适配器和黑白名单两种方法. 使用场景有时需要对微服务 ...
python微服务监控_如何用zabbix监控微服务
配置zabbix_agent.conf,通过shell脚本weifuwu.sh读取/etc/zabbix/scripts/tmp.txt内容,作为自定义zabbix键值获取到的内容返回给zabbix ...
微服务架构及其最重要的 10 个设计模式！
来源:Java日知录软件设计模式是解决软件设计中常见问题的通用.可复用的解决方案.设计模式让我们可以分享通用词汇并使用经实战检验的方案,以免重复造轮子.现在,我将介绍一系列设计模式来实现这些最佳实践 ...
微服务架构最重要的 10 个设计模式！
软件设计模式是解决软件设计中常见问题的通用.可复用的解决方案.设计模式让我们可以分享通用词汇并使用经实战检验的方案,以免重复造轮子.现在,我将介绍一系列设计模式来实现这些最佳实践. 微服务架构的设计模 ...
微服务架构中10个常用的设计模式
从软件开发早期(1960 年代)开始,应对大型软件系统中的复杂性一直是一项令人生畏的任务.多年来为了应对软件系统的复杂性,软件工程师和架构师们做了许多尝试:David Parnas 的模块化和封装 ( ...
微服务架构10个最重要的设计模式
自从软件开发的早期(1960年代)以来,解决大型软件系统中的复杂性一直是一项艰巨的任务.多年来,软件工程师和架构师为解决软件系统的复杂性进行了许多尝试:David Parnas的模块化和信息隐藏(19 ...

如何用Pact进行微服务集成测试

挑战：微服务集成测试

Consumer-Driven Contracts：

合约测试框架

Pact

如何用Pact进行微服务集成测试相关推荐

最新文章

热门文章