摘要：工欲善其事，必先利其器，我們拿什么工具來(lái)壓測(cè)呢我們做了很多前期調(diào)研和論證，最終決定基于開(kāi)發(fā)有贊自己的分布式全鏈路壓測(cè)引擎。

一年以前，有贊準(zhǔn)備在雙十一到來(lái)之前對(duì)系統(tǒng)進(jìn)行一次性能摸底，以便提前發(fā)現(xiàn)并解決系統(tǒng)潛在性能問(wèn)題，好讓系統(tǒng)在雙十一期間可以從容應(yīng)對(duì)劇增的流量。工欲善其事，必先利其器，我們拿什么工具來(lái)壓測(cè)呢？我們做了很多前期調(diào)研和論證，最終決定基于 Gatling 開(kāi)發(fā)有贊自己的分布式全鏈路壓測(cè)引擎 —— MAXIM。一年多來(lái)，我們使用 Maxim 對(duì)系統(tǒng)做了很多次的性能壓測(cè)，在提升系統(tǒng)性能、穩(wěn)定性的同時(shí)，也得益于歷次壓測(cè)的實(shí)踐經(jīng)驗(yàn)逐步改進(jìn) Maxim。

由于時(shí)間或成本關(guān)系，我們打算基于開(kāi)源軟件做二次開(kāi)發(fā)，而以下就是我們技術(shù)選型時(shí)的核心考量：

將請(qǐng)求編排成業(yè)務(wù)場(chǎng)景

以用戶下單這個(gè)場(chǎng)景為例，用戶完成一筆訂單，可能需要打開(kāi)商品主頁(yè)-加入購(gòu)物車(chē)-選擇收貨地址-下單支付這些步驟，而串起這一系列的請(qǐng)求就是所謂的將請(qǐng)求編排成業(yè)務(wù)場(chǎng)景

流量控制

流量控制可以是縱向的，如上述下單場(chǎng)景中，各個(gè)步驟的請(qǐng)求量逐漸減少，整體呈現(xiàn)一個(gè)漏斗模型；也可以是橫向的，比如用戶正在瀏覽 A 商品的商品詳情頁(yè)，然后看到了 B 商品的推薦，轉(zhuǎn)而瀏覽 B 商品的商品詳情頁(yè)

壓力控制

指壓測(cè)時(shí)并發(fā)用戶數(shù)、吞吐量(RPS / TPS)的控制

數(shù)據(jù)跟請(qǐng)求參數(shù)的綁定

壓測(cè)往往涉及大量的測(cè)試數(shù)據(jù)，而如何綁定數(shù)據(jù)和請(qǐng)求參數(shù)是我們需要考量的

對(duì)分布式測(cè)試的支持

因?yàn)槭侨溌穳簻y(cè)，自然需要多臺(tái)施壓機(jī)共同協(xié)作施壓，自然而然的需要分布式支持

測(cè)試報(bào)告

良好的測(cè)試報(bào)告是我們分析性能問(wèn)題的必備條件

二次開(kāi)發(fā)的成本

由于時(shí)間或人力關(guān)系，我們也需要考慮二次開(kāi)發(fā)成本

我們調(diào)研了以下 4 個(gè)主流開(kāi)源性能測(cè)試框架：

ApacheBench

Apache 服務(wù)器自帶，簡(jiǎn)單易用，但不支持場(chǎng)景編排、不支持分布式，二次開(kāi)發(fā)難度較大

JMeter

JMeter 支持上述很多特性，如分布式、良好的壓測(cè)報(bào)告等，但其基于 GUI 的使用方式，使得當(dāng)我們的壓測(cè)場(chǎng)景非常復(fù)雜并包含很多請(qǐng)求時(shí)，使用上不夠靈活；此外在流量控制方面的支持也一般

nGrinder

基于 Grinder 二次開(kāi)發(fā)的開(kāi)源項(xiàng)目，支持分布式，測(cè)試報(bào)告良好，但和 JMeter 一樣，在場(chǎng)景編排和流量控制方面支持一般

Gatling

支持場(chǎng)景編排、流量控制、壓力控制，測(cè)試報(bào)告良好，且提供了強(qiáng)大的 DSL（領(lǐng)域特定語(yǔ)言）方便編寫(xiě)壓測(cè)腳本，但不支持分布式，且使用 Scala 開(kāi)發(fā)，有一定開(kāi)發(fā)成本

