一.关于微服务的介绍
2016年有一个调查、统计,在抽样调查、统计的两千家企业里,30%在使用微服务,15%在实验开发和测试微服务架构,24%在学习微服务准备转型,只有剩下30%的企业没有使用微服务。
下面,简单介绍一下微服务
1.微服务是什么
根据单独的功能,建立一个个单独的服务,这些服务之间的关系是独立的,并通过API之间的相互通信来联系,构建庞大复杂的业务,这就是微服务架构。
2.微服务的优点
1)根据业务模块划分服务种类,把整个应用拆成对应单个功能的微小服务,进行开发和维护。
2)每个服务可以独立部署并且互相隔离,保证了每一个服务的独立性和灵活性。
3)通过轻量的API调用(通讯协议和简单的数据结构)服务,来进行服务之间的通信,一般是http+json的方式。服务之间不再关注对方如何实现,只要遵守项目开始定义的接口进行数据通信,实现了较低的系统耦合度,方便开发和维护升级。
4)每个系统都要考虑实现高可用性和方便维护升级特性。
3.再说说微服务的缺点:
1)运维成本相对于传统单一架构高
2)DevOps(Development和Operations的组合)是必须的
3)代码可能会有重复
4)分布式系统相对单一系统复杂
4.微服务开发框架
1)Spring Boot
利用Spring Boot开发的便捷简化分布式系统的基础设施,比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。
2)Spring Cloud:Spring Cloud是一个系列框架的合集,能够构建一整套完整的微服务架构技术生态。
3)Dubbo:Dubbo是由阿里巴巴开源的分布式服务化治理框架,国内许多公司有在应用。
4)Dropwizard:国内现在使用Dropwizard不多,但是与SpringBoot相比,Dropwizard在轻量化上更便捷。
5)一些基于.net的开发框架
1. .NET Core
2.Service Fabric
3.Surging
4.Microdot Framework
6. 一些Node.js相关微服务框架
1.Seneca
2.Hapi/ restify/ LoopBack
7. Go相关微服务框架
Go-Kit/Goa/Dubbogo
虽然微服务有这些缺点,但是瑕不掩瑜,微服务架构在复杂系统的开发上还是优势巨大的。微服务已经成为很多大型互联网公司的选择,是一个应用十分广泛的技术。
二.关于契约测试的介绍
1. 什么是契约测试
契约测试最开始的概念由Martin Fowler提出,它又被称之为:消费者驱动的契约测试(Consumer Driven Contracts)。这里的契约是指软件系统中各个服务间交互的数据标准格式,更多的指消费端和提供端之间交互的数据接口的格式。
对这种结构进行概括,称之为消费者合同。当提供者接受消费者表达的合理预期时,它就会签订消费者合同。
2.消费者合同具有以下特征
1)开放和不完整性
消费者合同对于系统可用的业务功能而言是公开和不完整的。他们根据消费者对提供者合同的期望,表达了系统业务功能能力的一个子集。
2)多重和非权威性
消费者合同与服务消费者的数量成正比,而且对于提供者的全部合同义务而言,每份合同都是非权威的。从消费者到提供者的关系的非权威性,是将面向服务的体系结构与分布式应用程序体系结构区分开来的关键特征之一,即消费者和提供者的服务都是可以根据具体情况改变的。
3)有限的稳定性和不变性,消费者合同只有在特定时间段/地点有效。
3. 契约测试的特点
1)测试接口和接口之间的正确性
2)验证服务层提供的数据是否是消费端所需要的
3)将本来需要在集成测试中体现的问题前移,更早的发现问题
4)更快速的验证消费端和提供端之间交互的基本正确性
4. 契约测试的应用
1)为什么要使用契约测试(Pact)
传统方式下,微服务的集成以及测试都是一件复杂的事情。其实在微服务概念还没有出现之前,在SOA流行的时候,就有人提出了消费者驱动契约(Consumer Driven Contract,CDC)的概念。微服务流行后,服务的集成和集成测试成了不得不解决问题,于是出现了基于消费者驱动契约的测试思想。
2)开发过程中存在的问题
联调成本过高。双方开发到可以联调后才可以放在同一个环境上进行测试,不仅要同时把握双方的进度,还会造成资源和时间上的浪费。
对于接口的变动把控相当困难。由于接口变动是普遍存在的,尤其对于调用关系复杂的接口,一旦发生变动,如果没有一套机制进行控制,验证的成本巨大,更不必说持续集成了。
5.契约测试能给我们带来什么
1)通过使用契约测试,接口调用双方协商接口后就可以并行开发,并且在开发过程中利用契约进行预集成测试,不用等到联调再来集成拉通接口。一旦**,在保证质量的前提下,联调的成本可以显著降低。
2)因为契约的存在,让接口的变动有迹可循,即使变动也可以确保变动的安全性和准确性。在构建的过程中来完成接口的联调测试,接口变动的验证测试。如果规范整个开发流程,正确使用契约测试,就可以真正实现持续集成,来达到任何时候构建出来的程序都是真正可发布的状态。
6.介绍一款契约测试常用的工具Pact
1)Pact开发术语
Consumer:微服务接口的调用者
Provider:微服务接口的提供者
契约:是由consumer端和provider端共同定义的接口规范,包括接口访问的路径,输入和输出数据。在具体的实施中,是由consumer端生成的一个json文件,并存放在pact broker(保存契约文件的服务器)上。
2)接口双方的命名
这里的接口命名在后续写测试用例的时候需要使用。
3)代码实现(包括开发代码和测试代码)
4)构建过程
构建的过程会跑测试用例,所以可以自动完成契约文件的生成,上传broker,契约文件的验证等一系列过程。要先构建consumer,用来确保先生成契约文件,以免provider的验证的时候取不到。provider构建时,会启动真实的服务来进行验证。完成各自构建,联调在出包的时候就已经完成,意味着构建后出的包就基本是一个可发布的状态。
一个完整Pact的test文件包括consumer(消费者端)和provider(服务提供者端)。
总结
微服务和契约测试都在大型的应用中被广泛使用,对于测试人员,掌握微服务和契约测试的原理,并且用契约测试方法对系统做测试,是技术的必要,更是参与大型项目的必须技能。