2. 测试环境搭建:压测工具选型与监控部署
好,咱们进入实战前的第一道坎——环境搭建。说实话,很多同学觉得这步就是装个软件,没啥技术含量。但我见过太多团队,工具选错了,后面全白干。监控没搭好,压测跑完了才发现数据丢了。嗯,今天咱们就把这事聊透。
2.1 压测工具选型:JMeter vs Locust vs Gatling
选工具这事,我个人的习惯是先看场景,再看团队。别盲目追新,也别死守老一套。下面这三款,我都在项目中实战过,说说我的真实感受。
| 维度 | JMeter | Locust | Gatling |
|---|---|---|---|
| 语言 | Java(GUI配置) | Python(代码编写) | Scala(DSL脚本) |
| 学习曲线 | 低(拖拽即可) | 中(需懂Python) | 高(需懂Scala) |
| 分布式压测 | 支持(需额外配置) | 原生支持(简单) | 支持(需配置) |
| 报告质量 | 一般(需插件) | 一般(需扩展) | 优秀(内置HTML报告) |
| 社区活跃度 | 极高 | 高 | 中 |
| 适合场景 | 传统企业、快速上手 | Python团队、灵活定制 | 高性能、CI/CD集成 |
2.1.1 JMeter:老牌劲旅,稳如老狗
JMeter 是我最早接触的压测工具。说白了,它就是个图形化的压力机。你点点鼠标,就能配出一个复杂的压测场景。我记得有一次帮一家银行做接口压测,对方要求必须用 JMeter,因为他们的运维团队只会这个。
优点很明显:
- 上手快,拖拽组件就能跑
- 插件生态丰富,几乎啥协议都支持
- 文档多,遇到问题百度一下就有答案
但坑也不少:
- GUI 模式压测时,本身就会消耗资源。我曾经犯过这个错——用 GUI 跑 500 并发,结果 JMeter 自己先挂了。
- 报告太丑,得配合插件或者自己写脚本处理。
jmeter -n -t test.jmx -l result.jtl
2.1.2 Locust:Python 党的最爱
Locust 这东西,我第一次用就爱上了。为啥?因为它用 Python 写脚本,太灵活了。你想想看,Python 能干啥?能调库、能写逻辑、能对接各种数据源。我在做电商秒杀压测时,就用 Locust 配合 Redis 模拟了真实用户行为。
核心优势:
- 代码即配置,想怎么玩就怎么玩
- 分布式压测原生支持,一条命令搞定
- Web UI 实时查看结果,很直观
需要注意:
- 性能不如 Gatling,毕竟 Python 是解释型语言
- 报告功能偏弱,需要自己二次开发
避坑指南: 我曾经用 Locust 压测一个 WebSocket 服务,发现并发数一上去,Locust 的 master 节点 CPU 就飙到 100%。后来排查发现是事件循环处理不过来。解决方案是:把 master 和 worker 分开部署,并且 worker 数量不要超过 CPU 核心数的 2 倍。
2.1.3 Gatling:性能怪兽,CI/CD 首选
Gatling 是我最近两年才开始用的。说实话,一开始被 Scala 脚本吓到了。但用顺手之后,真香。它的报告是我见过最漂亮的,没有之一。而且它基于 Akka 的异步模型,单机就能压出很高的并发。
为什么选它?
- 性能极高,同样的硬件配置,Gatling 能压出 JMeter 2-3 倍的并发
- 报告自带图表,直接就能用
- 和 Jenkins、GitLab CI 集成非常方便
缺点也很明显:
- 学习成本高,Scala 语法对很多人来说是个坎
- 调试不方便,不像 Python 那样可以交互式调试
2.2 监控工具部署:Prometheus + Grafana
压测工具负责「造压力」,监控工具负责「看结果」。这两者缺一不可。我见过太多人,压测跑得飞起,结果服务器 CPU 都 100% 了还不知道。嗯,监控就是你的眼睛。
2.2.1 为什么选 Prometheus + Grafana?
市面上监控方案很多,但 Prometheus + Grafana 基本是业界标准。为啥?
- Prometheus:时序数据库,专门存指标数据。拉取模式,你不需要在每台机器上装 agent。
- Grafana:可视化面板,能把 Prometheus 的数据变成漂亮的图表。
说白了,Prometheus 负责「存」,Grafana 负责「看」。这对组合,就像咖啡和奶精,分开也能用,但合在一起才完美。
2.2.2 部署实战:Docker Compose 一键搞定
我个人习惯用 Docker 部署,省心。下面是我常用的 docker-compose.yml 配置:
version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
ports:
- "9090:9090"
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
grafana:
image: grafana/grafana:latest
container_name: grafana
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin
volumes:
- grafana_data:/var/lib/grafana
volumes:
prometheus_data:
grafana_data:
对应的 prometheus.yml 配置文件:
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['host.docker.internal:9100']
- job_name: 'jmeter'
static_configs:
- targets: ['host.docker.internal:9270']
host.docker.internal 来访问宿主机。如果你在 Linux 上跑 Docker,需要换成宿主机 IP。我曾经因为这个坑,折腾了半小时才发现 Prometheus 连不上 node_exporter。
2.2.3 关键指标:压测时该看什么?
很多新手一上来就盯着 CPU 看,其实不对。压测时,我建议你重点关注这几个指标:
| 指标 | 来源 | 说明 |
|---|---|---|
| CPU 使用率 | node_exporter | 超过 80% 说明 CPU 是瓶颈 |
| 内存使用率 | node_exporter | 注意不要触发 OOM |
| 磁盘 IO | node_exporter | 数据库类应用重点关注 |
| 网络带宽 | node_exporter | 看是否被打满 |
| 请求延迟 | JMeter Exporter | P99 延迟是关键 |
| 错误率 | JMeter Exporter | 超过 1% 就要报警 |
2.3 知识体系总览
说了这么多,咱们用一张图来总结一下整个测试环境的架构:
这张图把整个流程串起来了。你想想看,压测工具造压力,被压系统扛压力,监控系统看压力。三个环节缺一不可。我在实际项目中,经常发现有人只关注压测工具,忽略了监控。结果压测跑完了,连个像样的报告都拿不出来。
最后说一句: 环境搭建这事,别图快。我建议你花一天时间,把 Prometheus + Grafana 的 Dashboard 调好,把压测工具的脚本写好。后面跑压测的时候,你会发现这时间花得值。