Devops微服务架构下具有代码级穿透能力的精准测试

微服务是Devops场景下热门的开发框架,在大型项目中被广泛采用。它把一个大型的单个应用程序和服务拆分为数十个的支持微服务,独立部署、互相隔离,通过扩展组件来处理功能瓶颈问题,比传统的应用程序更能有效利用计算资源。微服务之间无需关心对方的模型,它通过事先约定好的接口进行数据流转,使业务可以高效响应市场变化。但微服务一个明显的表象就是随着服务的增多,传统的测试模式受到很大制约,无法有效进行下去,威胁到整体系统质量。所有J2EE代码层白盒采集工具都无法区分覆盖和具体功能的对应关系,只能以后台模式“笼统“的采集一个阶段的总的覆盖,无法满足对于Devops下对于故障定位、深度测试分析以及敏捷发布算法的要求。
 
  星云测试(www.teststars.cc)发布分布式微服务精准测试解决方案,是目前市场上唯一可达到在复杂分布式系统中,跨多个服务器进行代码白盒级分析、实现请求分布式追踪的测试平台。其中产品内的穿透模块,可以支持各种主流微服务通信架构。例如httpclient,springcloud微服务架构、阿里dubbo微服务架构,以及消息队列,将并发访问场景下跨多个服务多组代码逻辑分离并重建追踪出来。实现业务逻辑的代码在开发层面通过微服务离散后,在测试阶段则可以反向复原整个完整代码执行视图。精准测试里面的穿线概念(Threadingtest)增加了第三层含义,即针对的分布式服务的穿透能力。
 

 
  微服务场景下,一个完整请求会跨多个计算(服务)节点,而对于以节点为剖面的各种测试和监控手段都变得不那么直接和有效。一个请求链路的失效和性能故障等问题,从一个计算节点剖面去分析是很困难的,因为在一个计算节点剖面上的数据是混合型数据,而无法区分这里面的数据来自于那个请求。原始的方法无法将一个调用链路上的所有信息完整的重新刻画出来。业界流行的APM技术可以某种程度实现这种调用链路分析,该项技术主要用于监控,体现的数据是组件级的,而且为了性能考虑还经常抽取样本,无法达到测试要求的代码级的分析。
 
  微服务采用的“分而治之”的策略,而精准测试对于微服务的测试和运营管控上采用的是“概览全局”的策略。精准测试在编译阶段,重新将微服务所有模块视为一个完整项目,统一编译和插装,经过插装后的代码重新部署到原有节点上。在微服务的启动过程中附加上分布式追踪所需要的agent启动,即可完成微服务场景下达到测试用例级的代码全调用路径分析。由于微服务有多个程序模块,星云测试平台支持模块级增量编译模式,即每次编译替换某一个模块就可以生成一个新的版本,而无需将所有微服务模块全新编译。
 
  穿透和分布式追踪的原理,这里要重点将以下星云测试JavaEE应用服务器agent的能力。agent提供了一个虚拟jsp的技术,通过agent启动的被测应用,都附加了一个虚拟jsp,地址类似于http://www.appundertest.com/teststars.jsp。  访问这个页面可以用来指本机的用户,一般这个设置和精准测试示波器的登录用户需要一致。设置完成后,对被测试应用的请求将附加上一个用户标识的cookie信息,这个信息会在微服务的多层架构中一直携带和穿透。例如从浏览器发起的一个带着用户标识信息的请求,到了应用服务的处理线程中,这个线程执行的所有代码将附加上这个用户信息,如果应用在向后调用其他的节点的服务,则这个用户信息会继续向后传递,直到最后的执行节点。由于每个节点的代码均有精准测试系统插装的代码,会自动的向用户请求发起端的示波器回馈数据,那么就可以实现将整个调用链路上的代码逻辑发送给示波器。示波器收到数据后,将动态数据和代码编译阶段的程序静态数据结合起来,即可展示全链路的程序调用路径信息。从另外角度,当微服务系统有多个请求同时并行的时候,那么每个示波器收到的是自己对应的请求代码的全链路执行情况,而其他示波器用户和其他普通用户的数据则不会被收录进来。
 

 上图是一个spring cloud微服务架构下两个节点的调用图。当从第一层入口组件访问后,入口组件向后调用下一层节点的时候,后一层节点的运行线程自动取到了前一层节点的用户信息,并且加入到了第二层节点的运行线程控件。这样,通过精准测试示波器(登录用户标识和请求标识一致)就可以收到两个节点的数据。实现多个用户同时访问分布式应用的时候,不同用户出发的数据自动分离,路由到对应的示波器,最终对应到用例上。

