云原生全链路性能测试工具深度解析与应用

标签：原生 压测 流量 测试用例 3.2 测试 链路 测试工具

1. 背景

在当今数字化和微服务化时代，系统性能对于用户体验和业务完整性来说至关重要。
随着业务的复杂化，系统会越来越不稳定，同时用户对高效、稳定的服务的期望也会
不断增长。这时全链路性能测试变得愈发必要。
性能测试通常是一种测试实践，用于确定系统在特定工作负载下的响应性和稳定性。
它还可以用于调查、测量、验证或验证系统的其他质量属性，例如可伸缩性、可靠性
和资源使用情况。
全链路性能测试则是在性能测试的基础上，系统性、综合性的测试方法。旨在模拟真
实业务场景下的综合性能压力测试。

2. 产品总体介绍

2.1 当前全链路性能测试的痛点

想要对一个系统进行全链路性能测试，需要满足很多条件。
有些条件是硬性条件，软件无法解决，如：资源依赖问题，需要服务器的支持。数据
管理和隐私问题，需要后端和运维支持。环境一致性，需要架构上能支持。这些硬性
条件，虽然我们有方案并且有其它产品做为支撑，但不是本产品需要解决的。
本产品关注以下测试痛点：
场景建模：业务越复杂，建模真实业务场景就越复杂且困难。想要准确模拟复杂的业
务，并且真实测试到多个系统、服务和数据源，还需要深入理解业务流程以及各种依
赖。
工具和技术选择：合适的工具和技术，是成功测试的关键。市场上有许多不同的工具
和技术，如JMeter、Locust等，这些工具做为简单的压力测试可以满足需求，想要真
实模拟真实业务场景和流量，却是需要更多的专业且复杂的配置或者二次开发，使用
门槛高。
结果分析和解释：全链路性能测试不是一味的往高流量压测，它是需要分析与解释测
试结果的，测试结果分析与解释有助于找到系统的性能瓶颈与根本原因所在。
测试时间和成本：全链路性能测试不是仅仅在高压流量下测试一两分钟的事，它可能
需要耗费大量的时间和资源，特别是在模拟高负载情况下。着需要一定的成本，以获
得适合的测试环境。
持续集成和持续交付：在当前的快速迭代更新的微服务架构体系下，需要持续集成全
链路性能测试，一遍尽早发现系统性能问题并解决它。

2.2 产品如何解决用户痛点

EaseLoad是一款用于在云原生环境中测试微服务网站性能的在线服务。
全面安全: EaseLoad需要在生产环境中进行性能测试。因此，它可以隔离测试流量、
服务、资源、中间件以及测试期间产生的数据，以确保生产环境不会出现混乱，并最
小化性能影响。
零源代码更改：EaseLoad采用非侵入式设计，客户无需更改任何源代码。它易于部署
和运行，没有开发成本。
真实场景模拟：并行模拟大量访问站点的实际场景用户。
简单且可重用的测试用例：测试用例以YAML格式声明，可以在测试产品的生命周期内
的不同工作流中引用和重用。
快速瓶颈识别：利用EaseMonitor的强大功能，EaseLoad的测试引擎本身被设计为一种
服务，向EaseMonitor报告指标、追踪和日志。EaseMonitor报告整个调用路径和可能
的瓶颈

3. 产品介绍

3.1 产品特点

3.1.1 产品亮点

1. 基线测试，挖掘系统最大性能潜力
2. 测试工作流，同步/异步/延时，灵活组织工作流，高保真模拟真实流量
   3.1.2 产品理念
   根据木通原理，系统的能力近观限于最短的那一块木板。而由于分布式IT系统的复杂
   性，对于第一个独产的服务，即使用对单个服务的性能测试，但是易确定服务间调用
   的比例关系，因此不知道那一个服务或节点是短板。另一方面，真实环境的流量特定
   也不易确定，因此对单点服务的压测模型只能进行估计，和真实情况有差距。对于大
   型的IT系统，由于系统的演化，甚至很难分析列举出一个业务服务接口倒底涉及哪些
   后端服务和资源。所以为了测量整个系统的性能特性和瓶颈点，需要实行全链路性能
   测试。
   全链路性能测试应满足如下产品理念：
3. 尽可能的复现真实的流量特点，触发潜在的性能问题
4. 数据安全隔离，保障生产环境安全
5. 实施成本低，部署、运行简单直观，不增加现的开发、测试团队负担
6. 云原生， 满足分布式、弹性伸缩、可管理性及可观没性等云原生特征，并且易
   于和其它云原生组件和服务集成。

