3. 环境搭建：压测机器配置、网络带宽评估、被压测服务部署、监控工具搭建

好，咱们进入第三章。环境搭建这块，说实话，是整场压测的基石。我见过太多团队，压测脚本写得花里胡哨，结果环境一跑就露馅——要么压测机自己先扛不住了，要么网络成了瓶颈，要么监控数据全是毛刺。说白了，地基没打牢，楼盖得再高也白搭。

这一章，我带你一步步把环境捋清楚。咱们从压测机器怎么配开始，到网络带宽怎么评估，再到被压测服务怎么部署，最后把 Prometheus + Grafana 这对黄金搭档搭起来。嗯，跟着我的节奏来，别急。

3.1 压测机器配置：别让工具拖后腿

压测机器，就是发压力的那台机器。很多人觉得随便找台服务器就行，其实不然。你想想看，如果压测机自己 CPU 都 100% 了，那发出去的请求还能准吗？

我个人习惯，压测机至少满足以下配置：

• CPU：8 核以上，主频 3.0GHz 以上。高频比多核更重要，因为压测工具（比如 wrk、locust）很多是单线程模型。
• 内存：16GB 起步。如果压测场景复杂，比如要记录每个请求的响应时间，内存消耗会很大。
• 磁盘：SSD，至少 500GB。压测日志和结果文件写起来很快，机械盘扛不住。
• 网络：千兆网卡起步，最好是万兆。这个后面细说。

3.2 网络带宽评估：别让网线成了瓶颈

网络带宽，是压测里最容易忽略的坑。你想想看，压测机发请求，被压服务回响应，数据都在网线上跑。如果带宽不够，那延迟和丢包就来了。

怎么评估？ 我一般用这个公式：

所需带宽 = 预估 QPS × 平均请求包大小 × 8（bit 转换）

举个例子：

• 预估 QPS = 10000
• 平均请求包大小 = 1KB（1024 字节）
• 所需带宽 = 10000 × 1024 × 8 = 81.92 Mbps

看起来千兆网卡（1000 Mbps）绰绰有余？别急，这只是请求方向。响应方向呢？如果响应包是 10KB，那带宽需求直接翻 10 倍，变成 819.2 Mbps。再加上网络开销、TCP 重传等因素，千兆网卡可能就吃紧了。

我的建议：

• 压测机和被压服务之间，尽量走同一台交换机，减少跳数。
• 如果条件允许，用万兆网卡 + 万兆交换机。
• 压测前，用 iperf 或 netperf 跑一下，确认实际带宽。

3.3 被压测服务部署：稳定是第一要义

被压测的服务，部署方式直接影响结果。我见过有人直接在开发环境压测，结果服务时不时重启一下，数据全废了。

部署要点：

• 独立环境：被压服务最好部署在独立的机器或容器里，不要跟其他服务混跑。
• 资源隔离：如果用了 Docker，记得限制 CPU 和内存，避免资源争抢。
• 日志级别：压测时把日志级别调到 WARN 或 ERROR，别让 INFO 日志刷爆磁盘。
• JVM 参数：如果是 Java 服务，记得调好堆内存和 GC 参数。我一般用 -Xms4g -Xmx4g -XX:+UseG1GC 起步。

3.4 监控工具搭建：Prometheus + Grafana

没有监控的压测，就像闭着眼睛开车。你只知道车在跑，但不知道是快是慢、有没有跑偏。Prometheus 负责采集数据，Grafana 负责展示，这俩是绝配。

3.4.1 Prometheus 搭建

Prometheus 的安装很简单，我一般用 Docker 部署：

docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus

配置文件 prometheus.yml 长这样：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'my-service'
    static_configs:
      - targets: ['192.168.1.100:8080']

这里 targets 就是被压服务的地址。如果服务暴露了 Prometheus 指标接口（比如 /metrics），Prometheus 就会定期去抓数据。

3.4.2 Grafana 搭建

Grafana 同样用 Docker 部署：

docker run -d \
  --name grafana \
  -p 3000:3000 \
  grafana/grafana

启动后，浏览器访问 http://localhost:3000，默认账号密码都是 admin。进去之后，先添加 Prometheus 数据源：

• 点击左侧齿轮图标 → Data Sources → Add data source
• 选择 Prometheus，URL 填 http://localhost:9090
• 点击 Save & Test，看到绿色提示就成功了

然后就可以创建 Dashboard 了。我一般会加这几个面板：

• QPS：rate(http_requests_total[1m])
• 响应时间：histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1m]))
• 错误率：rate(http_requests_total{status=~"5.."}[1m]) / rate(http_requests_total[1m])
• CPU/内存：从 node_exporter 或 cAdvisor 拿数据

3.4.3 整体架构图

下面这张图，是我压测环境的标准架构。你一看就明白了：

你看，压测机发请求到被压服务，被压服务暴露 /metrics 接口，Prometheus 定期去抓，Grafana 再从 Prometheus 拉数据展示。整个链路清晰明了。

3.5 验证环境：跑一次冒烟测试

环境搭好了，别急着上量。先跑一次冒烟测试，确认所有组件都正常：

1. 启动被压服务，确认 /metrics 接口能返回数据。
2. 启动 Prometheus，在浏览器访问 http://localhost:9090/targets，确认 target 状态是 UP。
3. 启动 Grafana，添加数据源，创建一个简单的 QPS 面板，看看有没有数据。
4. 用压测工具发几个请求，确认 Grafana 面板上的数字在跳动。

好了，环境搭建就到这里。你按照这个步骤来，应该不会出大问题。记住，压测环境越接近生产，结果越有参考价值。别偷懒，该配的配，该测的测。

想要更多资料，联系可可