有赞全链路压测引擎的设计与实现Word格式文档下载.docx

1、以用户下单这个场景为例，用户完成一笔订单，可能需要打开商品主页-加入购物车-选择收货地址-下单支付这些步骤，而串起这一系列的请求就是所谓的将请求编排成业务场景流量控制流量控制可以是纵向的，如上述下单场景中，各个步骤的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向的，比如用户正在浏览 A 商品的商品详情页，然后看到了 B 商品的推荐，转而浏览 B 商品的商品详情页压力控制指压测时并发用户数、吞吐量（RPS / TPS）的控制数据跟请求参数的绑定压测往往涉及大量的测试数据，而如何绑定数据和请求参数是我们需要考量的对分布式测试的支持因为是全链路压测，自然需要多台施压机共同协作施压，自然而然的需要

2、分布式支持测试报告良好的测试报告是我们分析性能问题的必备条件二次开发的成本由于时间或人力关系，我们也需要考虑二次开发成本1.2、4 个主流开源性能测试框架对比我们调研了以下 4 个主流开源性能测试框架：ApacheBenchApache 服务器自带，简单易用，但不支持场景编排、不支持分布式，二次开发难度较大JMeterJMeter 支持上述很多特性，如分布式、良好的压测报告等，但其基于 GUI 的使用方式，使得当我们的压测场景非常复杂并包含很多请求时，使用上不够灵活；此外在流量控制方面的支持也一般nGrinder基于 Grinder 二次开发的开源项目，支持分布式，测试报告良好，但和 JMet

3、er 一样，在场景编排和流量控制方面支持一般Gatling支持场景编排、流量控制、压力控制，测试报告良好，且提供了强大的 DSL（领域特定语言）方便编写压测脚本，但不支持分布式，且使用 Scala 开发，有一定开发成本以上，我们最终选择基于 Gatling 做二次开发。2、Maxim 新增的特性Maxim 在 Gatling 基础上开发了很多新特性：支持分布式一个控制中心（Control Center，负责调度） + 多个压力注入器（指施压机）提供 GUI，并对用户隐藏压测过程的复杂性高效地创建、运行（手动/定期）测试任务管理测试资源测试资源包括压测脚本、数据集（为压测请求提供测试数据，由数据

4、块构成的一个集合，数据块是大量测试数据的最小分割单元）、压力注入器支持压测脚本参数化Maxim 中并发用户数、RPS、持续时间等都可以通过 GUI 动态注入压测脚本支持压力注入器系统状态监控实时监控压力注入器的 CPU、内存、I/O 等指标自动生成压测报告，保留历史压测报告采集多个压力注入器的压测日志，自动汇总生成压测报告，并保留历史压测报告3、Maxim 的技术架构3.1、Maxim 的总体架构Maxim 架构的主要构成：Maxim ConsoleMaxim Console 主要衔接 GUI 和 Maxim Control Center，负责创建、运行测试任务，接收压力控制参数等Maxim

5、Control CenterMaxim 的控制中心，这里主要负责压测任务的调度、读取数据集、上传脚本和数据以及读取日志并生成压测报告Load Injector Cluster压力注入器集群，主要分为 Agent 和 Gatling 两部分，Agent 负责接收 Maxim 控制中心的调度指令以及向控制中心反馈本压力注入器压测情况，而 Gatling 则是真正发起压测请求的地方，并将压测日志写入 InfluxDBData Factory压测数据首先会在大数据平台通过 MapReduce 任务生成，而数据工厂负责为控制中心读取这些数据并返回数据集Cloud Storage云存储，Maxim 控制中

6、心会将压测脚本和压测数据上传到云存储，当 Agent 收到控制中心的任务执行指令时，会从云存储下载压测脚本和对应的数据块。设计云存储的目的主要是为了模拟真实用户环境在公网发起压测请求，但有赞目前都是从内网发起压测请求，所以云存储的功能也可以以其他方式实现，比如 Agent 直接从大数据平台下载数据集InfluxDB所有压力注入器产生的日志都会统一写入 InfluxDB，方便生成压测报告Maxim的调度算法 控制中心会根据当前测试任务使用的压力注入器数量，将数据集中的数据块平均分配给每个压力注入器，让每个压力注入器只下载对应的那些数据块。此外，并发用户数、RPS 也会被平均切分给每个压力注入器。

