4. 测试环境搭建：硬件环境、软件环境、网络环境、监控工具部署
说实话，很多团队做性能测试，脚本写得挺漂亮，场景设计也合理，结果一跑数据，全废了。为什么？环境没搭好。我见过太多人在这上面栽跟头，包括我自己。今天咱们就把这块掰开揉碎了讲清楚。
4.1 硬件环境：别让机器拖后腿
硬件环境是性能测试的底座。底座不稳，上面盖什么都白搭。我个人习惯，在搭建之前先画一张拓扑图，把每台机器的角色标清楚。
核心原则：压测机、被压服务、监控服务，三者必须物理隔离。别图省事全塞一台机器上，那样测出来的数据你根本没法信。
硬件选型上，我一般这么配：
- 压测机：CPU 要强，内存要大。我常用 8 核 16G 起步。为什么？因为压测工具本身也要消耗资源，尤其是并发数上去以后。
- 被压服务：按生产环境的 1/4 或 1/2 来配。别上来就搞个 64 核的，你测的是性能，不是炫富。
- 监控服务器：4 核 8G 就够了。跑个 Prometheus + Grafana，绰绰有余。
我的小技巧：所有机器用同一批硬件型号。不同代的 CPU，性能差异能到 20% 以上。我在项目中遇到过，两台机器跑同一个接口，结果差了 30%，排查了半天才发现是 CPU 型号不一样。
4.2 软件环境：版本一致是底线
软件环境这块，说白了就一句话：跟生产环境保持一致。操作系统、中间件、数据库、JDK 版本，一个都不能差。
我建议用 Docker 或者虚拟机来管理。好处是快，坏了就删了重建。我曾经因为 JDK 版本差了 0.0.1，结果 GC 行为完全不一样，压测数据全废了。嗯，从那以后我再也不敢马虎了。
# 我的标准软件栈清单
操作系统: CentOS 7.9 / Ubuntu 20.04
JDK: OpenJDK 11.0.12
数据库: MySQL 8.0.28
中间件: Nginx 1.20.1 / Redis 6.2.6
压测工具: JMeter 5.5 / wrk 4.2.0
注意：别用最新版。最新版往往有坑。用生产环境已验证过的版本，稳才是第一位的。
4.3 网络环境：延迟和带宽都要管
网络环境是很多人容易忽略的点。你想想看，如果压测机和被压服务之间隔了 10 跳，延迟 50ms，那测出来的响应时间能信吗？
我一般这么搞：
- 同机房部署：压测机和被压服务放在同一个交换机下。延迟控制在 1ms 以内。
- 带宽预留：压测期间，别让其他服务抢带宽。我遇到过，压测跑着跑着，有人开始下载大文件，结果带宽被打满，TPS 直接腰斩。
- 防火墙规则：能关就关，不能关就配白名单。防火墙对性能的影响，比你想象的大。
避坑指南：我曾经在压测前忘了检查网卡速率。结果千兆网卡跑成了百兆，压测数据惨不忍睹。查了半天才发现是网线没插好。嗯，从那以后我每次压测前都会跑一遍 iperf 测带宽。
4.4 监控工具部署：没有监控，等于盲打
性能测试没有监控，就像开车没有仪表盘。你根本不知道车哪里出了问题。我常用的监控栈是 Prometheus + Grafana + Node Exporter，再加一个 APM 工具做链路追踪。
部署起来其实不复杂：
# 1. 安装 Node Exporter（每台机器都要装）
wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
tar -xzf node_exporter-1.3.1.linux-amd64.tar.gz
cd node_exporter-1.3.1.linux-amd64
./node_exporter &
# 2. 安装 Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.33.1/prometheus-2.33.1.linux-amd64.tar.gz
tar -xzf prometheus-2.33.1.linux-amd64.tar.gz
cd prometheus-2.33.1.linux-amd64
./prometheus --config.file=prometheus.yml &
# 3. 安装 Grafana
wget https://dl.grafana.com/oss/release/grafana-8.3.4.linux-amd64.tar.gz
tar -xzf grafana-8.3.4.linux-amd64.tar.gz
cd grafana-8.3.4.linux-amd64
./bin/grafana-server &
配置 Prometheus 的 prometheus.yml，把要监控的机器加进去：
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100', '192.168.1.12:9100']
然后去 Grafana 里导入一个 Node Exporter 的 Dashboard（ID 是 1860），就能看到 CPU、内存、磁盘、网络的全貌了。
我的习惯：除了系统指标，我还会监控 JVM 的 GC 情况、数据库的连接池、Redis 的命中率。这些指标在压测时能帮你快速定位瓶颈。
4.5 环境验证：搭完不等于能用
环境搭完了，别急着跑压测。先做一轮验证：
- 连通性测试：ping 一下，确保网络通。
- 端口测试：telnet 一下，确保服务端口能连上。
- 基础性能测试：用 wrk 或者 ab 跑一个简单的请求，看看基线数据是否合理。
- 监控数据验证：看看 Grafana 上有没有数据，指标是否正常。
重要：验证这一步不能省。我见过有人搭完环境直接跑压测，结果跑了半天发现监控没数据，白忙活一场。
4.6 知识体系总览
下面这张图，是我对测试环境搭建的总结。你照着这个框架来，基本不会出大问题。
这张图把整个环境搭建的脉络理清楚了。硬件是底座，软件是上层，网络是血管，监控是眼睛。四者缺一不可。
好了，这一章的内容就到这儿。记住一句话：环境搭得好，压测跑得稳。别图快，别偷懒，每一步都走扎实了，后面才能省心。