考虑稳定性与响应时间的微服务应用性能测试方法

刘恒旺，靳 鑫，吴 琦，孙 歆，孙昌华

（1.安徽继远检验检测技术有限公司，安徽合肥 230097；2.国网浙江省电力有限公司电力科学研究院，浙江杭州 310014）

针对单体应用的缺点，提出了一个与单体应用体系结构完全不同的微服务体系结构[1]。这个应用程序被划分成逻辑、设计和开发的小型服务组，每个服务组只关注其所负责的功能，而不关注其他服务及其内部实现功能[2]。这些服务可以单独部署在平台（服务器）上，也可以在独立进程中运行，进程之间相互隔离，减少了服务间的耦合。添加bug 更改新特性，在此过程中要求重新部署该特性，而微服务架构则将重点放在服务分段上，仅对修改后的服务进行重新部署，并且不会影响其他服务的运行。因此，研究微服务的良好应用性能是非常必要的。以往使用的考虑Spring Cloud 技术的微服务应用性能测试方法[3]，利用Spring Cloud 技术将微服务分为不同独立业务模块，对各个模块进行性能测试分析；考虑Java 开发框架微服务应用性能测试方法[4]，结合Java语言和Web 工具，实现微服务应用性能测试。然而，上述这两种方法受到微服务大量数据影响，处理数据时间需要耗费大量时间，导致性能测试结果不精准，为此，提出了考虑稳定性与响应时间的微服务应用性能测试方法。

1 测试环境与实验场景

1.1 测试环境

考虑稳定性与响应时间的微服务应用性能测试是在Windows10 企业版的64 位操作系统下进行的，测试包为JMeter，开发工具为Maven3.3.9，数据库为MySQL5.7。

1.2 实验场景

使用了前台检测和后台检查的方法，前台测试系统是用户可以查看和操作的基本页面[5]。后台是系统管理页面，需要系统管理员进行验证，得到确认后才能运行[6]。其中前台页面负责执行如下内容：使用者在登录页面输入个人资料，待网页显示已成功登录后，使用者可自行修改文章，并及时回复其他使用者的意见，当使用者进入主页时，填写关键词搜寻想浏览的资讯[7]。

后台页面负责执行如下内容：挑选信誉极好的用户作为管理员，负责删除不良用户、非法文章和所有的评论任务[8]。

系统整体采用的微服务架构如图1 所示。

图1 微服务架构

由图1 可知，微服务组采用MVC 体系结构，每一种服务都拥有独立的数据源[9]，并可以独立运行，不需要其他服务的支持。同时，在微服务组件中注册这些服务，通过不同服务设备之间的相互通信，可以减少服务间的耦合[10]，从而充分提高系统内聚性。

2 微服务应用性能测试

采用JMeter 测试工具，对基于微服务应用的性能进行测试。为了使测试数据尽可能客观，微服务主要实现了业务的功能逻辑代码[11]，微服务系统测试结构如图2 所示。

图2 微服务系统测试结构

2.1 稳定性分析

关于稳定性测试，提出了基于EBPF 的微服务应用系统性能测试方法。在微服务监控节点中进行应用[12]，测试步骤如下：

步骤一：接收群集监控节点发送的控制指令。

步骤二：当该指令的事件或函数被执行时，指令需要包含要收集的数据类型信息，并收集要使用的性能度量信息。

步骤三：当执行事件或功能时，EBPF 工具收集其性能度量参数。

1）该性能度量参数要求获得与微服务相关的所有信息，即网络消息链，在网络消息跟踪中建立网络消息链接[13-14]。由于微服务的类型较多，且每一个微服务对应着不同类型和数量的消息[15]，因此要求分组进行筛选过滤，并选择任何与微服务相关的、受监测的分组来建立链接。另外可以利用微服务对IP 信息进行分组、过滤、筛选等。每个会话都是在过滤出消息后，对消息信息进行分类，并且在同一个会话中将消息分成不同的类别。对每一次会话中的每条消息进行分析（例如消息接收、发送、接收时间等）[16]，构建高效的状态机（如图3 所示），在有限状态机的基础上确定网络消息链接。

从图3 可以看到，有效状态机启动时为初始化状态，接收到报文后处于接收请求状态，此阶段的时间为接收请求时间。在发送请求时，进入发送请求状态，发送到接收时处于结束状态，完成后在循环中进行新的发送和接收任务。也可以假定每个节点都会收到确认信息，所有收到的消息都是嵌套的，如图4 所示。

图3 有效状态机

图4 网络报文链路结构示意图

由图4 可知，当一个节点接收到一条消息时，该节点将其他节点发送的所有消息都保存起来，然后通过嵌套不同的消息间隔关系计算出各个网络的消息连接情况。

