有赞全链路压测引擎的设计与实现

摘要：工欲善其事，必先利其器，我们拿什么工具来压测呢我们做了很多前期调研和论证，最终决定基于开发有赞自己的分布式全链路压测引擎。

一年以前，有赞准备在双十一到来之前对系统进行一次性能摸底，以便提前发现并解决系统潜在性能问题，好让系统在双十一期间可以从容应对剧增的流量。工欲善其事，必先利其器，我们拿什么工具来压测呢？我们做了很多前期调研和论证，最终决定基于 Gatling 开发有赞自己的分布式全链路压测引擎 —— MAXIM。一年多来，我们使用 Maxim 对系统做了很多次的性能压测，在提升系统性能、稳定性的同时，也得益于历次压测的实践经验逐步改进 Maxim。

由于时间或成本关系，我们打算基于开源软件做二次开发，而以下就是我们技术选型时的核心考量：

将请求编排成业务场景

以用户下单这个场景为例，用户完成一笔订单，可能需要打开商品主页-加入购物车-选择收货地址-下单支付这些步骤，而串起这一系列的请求就是所谓的将请求编排成业务场景

流量控制

流量控制可以是纵向的，如上述下单场景中，各个步骤的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向的，比如用户正在浏览 A 商品的商品详情页，然后看到了 B 商品的推荐，转而浏览 B 商品的商品详情页

压力控制

指压测时并发用户数、吞吐量(RPS / TPS)的控制

数据跟请求参数的绑定

压测往往涉及大量的测试数据，而如何绑定数据和请求参数是我们需要考量的

对分布式测试的支持

因为是全链路压测，自然需要多台施压机共同协作施压，自然而然的需要分布式支持

测试报告

良好的测试报告是我们分析性能问题的必备条件

二次开发的成本

由于时间或人力关系，我们也需要考虑二次开发成本

我们调研了以下 4 个主流开源性能测试框架：

ApacheBench

Apache 服务器自带，简单易用，但不支持场景编排、不支持分布式，二次开发难度较大

JMeter

JMeter 支持上述很多特性，如分布式、良好的压测报告等，但其基于 GUI 的使用方式，使得当我们的压测场景非常复杂并包含很多请求时，使用上不够灵活；此外在流量控制方面的支持也一般

nGrinder

基于 Grinder 二次开发的开源项目，支持分布式，测试报告良好，但和 JMeter 一样，在场景编排和流量控制方面支持一般

Gatling

支持场景编排、流量控制、压力控制，测试报告良好，且提供了强大的 DSL（领域特定语言）方便编写压测脚本，但不支持分布式，且使用 Scala 开发，有一定开发成本

以上，我们最终选择基于 Gatling 做二次开发。

Maxim 在 Gatling 基础上开发了很多新特性：

支持分布式

一个控制中心（Control Center，负责调度） + 多个压力注入器（指施压机）

提供 GUI，并对用户隐藏压测过程的复杂性

高效地创建、运行（手动/定期）测试任务

管理测试资源

测试资源包括压测脚本、数据集（为压测请求提供测试数据，由数据块构成的一个集合，数据块是大量测试数据的最小分割单元）、压力注入器

支持压测脚本参数化

Maxim 中并发用户数、RPS、持续时间等都可以通过 GUI 动态注入压测脚本

支持压力注入器系统状态监控

实时监控压力注入器的 CPU、内存、I/O 等指标

自动生成压测报告，保留历史压测报告

采集多个压力注入器的压测日志，自动汇总生成压测报告，并保留历史压测报告

Maxim 架构的主要构成：

Maxim Console

Maxim Console 主要衔接 GUI 和 Maxim Control Center，负责创建、运行测试任务，接收压力控制参数等

Maxim Control Center

Maxim 的控制中心，这里主要负责压测任务的调度、读取数据集、上传脚本和数据以及读取日志并生成压测报告

Load Injector Cluster

压力注入器集群，主要分为 Agent 和 Gatling 两部分，Agent 负责接收 Maxim 控制中心的调度指令以及向控制中心反馈本压力注入器压测情况，而 Gatling 则是真正发起压测请求的地方，并将压测日志写入 InfluxDB

Data Factory

压测数据首先会在大数据平台通过 MapReduce 任务生成，而数据工厂负责为控制中心读取这些数据并返回数据集

Cloud Storage

