3. 压测环境搭建：硬件资源规划、网络拓扑、监控工具部署
压测环境搭建，说白了就是给你的压测找个「战场」。
我见过太多团队，代码写得挺漂亮，结果压测环境一跑就崩。不是硬件不够，就是网络瓶颈，要么监控数据根本看不懂。嗯，今天咱们就把这事掰扯清楚。
3.1 硬件资源规划：别让机器拖后腿
硬件规划这事，我个人的习惯是「先算后配」。别上来就买最高配，也别抠抠搜搜搞个最低配。
核心原则：压测机的性能至少是被测系统的 2 倍以上。否则你测出来的不是系统瓶颈，是压测机自己的瓶颈。
具体怎么算？我一般分三步走：
- 估算并发量：根据业务峰值，预估最大并发用户数。比如双十一的 10 万并发。
- 计算资源需求：每个虚拟用户大概需要多少 CPU、内存。我做过一个电商项目，每个用户线程大约占 50MB 内存，1000 并发就是 50GB。
- 留出余量：至少留 30% 的余量。为什么？因为压测过程中，监控工具本身也要吃资源。
| 组件 | 推荐配置 | 说明 |
|---|---|---|
| 压测机（JMeter/Locust） | 8核CPU / 32GB内存 / SSD | 单机可支撑 2000-5000 并发 |
| 被测应用服务器 | 4核CPU / 16GB内存 | 根据业务复杂度调整 |
| 数据库服务器 | 8核CPU / 64GB内存 / 高速SSD | IO 往往是瓶颈 |
| 监控服务器（Prometheus+Grafana） | 4核CPU / 16GB内存 | 数据量大的话要加磁盘 |
注意：我曾经在一个项目中，压测机用了机械硬盘。结果压到 2000 并发时，磁盘 IO 直接打满，压测结果全是假的。后来换了 SSD，问题立刻解决。
3.2 网络拓扑：画清楚你的数据流
网络拓扑这事，很多人不重视。你想想看，压测数据从压测机到服务器，中间经过多少跳？每跳都可能成为瓶颈。
我个人习惯先画一张拓扑图，把每个节点的 IP、端口、带宽都标清楚。下面这张图是我常用的压测网络拓扑结构：
画完拓扑图，你就能清楚看到数据流走向。我建议重点关注三个地方：
- 压测机到交换机：带宽够不够？延迟高不高？
- 交换机到应用服务器：有没有丢包？
- 应用服务器到数据库：连接池够用吗？
小技巧：压测机和被测系统最好在同一个网段。跨网段的话，延迟会明显增加。我之前有个项目，压测机在办公网，服务器在机房，中间隔了 5 跳，结果延迟多了 20ms，数据完全没法用。
3.3 监控工具部署：Prometheus + Grafana
监控工具，说白了就是你的「眼睛」。没有监控，压测就是盲人摸象。
我个人最喜欢 Prometheus + Grafana 这套组合。为什么？因为它开源、灵活、生态好。你想想看，Prometheus 负责采集数据，Grafana 负责展示，分工明确。
3.3.1 Prometheus 部署
Prometheus 的部署其实很简单。我一般用 Docker 来跑，省心省力。
# 拉取 Prometheus 镜像
docker pull prom/prometheus:latest
# 创建配置文件 prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.2.10:9100', '192.168.2.20:9100']
- job_name: 'jmeter'
static_configs:
- targets: ['192.168.1.10:9270']
# 启动 Prometheus
docker run -d \
--name prometheus \
-p 9090:9090 \
-v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus这里要注意，Prometheus 默认只保留 15 天的数据。如果你要做长时间压测，记得调整 --storage.tsdb.retention.time 参数。
避坑指南：我曾经在一次压测中，Prometheus 的磁盘写满了，导致监控数据全部丢失。后来我加了磁盘告警，再也没出过这个问题。
3.3.2 Grafana 部署
Grafana 的部署同样简单。我习惯用 Docker Compose 把 Prometheus 和 Grafana 一起启动。
# docker-compose.yml
version: '3'
services:
prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin123
volumes:
- grafana_data:/var/lib/grafana
volumes:
grafana_data:启动之后，访问 http://localhost:3000，默认账号密码是 admin/admin。然后添加 Prometheus 数据源，地址填 http://prometheus:9090。
3.3.3 关键监控指标
监控指标那么多，到底看哪些？我总结了一个「黄金指标」清单：
| 指标类别 | 具体指标 | 告警阈值 |
|---|---|---|
| CPU | node_cpu_seconds_total | 使用率 > 80% |
| 内存 | node_memory_MemAvailable_bytes | 可用内存 < 20% |
| 磁盘 IO | node_disk_io_time_seconds_total | IO 等待 > 30% |
| 网络 | node_network_receive_bytes_total | 带宽使用率 > 70% |
| 应用 | http_requests_total | 错误率 > 1% |
个人经验：别只看平均值。我习惯把 P99 和 P999 也加上。为什么？因为平均值会骗人。有一次压测，平均响应时间才 200ms，但 P99 已经到 5 秒了。如果只看平均值，你根本发现不了问题。
3.3.4 配置告警规则
光有监控还不够，你得让系统在出问题时主动通知你。Prometheus 的 Alertmanager 就是干这个的。
# alert_rules.yml
groups:
- name: node_alerts
rules:
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "CPU 使用率超过 80%"
description: "实例 {{ $labels.instance }} 的 CPU 使用率已超过 80%，当前值 {{ $value }}%"配置好之后，你可以把告警推送到钉钉、企业或者邮件。我个人习惯用钉钉，因为手机能直接收到通知，方便及时处理。
3.4 环境验证：别等到压测才发现问题
环境搭好了，别急着跑压测。先做一轮「冒烟测试」，验证一下：
- 压测机能 ping 通所有服务器吗？
- 端口能正常访问吗？
- 监控数据能正常采集吗？
- Grafana 面板能正常显示吗？
我见过最离谱的一次，环境搭了三天，结果压测时发现防火墙把压测端口给封了。嗯，从那以后，我每次都会先跑一个简单的 curl 命令验证一下。
# 验证应用服务器是否正常
curl -I http://192.168.2.10:8080/health
# 验证 Prometheus 是否正常采集数据
curl http://localhost:9090/api/v1/query?query=up总结一下：压测环境搭建，硬件是基础，网络是通道，监控是眼睛。这三样东西，缺一个都不行。我建议你花 70% 的时间在环境搭建上，30% 的时间在压测执行上。环境稳了，压测结果才有说服力。