关于微服务和契约测试的一些介绍

上一篇 / 下一篇  2018-04-25 10:47:56 / 个人分类:博为峰原创技术文章

一.关于微服务的介绍

   2016年有一个调查统计,抽样调查统计两千家企业里,30%在使用微服务,15%在实验开发和测试微服务架构24%在学习微服务准备转型只有剩下30%的企业没有使用微服务。

   下面简单介绍一下微服务

1.微服务是什么

    根据单独的功能,建立一个单独的服务,这些服务之间的关系是独立的,通过API之间的相互通信来联系构建庞大复杂的业务,就是微服务架构。

2.微服务的

   1)根据业务模块划分服务种类,把整个应用拆成对应单个功能的微小服务,进行开发和维护。

    2)每个服务可以独立部署并且互相隔离保证了每一个服务的独立性和灵活性。

    3)通过轻量的API调用通讯协议和简单的数据结构服务,来进行服务之间的通信,一般是http+json的方式。服务之间不再关注对方如何实现,只要遵守项目开始定义的接口进行数据通信,实现了较低的系统耦合度,方便开发和维护升级。

    4)每个系统都要考虑实现高可用性和方便维护升级特性。

3.再说说微服务的缺点:

    1)运维成本相对于传统单一架构

    2)DevOpsDevelopmentOperations)是必

    3)代码可能会有重复

    4)分布式系统相对单一系统复杂

4.微服务开发框架

    1Spring Boot

    利用Spring Boot开发的便捷简化分布式系统的基础设施,比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。

    2Spring Cloud:Spring Cloud是一个系列框架的合集,能够构建一整套完整的微服务架构技术生态。

    3Dubbo:Dubbo是由阿里巴巴开源的分布式服务化治理框架,国内许多公司在应用

    4Dropwizard:国内现在使用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(服务提供者端)

总结

    微服务和契约测试都在大型的应用中被广泛使用,对于测试人员,掌握微服务和契约测试的原理,并且用契约测试方法对系统做测试,是技术的必要,更是参与大型项目的必须技能。


TAG:

 

评分:0

我来说两句

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 33210
  • 日志数: 43
  • 建立时间: 2018-01-25
  • 更新时间: 2018-11-09

RSS订阅

Open Toolbar