2）性能指标参数还包括网络请求处理时间、CPU 利用率、内存利用率以及对日志的读写。在函数执行过程中，将收集和存储函数在每次事件或上下文切换过程中生成的函数调用堆栈，用来判断微服务系统是否存在异常。

步骤四：采用统一格式处理性能指标参数；

步骤五：将性能度量参数发送到集群监控节点，根据应用程序能力度量参数确定微服务的稳定性。

步骤六：每星期测试一次，如果测试结果表明微服务提供商由于网络原因不能被调用，则会导致用户发生“串联故障”，即“雪崩效应”，如图5 所示。

由图5 可知，如果服务节点调用失败，那么系统将立即执行代码，以提高整个系统的可用性，防止基于代码的设置、请求失败和超时等雪崩效应的发生。若服务器模块通过了高压测试，就不会出现系统错误和宕机故障。

图5 雪崩效应

2.2 响应时间分析

响应时间分析需借助JMeter 测试工具，单体中共设置50 个用户，对200 000 个样本进行测试，测试结果如表1 所示。

表1 单体应用

由表1 可知，在200 000 个样本中，平均响应时间为20 ms，误差为0，对这些测试数据进行汇总处理后，得到的应用性能数据如表2 所示。

表2 应用性能数据

由表2 可知，在两种样本数量下，微服务响应时间比单体应用响应时间要低，但吞吐量比单体应用吞吐量要高。产生这种情况的主要原因是微服务具有容错机制，一旦出现无法访问目标的情况，微服务就会立刻终止。因此，无论系统是否出现故障，用户都会得到一个良好的界面，由此也保障用户具有良好的体验效果。

3 测试结果与分析

从稳定性与响应时间两个方面对微服务应用性能进行测试，微服务网络拓扑结构如图6 所示。

图6 微服务网络拓扑结构

由图6 可知，被测试设备被配置为网络服务器端，接收来自客户端的HTTP 请求。被测试设备安装操作系统，Nginx 作为网络服务器，被测试页面分为动态和静态两个页面。为了获取微服务理想情况下的性能指标，使用小于1 kB 的静态页面和1 MB 的动态页面，其吞吐量分别为25～35 kB/s 和42～62 kB/s。

基于微服务网络拓扑结构，分别使用考虑Spring Cloud 技术微服务应用性能测试方法（W1）、考虑Java 开发框架微服务应用性能测试方法（W2）和eBPF 工具微服务应用性能测试方法（W3）对微服务吞吐量进行对比分析，结果如表3 所示。

表3 3种方式吞吐量对比分析

由表3可知，使用基于Spring Cloud技术微服务应用性能测试方法，静态页面下的吞吐量为19～40 kB/s，动态页面下的吞吐量为36～54 kB/s，超出理想情况下的范围；使用基于Java 开发框架微服务应用性能测试方法，静态页面下的吞吐量为22～36 kB/s，动态页面下的吞吐量为38～54 kB/s，超出理想情况下的范围；使用基于eBPF 工具微服务应用性能测试方法，静态页面下的吞吐量为26～33 kB/s，动态页面下的吞吐量为45～59 kB/s，在理想范围内。由此可知，使用该方法时数据传输十分稳定，说明该方法下测得的系统是稳定的，与理想情况一致。

分别使用3 种方法对微服务响应时间进行对比分析，结果如图7 所示。

图7 3种方法响应时间对比分析

由图7 可知，使用基于Spring Cloud 技术微服务应用性能测试方法，最高响应时间为0.014 8 s，最低响应时间为0.011 5 s；使用基于Java 开发框架微服务应用性能测试方法，最高响应时间为0.015 3 s，最低响应时间为0.012 0 s；使用基于eBPF工具微服务应用性能测试方法，最高响应时间为0.016 8 s，最低响应时间为0.012 5 s，与理想情况下数值相差0.000 2 s，由此可知，使用该方法的测试结果较为精准。

4 结束语

微服务是一个细粒度的面向服务架构，具有良好的稳定性，能够高效准确地完成任务。其采用基于域驱动的设计思想，在服务间采用REST 通信机制分别部署微服务，在不同的主机上实现微服务的分布式管理。在EBPF 基础上，利用微服务应用性能测试方法，建立了微服务场景的统一度量标准。该方法便于索引的开发和扩展，具有相对统一的数据结构，可以从内核中获得索引，而且指标粒度越细，系统性能分析的准确度就越高。在未来应用中，应用微服务中的开源容器引擎，用于加速封装、测试和部署，实现服务过程的虚拟化，减少项目部署时间。