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

• By TT
• 2018.09.11 
• Devops  微服务  精准测试