第二章 测试环境搭建：硬件环境规划、软件环境配置、网络拓扑设计、监控工具部署
环境搭建这事儿，说简单也简单，说复杂能让你折腾一整天。我见过太多团队，脚本写得漂亮，结果压测一跑，环境先崩了。说白了，压力测试测的不只是你的系统，也在测你的环境靠不靠谱。
这一章，咱们把硬件、软件、网络、监控这四个维度拆开揉碎了讲。嗯，跟着我的节奏来，保证你少踩几个坑。
2.1 硬件环境规划：别让机器拖后腿
硬件规划是地基。地基不稳，上面盖什么都白搭。我个人习惯，先问三个问题：
- 被测系统需要多少资源？ CPU、内存、磁盘IO，心里要有数。
- 压测机需要多少资源？ 别让压测机自己先成了瓶颈。
- 网络带宽够不够？ 千兆还是万兆？延迟多少？
我在项目中遇到过一件事：客户说服务器是32核64G，结果压测一跑，CPU直接飙到95%。后来一查，虚拟机超分严重，物理机上一共跑了8台虚拟机。你想想看，这能不出问题吗？
硬件规划核心原则：
- 压测机与被测系统物理隔离，别共用同一台宿主机
- 压测机资源至少是被测系统的2倍（我一般按3倍预留）
- 磁盘建议用SSD，尤其是日志写入频繁的场景
- 网络建议万兆内网，千兆在并发高时容易打满
我的小技巧： 压测前先跑一轮 top、iostat、vmstat，看看空闲资源到底有多少。别信云厂商给你的配置单，自己测了才算数。
2.2 软件环境配置：版本一致是铁律
软件环境配置，最怕什么？版本不一致。开发用JDK 11，测试环境用JDK 8，压测结果出来差异巨大，你都不知道该信谁。
我建议，压测环境的软件版本必须和生产环境完全一致。包括：
- 操作系统版本（CentOS 7.9 vs Rocky Linux 8.6，差异不小）
- JDK/Python/Node.js 等运行时版本
- 中间件版本（Nginx、Tomcat、Redis、MySQL）
- 内核参数配置（文件句柄数、网络参数、内存分配策略）
举个例子，我曾经因为Nginx的worker_connections没调大，压测到2000并发时直接报502。查了半天，不是代码问题，是Nginx默认配置只支持1024个连接。你说冤不冤？
避坑指南： 我曾经在压测前忘了检查 ulimit -n，结果压测脚本一跑，文件句柄耗尽，所有请求都挂了。从那以后，我每次压测前都会跑一遍环境检查脚本，把内核参数、文件句柄、端口范围全扫一遍。
下面是我常用的环境检查脚本片段，你可以直接拿去用：
#!/bin/bash
# 环境检查脚本 - 压测前必跑
echo "=== 系统信息 ==="
uname -a
cat /etc/os-release | grep PRETTY_NAME
echo "=== 文件句柄限制 ==="
ulimit -n
echo "=== 内核参数 ==="
sysctl net.ipv4.tcp_tw_reuse
sysctl net.core.somaxconn
sysctl vm.swappiness
echo "=== 端口范围 ==="
cat /proc/sys/net/ipv4/ip_local_port_range
echo "=== 磁盘IO ==="
iostat -x 1 3 | tail -52.3 网络拓扑设计：画清楚，别靠猜
网络拓扑设计，说白了就是搞清楚你的请求是怎么走的。从压测机出发，经过几层负载均衡？有没有防火墙？有没有CDN？这些都会影响延迟和吞吐量。
我习惯在压测前先画一张网络拓扑图。不用多精美，但必须把所有网络节点标清楚。下面是我用SVG画的一张典型压测环境拓扑图：
画完拓扑图，你就能清楚地看到：
- 请求路径上有几个节点？每个节点都可能成为瓶颈
- 监控数据怎么采集？从哪个节点拉指标？
- 网络延迟主要在哪一段？是不是需要优化？
我的经验： 压测时尽量走内网，别走公网。公网延迟抖动太大，压测结果不稳定。如果必须走公网，至少跑10分钟以上，取平均值。
2.4 监控工具部署：Prometheus + Grafana
监控是压测的眼睛。没有监控，你就像闭着眼睛开车，撞了都不知道怎么撞的。
我推荐 Prometheus + Grafana 这套组合。Prometheus 负责采集和存储指标，Grafana 负责可视化。两者配合，基本能覆盖99%的监控需求。
2.4.1 Prometheus 部署
Prometheus 部署很简单，下载二进制包，解压就能跑。但我建议用 Docker 部署，方便管理：
# docker-compose.yml
version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- ./data:/prometheus
ports:
- "9090:9090"
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d'
restart: always配置文件 prometheus.yml 长这样：
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100']
- job_name: 'spring_boot'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['192.168.1.20:8080']注意： scrape_interval 别设太短。我见过有人设成1秒，结果Prometheus自己先扛不住了。一般15秒就够，高并发场景可以调到5秒。
2.4.2 Grafana 部署
Grafana 同样用 Docker 部署：
services:
grafana:
image: grafana/grafana:latest
container_name: grafana
volumes:
- ./grafana-data:/var/lib/grafana
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin123
restart: always部署完成后，访问 http://你的IP:3000，默认账号密码是 admin/admin。然后添加 Prometheus 数据源，URL 填 http://prometheus:9090（如果是在同一个 Docker 网络里）。
2.4.3 关键监控指标
我个人习惯，压测时至少盯着以下几类指标：
| 指标类别 | 具体指标 | 说明 |
|---|---|---|
| 系统资源 | CPU 使用率 | 超过80%就要警惕 |
| 内存使用率 | 注意OOM Killer | |
| 磁盘IO | iowait 超过20%说明磁盘是瓶颈 | |
| 应用指标 | 请求延迟（P50/P95/P99） | P99 超过1秒就要优化 |
| 错误率 | 超过1%立即停止压测 | |
| 网络指标 | 网络吞吐量 | 别让带宽打满 |
| TCP连接数 | 注意TIME_WAIT堆积 |
核心要点： 监控不是为了看数据，而是为了发现问题。我建议在 Grafana 上配置告警规则，比如 CPU 超过 85% 就发钉钉通知。这样你就不用一直盯着屏幕了。
2.5 环境验证：别急着跑压测
环境搭好了，别急着跑压测。先做一轮冒烟测试，确认所有组件都正常工作：
- 检查 Prometheus 的 Target 状态，确保所有 exporter 都是 UP
- 在 Grafana 上随便拉几个图表，看看数据有没有正常采集
- 用 curl 手动发几个请求，确认应用能正常响应
- 跑一个低并发（比如10个线程）的压测，看看基础延迟
我曾经有一次，Prometheus 配置写错了，targets 的 IP 少写了一个数字，结果监控面板上全是空白。跑完一轮压测才发现，数据全丢了。嗯，从那以后，我每次都会先验证监控数据是否正常。
我的习惯： 写一个环境验证脚本，一键检查所有组件。包括端口是否监听、服务是否健康、监控数据是否正常。压测前跑一遍，心里踏实。
好了，环境搭建这部分就到这里。硬件、软件、网络、监控，四个维度都讲清楚了。下一节咱们开始讲脚本编写，那才是真正有意思的部分。