7、这样，每个压力注入器的负载基本是一致的。3.2、Maxim 的领域抽象TestJob - JobExecution - JobSliceExecution当压测任务开始执行，首先会在控制中心生成 JobExecution，监控本次压测任务的整体执行状态。控制中心又会根据上述调度算法为每个压力注入器生成任务分片 JobSliceExecution 并下发到各个压力注入器，其中包含了脚本、数据集等信息TestScript压测脚本DataSet和DataChunk数据集和组成数据集的数据块单元，目前单次压测任务已支持多数据集，为多个场景提供不同的压测数据，即混合场景压测LoadProfile从 GU

8、I 接收动态参数，主要包括压力注入器数量、并发用户数、RPS、持续时间等ExecPlan执行计划，包括按需执行和周期执行两种执行方式ExecutionStatus关于状态机下一节会详细介绍3.3、Maxim的状态机Maxim 状态机是 Maxim 分布式的核心，控制中心和各个 Agent 的行为都受状态机变化的影响。创建任务并开始执行以后，各个任务分片（JobSliceExecution）首先会进入 preparing 状态，各个 Agent 会从云存储下载压测脚本和各自对应的那些数据块，下载完成后再将这些数据块合并成一个 Json 数据文件作为压测脚本的数据输入。如果下载失败则会重试，即 P

9、repare。如果所有 Agent 都成功下载了脚本和数据，则各个 JobSliceExecution 会相继进入 prepared 状态，等所有 JobSliceExecution 进入 prepared 状态后，JobExecution 也会进入 prepared 状态，并向各个 Agent 发起执行指令，各个 JobSliceExecution 进入 running 状态，等所有 Agent 执行完成且各个 JobSliceExecution 变成 completed 状态之后，JobExecution 也会进入 completed 状态，此时压测任务执行完成并生成压测报告。如果各个任务

10、分片在 preparing、prepared 或 running 过程中有任何一个出错，则出错的分片会进入 failed 状态并通知控制中心，控制中心则控制其他分片中止正在执行的任务并进入 Stopping 状态，等这些分片中止成功并都变成 stopped 状态后，JobExecution 会被置成 failed 状态。当然了，也可以手动停止压测任务，这时候 JobSliceExecution 和 JobExecution 都会被置成 stopping-stopped 状态。3.4、Maxim 控制中心的技术架构Maxim 控制中心采用六边形架构（也叫端口与适配器模式），核心服务只处理核心业务

11、逻辑（如调度算法），其他功能如与 Agent 通信、脚本存储、数据存储、压测报告等都是通过适配层调用特定实现的 API 实现。具体技术的话，与 Agent 通信使用 grpc 实现，其他功能则是通过 SPI 技术实现，我们把这一层叫做接缝层（Seam）。这样设计最大层度的解耦了核心业务逻辑和其他功能的特定实现，我们在保持接缝层 API 不变的情况下，可以自由选择技术方案实现相应的功能。比如数据服务这块强依赖了有赞的大数据平台，假设我们开源了 Maxim，外部团队就可以选择他们自己的技术方案实现数据服务，或者为了测试目的 Mock 掉。4、改造 Gatling原生 Gatling 是将压测日志写

12、入本地日志文件的，而在分布式中，如果每个压力注入器都把日志写在本地，则为了基于所有日志分析生成压测报告，我们需要首先收集分散在各个压力注入器中的日志文件，这样显然是低效的。所以我们改造了 Gatling ，将所有日志都写到同一个 InfluxDB 数据库。需要生成压测报告时，控制中心从 InfluxDB 数据库读入本次压测任务的所有压测日志并保存为一个日志文件，再交由 Gatling 的日志处理模块来生成压测报告。5、扩展 Gatling原生 Gatling 不支持 Dubbo 压测，所以我们扩展 Gatling，实现并开源了 gatling-dubbo压测插件，具体实现方法详见 Dubbo压

13、测插件的实现基于Gatling6、Maxim 的未来展望Maxim 目前还是个单打独斗的产品，未来我们希望与大数据平台、运维平台等系统打通，让 Maxim 逐渐进化为一个一站式的压测平台，并引入更多新特性，如压测过程和压测报告的实时计算和展示等等。我的系列博客 混沌工程 - 软件系统高可用、弹性化的必由之路 异步系统的两种测试方法 Dubbo压测插件的实现基于Gatling我的其他测试相关开源项目 捉虫记：方便产品、开发、测试三方协同自测的管理工具 gatling-dubbo：扩展自Gatling的Dubbo性能测试插件招聘 有赞测试组在持续招人中，大量岗位空缺，只要你来，就能帮你点亮全栈开发技能树，有意向换工作的同学可以发简历到 sunjun【】-全文完-