以上，我們最終選擇基于 Gatling 做二次開(kāi)發(fā)。

Maxim 在 Gatling 基礎(chǔ)上開(kāi)發(fā)了很多新特性：

支持分布式

一個(gè)控制中心（Control Center，負(fù)責(zé)調(diào)度） + 多個(gè)壓力注入器（指施壓機(jī)）

提供 GUI，并對(duì)用戶隱藏壓測(cè)過(guò)程的復(fù)雜性

高效地創(chuàng)建、運(yùn)行（手動(dòng)/定期）測(cè)試任務(wù)

管理測(cè)試資源

測(cè)試資源包括壓測(cè)腳本、數(shù)據(jù)集（為壓測(cè)請(qǐng)求提供測(cè)試數(shù)據(jù)，由數(shù)據(jù)塊構(gòu)成的一個(gè)集合，數(shù)據(jù)塊是大量測(cè)試數(shù)據(jù)的最小分割單元）、壓力注入器

支持壓測(cè)腳本參數(shù)化

Maxim 中并發(fā)用戶數(shù)、RPS、持續(xù)時(shí)間等都可以通過(guò) GUI 動(dòng)態(tài)注入壓測(cè)腳本

支持壓力注入器系統(tǒng)狀態(tài)監(jiān)控

實(shí)時(shí)監(jiān)控壓力注入器的 CPU、內(nèi)存、I/O 等指標(biāo)

自動(dòng)生成壓測(cè)報(bào)告，保留歷史壓測(cè)報(bào)告

采集多個(gè)壓力注入器的壓測(cè)日志，自動(dòng)匯總生成壓測(cè)報(bào)告，并保留歷史壓測(cè)報(bào)告

Maxim 架構(gòu)的主要構(gòu)成：

Maxim Console

Maxim Console 主要銜接 GUI 和 Maxim Control Center，負(fù)責(zé)創(chuàng)建、運(yùn)行測(cè)試任務(wù)，接收壓力控制參數(shù)等

Maxim Control Center

Maxim 的控制中心，這里主要負(fù)責(zé)壓測(cè)任務(wù)的調(diào)度、讀取數(shù)據(jù)集、上傳腳本和數(shù)據(jù)以及讀取日志并生成壓測(cè)報(bào)告

Load Injector Cluster

壓力注入器集群，主要分為 Agent 和 Gatling 兩部分，Agent 負(fù)責(zé)接收 Maxim 控制中心的調(diào)度指令以及向控制中心反饋本壓力注入器壓測(cè)情況，而 Gatling 則是真正發(fā)起壓測(cè)請(qǐng)求的地方，并將壓測(cè)日志寫(xiě)入 InfluxDB

Data Factory

壓測(cè)數(shù)據(jù)首先會(huì)在大數(shù)據(jù)平臺(tái)通過(guò) MapReduce 任務(wù)生成，而數(shù)據(jù)工廠負(fù)責(zé)為控制中心讀取這些數(shù)據(jù)并返回?cái)?shù)據(jù)集

Cloud Storage

云存儲(chǔ)，Maxim 控制中心會(huì)將壓測(cè)腳本和壓測(cè)數(shù)據(jù)上傳到云存儲(chǔ)，當(dāng) Agent 收到控制中心的任務(wù)執(zhí)行指令時(shí)，會(huì)從云存儲(chǔ)下載壓測(cè)腳本和對(duì)應(yīng)的數(shù)據(jù)塊。設(shè)計(jì)云存儲(chǔ)的目的主要是為了模擬真實(shí)用戶環(huán)境在公網(wǎng)發(fā)起壓測(cè)請(qǐng)求，但有贊目前都是從內(nèi)網(wǎng)發(fā)起壓測(cè)請(qǐng)求，所以云存儲(chǔ)的功能也可以以其他方式實(shí)現(xiàn)，比如 Agent 直接從大數(shù)據(jù)平臺(tái)下載數(shù)據(jù)集

InfluxDB

所有壓力注入器產(chǎn)生的日志都會(huì)統(tǒng)一寫(xiě)入 InfluxDB，方便生成壓測(cè)報(bào)告

