上线前负载测试

先建模，再测量

只对一个端点均匀打请求的压测产生的是一个数字，不是容量答案。应建模用户真实执行的旅程，包含真实负载大小、思考时间与认证。

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

步骤

1. 识别关键用户旅程、请求组合、负载大小与预期峰值 RPS，包含思考时间与认证。
2. 先做低负载基线测试，确认系统健康且测试工具本身不是瓶颈。
3. 分阶段升到预期峰值并继续加压，观察错误率、p95/p99 延迟与依赖上限，定位第一个瓶颈。
4. 对照 SLO 分析结果，修复瓶颈或调整容量后重跑失败阶段。
5. 突然卸载并确认系统回到基线，没有残留错误、队列或泄漏连接。

验证

• 预期峰值下 p95/p99 与错误率在 SLO 内。
• 饱和点高于峰值并留有明确余量。
• 数据库连接等依赖限制被遵守。
• 卸载后指标在定义窗口内恢复基线。
• 结果与容量决策随发布记录归档。

决策点

优先使用与生产隔离的预发环境；只有在有严格保护、合成身份和随时停止能力时才在生产压测。通过标准应是 SLO 加余量，而不是“测试期间没有错误”。

陷阱

使用无隔离的生产数据、忽略思考时间、把一次成功运行当作容量证明。还应测试故障路径：依赖变慢或不可用时，系统在高负载下会发生什么。