原文地址:http://blog.51cto.com/13883507/2170265

时间: 2024-09-27 19:13:38

Devops微服务架构下具有代码级穿透能力的精准测试的相关文章

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

微服务架构下分布式事务方案

1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开发框架也非常多,比较著名的有Dubbo.SpringCloud.thrift .grpc等. 2 微服务落地存在的问题

微服务架构下的数据一致性:可靠事件模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:可靠事件模式 在<微服务架构下的数据一致性:概念及相关模式>中介绍了在微服务中实现数据一致性的三种方式,包括可靠事件模式.业务补偿模式.TCC模式.本文重点说一下可靠事件投递. 1. 可靠事件模式 可靠事件模式属于事件驱动架构,微服务完成操作后向消息代理发布事件,关联的微服务从消息代理订阅到该事件从而完成相应的业务操作,关键在于可靠事件投递和避免事件重复消费. 可靠事件投递有两个特性:1)每个服务原子性的完

微服务架构下的身份认证

从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案. 单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大.单体应用体系下,应用是一个整体,一般针对所有的请求都会进行权限校验.请求一般会通过一个

微服务架构下业务单机QPS跑不上去应从哪些角度分析

这是做应用运维老生常谈的一个事儿,经常做,今天把他总结一下. 不管什么性质的业务,吞吐量的本质是木桶原理,能跑多大量取决于木桶最短的那个板,脑袋里是不是立刻可以出现木桶的那个模型,哈哈!!换句话说,当有能力提高短板的高度时,业务的吞吐量就会有所上升,但同样有个边际效应,经过多次的优化后,当再次提高短板的成本非常非常大,而付出后提高的量很低时,那就不要较劲了,直接加服务器吧. 言归正传,先解释一下单机QPS跑不上去的现象,具体表现就是高过一个点后错误率增加.时延增大,很显然遇到短板了,那么这个短板

微服务架构下静态数据通用缓存机制

在分布式系统中,特别是最近很火的微服务架构下,有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案,这篇文章将结合一些实际的研发经验,尝试理清其中存在的关键问题以及探寻通用的解决之道. 什么是静态数据 这里静态数据是指不经常发生变化或者变化频率比较低的数据,比如车型库.用户基本信息.车辆基本信息等,车型库这种可能每个月会更新一次,用户和车辆基本信息的变化来源于用户注册.修改,这个操作的频率相对也是比较低的. 另外这类数据的另一个特点是要求准确率和实时性都比较高,不能出现丢失.错误,以及

微服务架构下,解决数据一致性问题的实践

随着业务的快速发展,应用单体架构暴露出代码可维护性差.容错率低.测试难度大和敏捷交付能力差等诸多问题,微服务应运而生.微服务的诞生一方面解决了上述问题,但是另一方面却引入新的问题,其中主要问题之一就是:如何保证微服务间的业务数据一致性.本文将通过一个商品采购的业务,来看看在Dubbo的微服务架构下,如何通过Fescar来保障业务的数据一致性.本文所述的例子中,Dubbo 和 Fescar 的注册配置服务中心均使用 Nacos.Fescar 0.2.1+ 开始支持 Nacos 注册配置服务中心.业

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

微服务架构下的数据一致性:概念及相关模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:概念及相关模式 从2014年开始,微服务逐渐进入大家的实现,被认为是下一代实现信息化的有效手段.设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性.但是在微服务架构中,这两种方式都不是最好的选择. 1. 使用本地事务和分布式事务保证一致性 在传统的单击应用中,最简单.最直接.最普遍的会使用一个关系型数据库,通过关系型数据库的事务保证数据的一致性.这种事务有四个基