3.2 产品的主要功能

前文我们已经阐述，MegaLoad 产品主要为用户解决的痛点，和如何为用户解决这些问
题。我们将在这一章中讨论关于MegaLoad 是通过什么样的产品功能来具体解决用户问
题的

3.2.1 全链路压测先决条件

3.2.1.1 业务特性调研

企业的业务场景会影呼对IT系统的热点。比如同样是电商平台，商超平台不同商家促
销时的订单量差别非常巨大，而物流量可以较平缓发出；外卖平台则不同，不同商家
订单量差别较小，对于物流出库要求是同等的紧急。调查业务场景及期特性非常重
要。主要的调查内容有：

1. 企业给用户提供什么核心服务？（支撑核心商业的服务）
2. 有哪此支撑服务？（用户互动、促销等）
3. 业务流程、业务状态转换关系（订单、特流、业务状态等）

3.2.1.2 压测系统及监控部署

压测系统部署图如下所示：

1. 全链路压测控制台 WEB前端，提供测试用例设计，压测过程控制，报表生成等
   各项用户界面功能。
2. 全链路压测服务 使用“后端服务”，“数据库”和“压测节点”三位一体的轻
   量级服务
   a. 后端服务 通过API提供各项功能的实现。
   b. 数据库 保存全链路压测模拟数据、测试用例，压测过程控制等数据和参
   数，在这里使用了内置的etcd做为存储。
   c. 压测节点 运行压测执行工具的节点，压测工具由代理脚本及开源软件
   (Jmeter、LoadRunner等）组成。压测节点可以水平扩充以提高测试流量
   的吞吐量。
3. 简易监控 可以一键部署到环境的各VM或物理节点。监控该节点或K8s容器。简
   易监控主要基于开源组件Promethues开发，是可选组件，如果待测试系统已经
   有全栈监控，并具备API集成能力，可以不用布署简易监控。
4. 基线测试工具 可以模拟简单的业务处理逻辑，排除复杂的过程，以得到一个理
   想状态的吞吐量数据，分析系统的最大性能潜力。

3.2.2 EaseLoad压测服务Docker安装

3.2.2.1 获取镜像

向megaease团队获取easeload服务的镜像
megaease/easeload:latest
将镜像同步到所有节点

3.2.2.2 添加monitor环境配置

monitor的环境配置有：kafka，域名，用户名，密码
monitor的环境配置是用于监控数据的，如果没有，可以不配置
kafka_address:

• kafka-0.kafka-hs:9093
• kafka-1.kafka-hs:9093
• kafka-2.kafka-hs:9093
  app.mgmt.monitor.endpoint: “ 域名 " a p p . m g m t . a u t h . u s e r n a m e : " {域名}" app.mgmt.auth.username: " 域名"app.mgmt.auth.username:"{monitor的用户名}”
  app.mgmt.auth.password: “ m o n i t o r 的密码 " a p p . m g m t . a u t h . e n d p o i n t : " {monitor的密码}" app.mgmt.auth.endpoint: " monitor的密码"app.mgmt.auth.endpoint:"{域名}”

3.2.2.3 单节点安装

1. 如果不要monitor，直接运行命令
   docker run -it -p 3000:3000 easeload:latest
2. 添加配置和数据目录运行命令
   docker run -it -p 3000:3000 -v ./data:/bin/data -v
   ./config.yaml:/bin/config/config.yaml easeload:latest
   a. /bin/data目录easeload的数据目录
   b. /bin/config/config.yaml文件是easeload的配置文件
3. 使用docker-compose.yml文件启动
   version: “2”
   services:
   easeload:
   container_name: easeload
   image: megaease/easeload:latest
   hostname: easeload
   ports:

• “3000:3000”
  volumes:
• ./config.yaml:/bin/config/config.yaml
• ./data:/bin/data

3.2.2.4 集群安装

1. 所有节点创建安装目录和配置文件
   a. 创建easeload目录
   b. 在easeload目录下创建data目录
   c. 在复制项目底下的server/config/config.yaml文件到easeload目录
2. 修改配置文件
   a. 第一台修改配置
   cluster-client-url: http://0.0.0.0:2379
   cluster-peer-url: http://0.0.0.0:2380
   cluster-join-urls:
   b. 其他节点修改配置, 添加cluster-join-urls配置，配上第一台配置的
   cluster-peer-url
   cluster-client-url: http://0.0.0.0:2379
   cluster-peer-url: http://0.0.0.0:2380
   cluster-join-urls: http://${第一台IP}:2380
3. 使用docker-compose.yml启动
   version: “2”
   services:
   easeload:
   container_name: easeload
   image: megaease/easeload:latest
   hostname: easeload
   network_mode: “host”
   volumes:

• ./config.yaml:/bin/config/config.yaml
• ./data:/bin/data
  验证安装
  安装的所有节点IP：
  

在前端中输入任何一个节点的endpoint访问前端，创建的所有数据，在其他节点上都
可以看得到。

3.2.3 工作空间

3.2.3.1 定义

在全链路压力测试前，我们会对业务进行调研（说明请看 3.2.1.1），每个业务都会
有各自的流程。在真实工作中，不同的业务往往由不同的人负责。我们把不同的业务
拆分成不同的工作空间，这样可以做到互不影响。

3.2.3.2 配置文件下载和导入

每个工作空间对应着一个配置文件。这意味着，你将可以独立下载整个工作空间的配
置文件，然后拿到其它环境的压测系统导入，重用整个配置。
整个工作空间的配置，包含如下类型：

1. 测试用例
2. 变量/环境
3. 工作流
4. 流量模型
   工作空间还包含了非配置信息：正在运行的任务和报表

3.2.3.3 总揽

在总揽中可以看到整个工作空间的各个数据的统计情况。下载配置/导入配置 也在总
揽中进行。

3.2.4 测试用例

在“测试用例”中，你可以进行测试用例管理，环境管理和变量管理。

1. 左侧是“测试用例列表”
2. 右侧是具体的“测试用例详情”
3. 右上方是“环境管理”和“变量管理”

3.2.4.1 测试用例列表

“测试用例列表”列出了整个工作空间的可用“测试用例”。每个工作空间中会有不
同归类，如：登录归为一类，具体业务归为一类，登出归为一类，以两层树形结构展
示。

1. 第一层是归类的类别，以文件夹的形式体现出来
2. 第二层是该类别下的具体“测试用例”

3.2.4.2 测试用例详情

“测试用例”是整个压力测试的基础，目前只支持http/https请求。一个测试用例包
含很多配置，具体内容如下：
注⚠：在可填的值里，有部分可以直接填写，且可以带上变量，以两个大括号表示引
用变量。如：/v1/{{username}}，这部分变量以“字符串+{{变量}}”表示![

3.2.4.3 环境管理

在实际系统部署里，为了实现高可用和快速交付，同一套系统，往往会有多个环境，
如：性能测试环境，开发环境，生产环境。生产环境甚至可能会有蓝绿部署等等区
别。环境管理就是为了解决相同业务场景，不同环境之间测试脚本重用做的一个功
能。
环境管理的主要表现是管理变量，不同的环境有着相同的变量，但是变量的值应该配
置对应环境的值。在默认的情况下，会有一个default。在环境管理时，想要添加一个
环境，必须从另一个环境复制一份过来。后面如果添加/删除变量，系统统一给所有环
境添加/删除。

3.2.4.4 变量管理

变量是用于存储和表示数据的名称。在测试用例中可以用于存储运行时数据，或者根
据不同环境存储不同的数据。

变量的类型目前有四个：ENDPOINT, LOCAL, RANGE, LIST

3.2.5 工作流

如果说“测试用例”是编辑业务的接口请求的话，那么“工作流”就是利用“测试用
例”编排成一个业务流程。一个“工作空间”可以有多个工作

工作流有5个类型：TESTREF, WAIT, PARALLEL, LOOP, TRIGGER

3.2.5.1 工作流中的“请求动作”

在“工作流”中，如果用TESTREF类型引用了测试用例，可以在旁边进行编辑，编辑里
最右边有个“请求动作”。

在实际业务流程中，会有一些判断逻辑存在，这时候就需要要用到请求判断。比如：
获取列表，如果列表没有某个名称为XXX的数据，就创建，然后查看数据，如果有则直
接查看数据。

“请求判断”有5种数据类型进行判断：StatusCode，Cookie, Header, BodyJson，
Timeout。前面四种数据类型StatusCode，Cookie, Header, BodyJson的判断与“测
试用例详情”的检查器一致，详情看 3.2.4.2 。最有一种Timeout类型不用填写判断
条件。
除了“请求判断”之外，如果判断命中，会有5个“动作”：goto，and，or，abort，
ignore

3.2.6 流量模型

在全链路压测中，流量模型用于控制在压测过程中的用户并发量。
全链路性能测试和单点测试最大的区别是测试流量必需模拟真实的业务场景。比如对
于同样的服务接口，对于“2小时完成100万订单”的性能目标，模拟50万用户每人下2
单和模拟100用户，每人下10000单，压测结果差异会很大，产生的瓶颈点很可能会不
同。只有贴合真实的用户场景，才能确认哪些问题是值得解决的。
注⚠：后面为了行文的简洁和方便，我们把MegaLoad中的用户并发量简称为参与者，
用户并发量和参与者，在本文中可以通用的替换，表达的是一个含义。

在流量模型详情中，总共有四行
第一行有三个选项：

1. 选择流量模型，控制用户流量模拟的方式。有六种流量模型：Load Test、Soak
   Test、Stress Test、 BreakPoint Test、Spike Test、Custom。
2. 选择流量模型需要运行的工作流
3. 选择流量模型的最大并发总控制
   第二行有两个填写框：
4. http/https请求的最大连接数
5. http请求的超时时间
   第三行是流量模型的具体参数和流量模拟图，不同的流量模型会有不同的参数，表现
   出来的模拟图也会不一样。
   第四行是断开控制，当瞒著配置时，全链路压力测试的流量就会进行一定调整，不一
   样的流量模型调整策略不一样，详情请看各自的流量模型。断开控制可以判断两种数
   据：响应时间和异常率。
   响应时间有5个指标：P50,P90,P95,P99,P999
   异常率有4个指标：M1ErrorPercent，M5ErrorPercent，M15ErrorPercent，
   ErrorPercent
   指标的含义如下：
   

3.2.6.1 流量模型Load/Soak/Stress

典型的专业负载测试流量模型有三种：负载测试（Load Test），浸泡式测试（Soak
Test），极限压力测试（Stress Test）。
这三种流量模型的参数是一样的，只是在实际应用中具体的“负载量”和“测试时
长”不一样。
参数有三个：

1. 最大持续时间：该流量模型的压测时长
2. 上升期：并发的参与者从0增加到最多参与者所需的时间
3. 最多参与者：该流量模型所需要负载的“参与者”
   

3.2.6.2 流量模型BreakPoint

模拟最大负载探测测试流量。
参数有四个：

1. 最大持续时间：该流量模型的压测时长
2. 基础参与者：该流量模型压测的第一阶段的“参与者”，从第二个阶段开始，
   除非遇到断开控制，否者每个阶段的“参与者”是上一个阶段的2倍。
3. 阶段上升：两个阶段之间，从前一个阶段上升到下一个阶段的“参与者”所需
   的时间
4. 阶段：每个阶段持续的时间
   
   在典型的BreakPoint的算法里，每个阶段的“参与者”都是上一个阶段的2倍，但是为
   了更好的得到测试效果，我们对BreakPoint的算法进行了优化。当出现断开控制后，
   不是立即停止，而是将“参与者”回复到上一个阶段的“参与者”数量再跑一个阶段
   ，如果验证系统能够正常回复（测试系统的自我修复能力），下一个阶段会以当前节
   点为基础，以1.1倍的涨幅进行压测，直到结束或者再次数显断开控制。尽可能压测出
   最接近系统的极限值。

3.2.6.3 流量模型Spike

模拟流量爆发测试流量。
参数有六个：

1. 最大持续时间：该流量模型的压测时长
2. 一般参与者：正常流量下的“参与者”
3. 一般上升：并发的“参与者”从0增加到一般“参与者”所需的时间
4. 峰值时间：爆发大量“参与者”的持续时间
5. 峰值最低间隔：爆发大量“参与者”的间隔时间最低值
6. 峰值最高间隔：爆发大量“参与者”的间隔时间最大值
   两次流量爆发的间隔时间取“峰值最低间隔”和“峰值最高间隔”之间的随机数。
   
   在典型的Spike的算法里，每个阶段“爆发期”的“参与者”都是上一个阶段“爆发
   期”的2倍，从一般参与者开始计算。但是为了更好的得到测试效果，我们和
   BreakPoint类似，对Spike的算法进行了优化。当“爆发期”出现断开控制后，不是立
   即停止，而是恢复到正常流量继续压测，如果验证系统能够正常回复（测试系统的自我修复能力），用最后一次没有出现断开控制的“爆发期”的“参与者”数，乘以1.1
   继续运行压力测试。后面“爆发期”的“参与者”调整为上一个阶段“爆发期”的1.1
   倍，直到结束或者再次数显断开控制。尽可能压测出最接近系统的极限值。

3.2.6.4 流量模型Custom

自定义自己想要的流量模型。该流量模型以阶段的方式进行配置。
参数有“最大持续时间”：该流量模型的压测时长，和阶段参数。
阶段参数有3个：

1. 阶段：配置该阶段的持续时间
2. 上升：并发的参与者从上一阶段变化成下一阶段所需的时间
3. 参与者：该阶段所需要负载的“参与者”
   
   这种流量模型在遇到断开控制后，直接停止压测。

3.2.7 任务管理

任务是用户定义好测试用例、测试流程和测试流量模型之后，最后执行压力测试的动
作行为。点击流量模型中的“运行”按钮就会运行任务。在任务里面可以看到以往运
行过的任务和报告。

在报告中，如果压测的流量模型有阶段性的比变化如：BreakPoint，会把每个阶段的
压测指标报告出来

4. 市场情况

4.1 成功案例

4.1.1 客户介绍

理想团队，成立于1999年04月，属于XX全资子公司。公司致力于中国IT产业的发展，
定位于电信与IT产业融合的ICT服务商形象，为社会信息化、企业信息化和家庭信息化
提供专业化的应用集成服务。

4.1.2 客户面临的问题

1.缺乏监控体系，缺乏全套全链路监控体系，无法从整体设计监控公司产品，故障难
以追踪和解决，无法满足 SLA 和 SLA，业务决策的困难，影响竞争力
2.缺乏全链路压测，性能问题暴露，无法应对高峰期，服务不稳定，用户满意度下降
，无法预测性能瓶颈，投入资源浪费

4.1.3 客户得到的收益

1.监控的能力方向
主要通过探针，监控服务等手段让用户获得一个高性能，高可用，快速发布的全链路
监控系统。
2.压测能力方向
通过EaseLoad让用户获得一个高性能，高可用，可重用的全链路压测体系。

4.2 竞品调研

目前国内主流的云厂商也会提供全链路压力测试服务，但是只有华为云和阿里云提供
了正常的服务，相对与这些竞品来说，EaseLoad提供更人性化的前端和更全面的流量
模型，华为云只能自定义流量，阿里云只能用Load Test和BreakPoint Test。

5. 结论

Easeload 是一款云原生全链路性能测试工具，和云原生生产环境无缝集成。Easeload
不仅开箱即用的压测能力水平扩缩容，还和生产环境的云设施集成，快速、高效的完
成性能测试，发现网站潜在的性能瓶劲和改进点。
它包括以下主要功能：

1. 测试用例管理：提供了全套http/https请求的测试用例管理，响应校验和变量
   提取

2. 环境管理：提供不同环境变量之间无缝切换的能力

3. 变量管理：提供多种满足业务需求的变量类型

4. 业务流程管理：利用测试用例编排业务流程的能力，同时可以通过逻辑判断执
   行不同流程

5. 压力流量模型管理：提供专业的主流压力流量模型

6. 压力测试报告：提供专业的压力测试报告

实现以下目标：

1. 全面性能评估： 全链路压力测试旨在全面评估系统的性能，包括前端用户体
   验、后端服务响应、数据库交互等各个环节的性能指标。
2. 端到端稳定性验证： 通过模拟真实的用户操作流程，全链路压力测试可以验证
   整个系统在高负载情况下的稳定性，以确保不会因为某个环节的问题导致整个
   系统崩溃或失效。
3. 负载均衡检验： 全链路压力测试可以帮助评估系统在负载情况下的负载均衡策
   略是否有效，以及是否能够合理地分配负载以保证各个服务的正常运行。
4. 系统拓扑分析： 通过全链路压力测试，可以深入了解系统内各个环节之间的关
   系和影响，帮助发现可能的性能瓶颈和问题点。
5. 资源耗尽检测： 全链路压力测试可以揭示系统在高负载下是否会出现资源耗尽
   问题，如内存泄漏、数据库连接池耗尽等。
6. 弱点和风险暴露： 通过全链路压力测试，可以发现系统在不同负载下的弱点和
   潜在的风险，以及可能导致性能下降或故障的问题。
7. 应对突发情况： 在全链路压力测试中，可以模拟突发情况，如网络异常、服务
   器故障等，以验证系统在异常情况下的表现和恢复能力。
8. 业务容量规划： 全链路压力测试可以帮助确定系统能够支持的最大用户数、并
   发访问量以及交易处理量，以便进行容量规划。
9. 性能优化和改进： 通过全链路压力测试，可以获得系统在不同负载下的性能数
   据，从而指导性能优化和系统改进。

标签：原生,压测,流量,测试用例,3.2,测试,链路,测试工具
From： https://blog.csdn.net/2301_79159642/article/details/143625119