Maxim的調(diào)度算法  
控制中心會(huì)根據(jù)當(dāng)前測(cè)試任務(wù)使用的壓力注入器數(shù)量，將數(shù)據(jù)集中的數(shù)據(jù)塊平均分配給每個(gè)壓力注入器，讓每個(gè)壓力注入器只下載對(duì)應(yīng)的那些數(shù)據(jù)塊。此外，并發(fā)用戶數(shù)、RPS 也會(huì)被平均切分給每個(gè)壓力注入器。這樣，每個(gè)壓力注入器的負(fù)載基本是一致的。

TestJob - JobExecution - JobSliceExecution

當(dāng)壓測(cè)任務(wù)開(kāi)始執(zhí)行，首先會(huì)在控制中心生成 JobExecution，監(jiān)控本次壓測(cè)任務(wù)的整體執(zhí)行狀態(tài)。控制中心又會(huì)根據(jù)上述調(diào)度算法為每個(gè)壓力注入器生成任務(wù)分片 JobSliceExecution 并下發(fā)到各個(gè)壓力注入器，其中包含了腳本、數(shù)據(jù)集等信息

TestScript

壓測(cè)腳本

DataSet和DataChunk

數(shù)據(jù)集和組成數(shù)據(jù)集的數(shù)據(jù)塊單元，目前單次壓測(cè)任務(wù)已支持多數(shù)據(jù)集，為多個(gè)場(chǎng)景提供不同的壓測(cè)數(shù)據(jù)，即混合場(chǎng)景壓測(cè)

LoadProfile

從 GUI 接收動(dòng)態(tài)參數(shù)，主要包括壓力注入器數(shù)量、并發(fā)用戶數(shù)、RPS、持續(xù)時(shí)間等

ExecPlan

執(zhí)行計(jì)劃，包括按需執(zhí)行和周期執(zhí)行兩種執(zhí)行方式

ExecutionStatus

關(guān)于狀態(tài)機(jī)下一節(jié)會(huì)詳細(xì)介紹

Maxim 狀態(tài)機(jī)是 Maxim 分布式的核心，控制中心和各個(gè) Agent 的行為都受狀態(tài)機(jī)變化的影響。

創(chuàng)建任務(wù)并開(kāi)始執(zhí)行以后，各個(gè)任務(wù)分片（JobSliceExecution）首先會(huì)進(jìn)入 preparing 狀態(tài)，各個(gè) Agent 會(huì)從云存儲(chǔ)下載壓測(cè)腳本和各自對(duì)應(yīng)的那些數(shù)據(jù)塊，下載完成后再將這些數(shù)據(jù)塊合并成一個(gè) Json 數(shù)據(jù)文件作為壓測(cè)腳本的數(shù)據(jù)輸入。如果下載失敗則會(huì)重試，即 Prepare。如果所有 Agent 都成功下載了腳本和數(shù)據(jù)，則各個(gè) JobSliceExecution 會(huì)相繼進(jìn)入 prepared 狀態(tài)，等所有 JobSliceExecution 進(jìn)入 prepared 狀態(tài)后，JobExecution 也會(huì)進(jìn)入 prepared 狀態(tài)，并向各個(gè) Agent 發(fā)起執(zhí)行指令，各個(gè) JobSliceExecution 進(jìn)入 running 狀態(tài)，等所有 Agent 執(zhí)行完成且各個(gè) JobSliceExecution 變成 completed 狀態(tài)之后，JobExecution 也會(huì)進(jìn)入 completed 狀態(tài)，此時(shí)壓測(cè)任務(wù)執(zhí)行完成并生成壓測(cè)報(bào)告。如果各個(gè)任務(wù)分片在 preparing、prepared 或 running 過(guò)程中有任何一個(gè)出錯(cuò)，則出錯(cuò)的分片會(huì)進(jìn)入 failed 狀態(tài)并通知控制中心，控制中心則控制其他分片中止正在執(zhí)行的任務(wù)并進(jìn)入 Stopping 狀態(tài)，等這些分片中止成功并都變成 stopped 狀態(tài)后，JobExecution 會(huì)被置成 failed 狀態(tài)。當(dāng)然了，也可以手動(dòng)停止壓測(cè)任務(wù)，這時(shí)候 JobSliceExecution 和 JobExecution 都會(huì)被置成 stopping->stopped 狀態(tài)。

