2. 测试环境搭建：硬件资源规划、网络拓扑设计、数据库与中间件选型、监控工具部署（Prometheus + Grafana）
好，咱们进入第二章。环境搭建这事儿，说简单也简单，说复杂能让你折腾一礼拜。我见过太多团队，上来就写脚本压测，结果跑起来才发现网络带宽打满了，或者数据库连接池爆了。嗯，这章咱们就把地基打牢。
核心原则：测试环境要尽量模拟生产，但不必完全复制。关键是把瓶颈点暴露出来，而不是把环境搭成生产环境的缩水版。
2.1 硬件资源规划：别让机器拖后腿
我个人习惯，先算一笔账。你要压测的并发交易系统，峰值TPS是多少？假设目标是5000 TPS，每个请求平均耗时50ms，那系统同时处理的请求数大约是5000 × 0.05 = 250个。这250个请求，CPU、内存、网络IO怎么分配？
我建议按这个思路来：
- 压测机：至少2台，每台4核8G起步。一台跑主控脚本，一台跑负载生成器。别把压测机和被测服务放同一台机器，否则压测本身就把资源吃光了，测出来的数据全是噪音。
- 应用服务器：根据你的服务拆分情况来。如果是单体应用，4核8G够用；如果是微服务，每个服务至少2核4G。我在项目中遇到过，一个网关服务因为内存分配太小，压测时频繁GC，导致TPS上不去，排查了半天才发现是JVM参数没调。
- 数据库服务器：这是大头。建议8核16G起步，SSD硬盘是必须的。你想想看，交易系统最怕什么？磁盘IO打满。我曾经见过一个项目，压测到一半数据库磁盘IO 100%，所有请求都卡住了。后来换了NVMe SSD，问题才解决。
- 网络：千兆网卡是底线。如果压测机和服务器的网络延迟超过1ms，你就要检查是不是交换机瓶颈了。
| 角色 | CPU | 内存 | 磁盘 | 数量 |
|---|---|---|---|---|
| 压测机 | 4核 | 8G | SSD 256G | 2 |
| 应用服务器 | 4核 | 8G | SSD 512G | 2~4 |
| 数据库服务器 | 8核 | 16G | NVMe 1T | 1主2从 |
| 监控服务器 | 2核 | 4G | SSD 256G | 1 |
小技巧：压测机的内存要留够。因为压测工具（比如Locust或JMeter）会在内存里缓存大量请求结果，内存不够会导致压测本身变慢，影响结果准确性。
2.2 网络拓扑设计：画清楚数据怎么流
网络拓扑说白了，就是数据从哪来、到哪去、中间经过哪些节点。我习惯先画一张图，把每个组件的IP、端口、协议都标清楚。
画完图你会发现，网络瓶颈往往出在交换机上。我遇到过一个问题：压测时TPS始终上不去，排查发现交换机端口配置了流量限制，千兆口实际只能跑100M。所以，记得检查交换机的端口配置，别让硬件限制软件。
注意：压测机和被测服务之间不要经过防火墙或负载均衡器（除非你要测的就是这些组件）。中间每多一层，延迟和丢包的概率就多一分，干扰你定位真正的性能瓶颈。
2.3 数据库与中间件选型：选对工具，事半功倍
数据库选型这事儿，我踩过不少坑。交易系统对数据一致性要求高，所以关系型数据库是首选。我个人推荐MySQL 8.0+或PostgreSQL 14+，原因很简单：社区活跃、文档齐全、踩坑经验多。
中间件方面，看你的业务场景：
- 消息队列：Kafka适合高吞吐场景，但延迟稍高；RabbitMQ适合低延迟场景，但吞吐量不如Kafka。我建议，如果TPS超过1万，用Kafka；如果对延迟敏感（比如要求P99 < 10ms），用RabbitMQ。
- 缓存：Redis是标配。注意，压测时一定要监控Redis的命中率，如果命中率低于90%，说明缓存设计有问题，压测结果会失真。
- 连接池：HikariCP（Java）或psycopg2（Python）的默认配置往往偏保守。我在项目中遇到过，默认连接池只有10个，压测时大量请求排队等待连接，TPS直接腰斩。记得根据压测目标调整连接池大小。
避坑指南：我曾经在压测前忘了检查数据库的最大连接数限制。MySQL默认是151个，压测一启动，连接数瞬间打满，后面的请求全部报错。所以，压测前一定要检查max_connections、open_files_limit这些参数。
2.4 监控工具部署：Prometheus + Grafana
没有监控的压测，就像闭着眼睛开车。你只知道车在跑，但不知道是快是慢、有没有跑偏。我习惯用Prometheus采集数据，Grafana展示数据。这套组合拳，业界公认好用。
部署步骤其实不复杂：
- 安装Prometheus：下载二进制包，解压就能用。配置文件prometheus.yml里，定义好要抓取的目标（比如应用服务器的/metrics接口）。
- 安装Grafana：同样下载解压，默认端口3000。第一次登录，用户名密码都是admin。
- 配置数据源：在Grafana里添加Prometheus数据源，URL填Prometheus的地址（比如http://192.168.1.40:9090）。
- 导入仪表盘：Grafana社区有现成的仪表盘模板，比如Node Exporter Full（ID: 1860），导入后就能看到CPU、内存、磁盘、网络等基础指标。
但光有基础指标不够。交易系统压测，你还要关注：
- TPS和响应时间：用Histogram类型记录请求耗时，Grafana里用heatmap展示P50、P90、P99。
- 错误率：记录HTTP 5xx和业务错误码，一旦错误率超过1%，立即告警。
- 数据库连接数：监控活跃连接数和等待连接数，连接池打满往往是性能瓶颈的前兆。
# Prometheus 配置示例
scrape_configs:
- job_name: 'trade-service'
static_configs:
- targets: ['192.168.1.20:8080', '192.168.1.21:8080']
metrics_path: '/actuator/prometheus'
- job_name: 'node-exporter'
static_configs:
- targets: ['192.168.1.20:9100', '192.168.1.21:9100', '192.168.1.30:9100']注意：Prometheus的抓取间隔默认是15秒，对于高并发压测来说太长了。我建议改成5秒，甚至1秒。但要注意，抓取频率越高，Prometheus本身的资源消耗也越大。如果监控服务器只有2核4G，建议保持5秒间隔。
嗯，环境搭建这部分就这些。说白了，硬件规划是骨架，网络拓扑是血管，数据库和中间件是器官，监控工具是神经系统。四者缺一不可。下一节咱们开始写压测脚本，到时候你会感谢今天把环境搭得这么扎实。
总结：环境搭建不是一次性工作。压测过程中，你可能需要调整硬件配置、优化网络参数、更换中间件版本。保持灵活，随时准备调整。