3. 测试环境搭建：独立压测环境要求、数据隔离策略、Mock服务搭建、监控系统部署

好，咱们进入第三章。环境搭建这块，说实话，是压测里最容易出幺蛾子的环节。我见过太多团队，压测环境跟生产环境混在一起，结果压着压着把线上业务给压崩了。嗯，咱们今天就把这事掰扯清楚。

3.1 独立压测环境要求

为什么要独立？说白了，压测本身就是一种「暴力测试」。你想想看，几万甚至几十万的QPS打过去，网络带宽、CPU、内存都会被瞬间拉满。如果跟其他环境共用，那后果就是大家一起崩。

硬件隔离要求：

• 独立服务器/容器集群：压测节点、被压服务、数据库、缓存，全部独立部署。我个人习惯用K8s的独立命名空间，配合资源配额限制。
• 网络隔离：压测流量不能跑到生产网段。VLAN或者独立子网，这是底线。
• 数据存储隔离：压测用的数据库实例，跟开发、测试、预发环境完全分开。我在项目中遇到过，有人把压测数据写到了预发库，结果预发环境的数据全乱了。

软件环境要求：

• 版本一致性：中间件版本、JDK版本、操作系统内核参数，尽量跟生产保持一致。否则压出来的数据没有参考价值。
• 资源预留：压测期间，被压服务独占资源。别让其他任务来抢CPU。
• 快速重建能力：压测环境要能一键销毁、一键重建。我一般用Terraform+Ansible搞定。

3.2 数据隔离策略

数据隔离，是风控压测里最头疼的事。风控系统依赖大量历史数据做规则计算，比如用户画像、设备指纹、交易流水。这些数据如果混在一起，压测结果根本不准。

我常用的三种隔离方式：

隔离方式	适用场景	优缺点
逻辑隔离（Schema/表前缀）	小规模压测，数据量<100万	优点：部署简单；缺点：清理麻烦，容易残留
物理隔离（独立数据库实例）	中大规模压测，数据量100万-1亿	优点：彻底隔离，不影响其他环境；缺点：成本高
数据脱敏+影子表	生产数据脱敏后用于压测	优点：数据真实；缺点：脱敏过程复杂

避坑指南：我曾经在压测时，直接用生产库的备份数据，结果忘了脱敏。压测报告里直接出现了真实用户的手机号。嗯，从那以后，我强制要求所有压测数据必须经过脱敏流水线。

数据清理策略：

• 压测前：全量清理，重新灌入基准数据。
• 压测中：定时清理中间表，防止数据膨胀。
• 压测后：一键销毁整个环境。

3.3 Mock服务搭建

风控系统依赖的外部服务太多了：第三方征信、黑名单库、设备指纹服务。压测时如果全部调用真实服务，一来对方扛不住，二来费用也扛不住。所以，Mock是必须的。

Mock的核心原则：

• 响应速度要快：Mock服务的延迟必须稳定，不能成为瓶颈。
• 返回值要可控：能模拟正常、异常、超时等各种场景。
• 支持动态配置：压测过程中能随时调整Mock行为。

我常用的Mock方案：

# 使用WireMock搭建Mock服务
# 1. 启动WireMock服务
java -jar wiremock-standalone-3.0.0.jar --port 8089

# 2. 配置Mock映射（JSON格式）
{
  "request": {
    "method": "POST",
    "url": "/api/risk/blacklist/check"
  },
  "response": {
    "status": 200,
    "jsonBody": {
      "code": 0,
      "data": {
        "is_black": false,
        "risk_level": "low"
      }
    },
    "fixedDelayMilliseconds": 50
  }
}

# 3. 动态调整延迟（模拟网络抖动）
curl -X POST http://localhost:8089/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": { "urlPattern": "/api/risk/.*" },
    "response": { "fixedDelayMilliseconds": 200 }
  }'

Mock场景覆盖清单：

• 正常响应（200，返回预期数据）
• 异常响应（500，服务不可用）
• 超时响应（延迟超过阈值）
• 限流响应（429，Too Many Requests）
• 空数据响应（返回空列表或null）

3.4 监控系统部署（Prometheus+Grafana）

压测没有监控，就像开车没有仪表盘。你根本不知道系统什么时候会崩。我个人习惯，在压测开始前，监控系统必须已经稳定运行至少10分钟。

监控架构图：

Prometheus部署要点：

# prometheus.yml 核心配置
global:
  scrape_interval: 5s  # 压测期间建议5秒，生产环境可以15秒
  evaluation_interval: 5s

scrape_configs:
  - job_name: 'risk-service'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['192.168.1.100:8080', '192.168.1.101:8080']
  
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['192.168.1.100:9100', '192.168.1.101:9100']

Grafana仪表盘关键指标：

• QPS曲线：实时查看吞吐量变化
• 响应时间分布：P50、P90、P99、P999
• 错误率：5xx、4xx、超时、限流
• 系统资源：CPU、内存、网络IO、磁盘IO
• GC情况：Young GC频率、Full GC次数、GC暂停时间

告警规则示例：

# 告警规则：响应时间超过1秒
- alert: HighResponseTime
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1m])) > 1
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "P99响应时间超过1秒"
    description: "当前P99响应时间: {{ $value }}s"

# 告警规则：错误率超过5%
- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[1m]) / rate(http_requests_total[1m]) > 0.05
  for: 30s
  labels:
    severity: warning
  annotations:
    summary: "错误率超过5%"
    description: "当前错误率: {{ $value | humanizePercentage }}"

好了，环境搭建这块就这些。记住一句话：环境搭得越稳，压测数据越可信。别图省事，该隔离的隔离，该Mock的Mock，该监控的监控。后面咱们就要开始真正的压测执行了。

---