Maxim 控制中心采用六邊形架構(gòu)（也叫端口與適配器模式），核心服務(wù)只處理核心業(yè)務(wù)邏輯（如調(diào)度算法），其他功能如與 Agent 通信、腳本存儲(chǔ)、數(shù)據(jù)存儲(chǔ)、壓測(cè)報(bào)告等都是通過(guò)適配層調(diào)用特定實(shí)現(xiàn)的 API 實(shí)現(xiàn)。具體技術(shù)的話，與 Agent 通信使用 grpc 實(shí)現(xiàn)，其他功能則是通過(guò) SPI 技術(shù)實(shí)現(xiàn)，我們把這一層叫做接縫層（Seam）。這樣設(shè)計(jì)最大層度的解耦了核心業(yè)務(wù)邏輯和其他功能的特定實(shí)現(xiàn)，我們?cè)诒３纸涌p層 API 不變的情況下，可以自由選擇技術(shù)方案實(shí)現(xiàn)相應(yīng)的功能。比如數(shù)據(jù)服務(wù)這塊強(qiáng)依賴了有贊的大數(shù)據(jù)平臺(tái)，假設(shè)我們開(kāi)源了 Maxim，外部團(tuán)隊(duì)就可以選擇他們自己的技術(shù)方案實(shí)現(xiàn)數(shù)據(jù)服務(wù)，或者為了測(cè)試目的 Mock 掉。

原生 Gatling 是將壓測(cè)日志寫(xiě)入本地日志文件的，而在分布式中，如果每個(gè)壓力注入器都把日志寫(xiě)在本地，則為了基于所有日志分析生成壓測(cè)報(bào)告，我們需要首先收集分散在各個(gè)壓力注入器中的日志文件，這樣顯然是低效的。所以我們改造了 Gatling ，將所有日志都寫(xiě)到同一個(gè) InfluxDB 數(shù)據(jù)庫(kù)。需要生成壓測(cè)報(bào)告時(shí)，控制中心從 InfluxDB 數(shù)據(jù)庫(kù)讀入本次壓測(cè)任務(wù)的所有壓測(cè)日志并保存為一個(gè)日志文件，再交由 Gatling 的日志處理模塊來(lái)生成壓測(cè)報(bào)告。

原生 Gatling 不支持 Dubbo 壓測(cè)，所以我們擴(kuò)展 Gatling，實(shí)現(xiàn)并開(kāi)源了 gatling-dubbo壓測(cè)插件，具體實(shí)現(xiàn)方法詳見(jiàn) Dubbo壓測(cè)插件的實(shí)現(xiàn)——基于Gatling

Maxim 目前還是個(gè)單打獨(dú)斗的產(chǎn)品，未來(lái)我們希望與大數(shù)據(jù)平臺(tái)、運(yùn)維平臺(tái)等系統(tǒng)打通，讓 Maxim 逐漸進(jìn)化為一個(gè)一站式的壓測(cè)平臺(tái)，并引入更多新特性，如壓測(cè)過(guò)程和壓測(cè)報(bào)告的實(shí)時(shí)計(jì)算和展示等等。

我的系列博客
混沌工程 - 軟件系統(tǒng)高可用、彈性化的必由之路
異步系統(tǒng)的兩種測(cè)試方法
Dubbo壓測(cè)插件的實(shí)現(xiàn)——基于Gatling

我的其他測(cè)試相關(guān)開(kāi)源項(xiàng)目
捉蟲(chóng)記：方便產(chǎn)品、開(kāi)發(fā)、測(cè)試三方協(xié)同自測(cè)的管理工具
gatling-dubbo：擴(kuò)展自Gatling的Dubbo性能測(cè)試插件

招聘
有贊測(cè)試組在持續(xù)招人中，大量崗位空缺，只要你來(lái)，就能幫你點(diǎn)亮全棧開(kāi)發(fā)技能樹(shù)，有意向換工作的同學(xué)可以發(fā)簡(jiǎn)歷到 sunjun【@】youzan.com