云存储，Maxim 控制中心会将压测脚本和压测数据上传到云存储，当 Agent 收到控制中心的任务执行指令时，会从云存储下载压测脚本和对应的数据块。设计云存储的目的主要是为了模拟真实用户环境在公网发起压测请求，但有赞目前都是从内网发起压测请求，所以云存储的功能也可以以其他方式实现，比如 Agent 直接从大数据平台下载数据集

InfluxDB

所有压力注入器产生的日志都会统一写入 InfluxDB，方便生成压测报告

Maxim的调度算法  
控制中心会根据当前测试任务使用的压力注入器数量，将数据集中的数据块平均分配给每个压力注入器，让每个压力注入器只下载对应的那些数据块。此外，并发用户数、RPS 也会被平均切分给每个压力注入器。这样，每个压力注入器的负载基本是一致的。

TestJob - JobExecution - JobSliceExecution

当压测任务开始执行，首先会在控制中心生成 JobExecution，监控本次压测任务的整体执行状态。控制中心又会根据上述调度算法为每个压力注入器生成任务分片 JobSliceExecution 并下发到各个压力注入器，其中包含了脚本、数据集等信息

TestScript

压测脚本

DataSet和DataChunk

数据集和组成数据集的数据块单元，目前单次压测任务已支持多数据集，为多个场景提供不同的压测数据，即混合场景压测

LoadProfile

从 GUI 接收动态参数，主要包括压力注入器数量、并发用户数、RPS、持续时间等

ExecPlan

执行计划，包括按需执行和周期执行两种执行方式

ExecutionStatus

关于状态机下一节会详细介绍

Maxim 状态机是 Maxim 分布式的核心，控制中心和各个 Agent 的行为都受状态机变化的影响。

创建任务并开始执行以后，各个任务分片（JobSliceExecution）首先会进入 preparing 状态，各个 Agent 会从云存储下载压测脚本和各自对应的那些数据块，下载完成后再将这些数据块合并成一个 Json 数据文件作为压测脚本的数据输入。如果下载失败则会重试，即 Prepare。如果所有 Agent 都成功下载了脚本和数据，则各个 JobSliceExecution 会相继进入 prepared 状态，等所有 JobSliceExecution 进入 prepared 状态后，JobExecution 也会进入 prepared 状态，并向各个 Agent 发起执行指令，各个 JobSliceExecution 进入 running 状态，等所有 Agent 执行完成且各个 JobSliceExecution 变成 completed 状态之后，JobExecution 也会进入 completed 状态，此时压测任务执行完成并生成压测报告。如果各个任务分片在 preparing、prepared 或 running 过程中有任何一个出错，则出错的分片会进入 failed 状态并通知控制中心，控制中心则控制其他分片中止正在执行的任务并进入 Stopping 状态，等这些分片中止成功并都变成 stopped 状态后，JobExecution 会被置成 failed 状态。当然了，也可以手动停止压测任务，这时候 JobSliceExecution 和 JobExecution 都会被置成 stopping->stopped 状态。

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

原生 Gatling 是将压测日志写入本地日志文件的，而在分布式中，如果每个压力注入器都把日志写在本地，则为了基于所有日志分析生成压测报告，我们需要首先收集分散在各个压力注入器中的日志文件，这样显然是低效的。所以我们改造了 Gatling ，将所有日志都写到同一个 InfluxDB 数据库。需要生成压测报告时，控制中心从 InfluxDB 数据库读入本次压测任务的所有压测日志并保存为一个日志文件，再交由 Gatling 的日志处理模块来生成压测报告。

原生 Gatling 不支持 Dubbo 压测，所以我们扩展 Gatling，实现并开源了 gatling-dubbo压测插件，具体实现方法详见 Dubbo压测插件的实现——基于Gatling

Maxim 目前还是个单打独斗的产品，未来我们希望与大数据平台、运维平台等系统打通，让 Maxim 逐渐进化为一个一站式的压测平台，并引入更多新特性，如压测过程和压测报告的实时计算和展示等等。

我的系列博客
混沌工程 - 软件系统高可用、弹性化的必由之路
异步系统的两种测试方法
Dubbo压测插件的实现——基于Gatling

我的其他测试相关开源项目
捉虫记：方便产品、开发、测试三方协同自测的管理工具
gatling-dubbo：扩展自Gatling的Dubbo性能测试插件

招聘
有赞测试组在持续招人中，大量岗位空缺，只要你来，就能帮你点亮全栈开发技能树，有意向换工作的同学可以发简历到 sunjun【@】youzan.com