4. 压测工具选型：wrk、hey、vegeta、k6 对比、选择标准与适用场景
在 Go Web 服务契约压测中，工具选型直接影响测试效率、结果可信度与团队协作成本。本章对四款主流开源压测工具——wrk、hey、vegeta、k6——进行系统性对比，并给出基于契约压测场景的选择标准。
4.1 工具概览与核心定位
| 工具 | 语言 | 并发模型 | 脚本能力 | 结果输出 | 社区活跃度 |
|---|---|---|---|---|---|
| wrk | C + LuaJIT | 多线程 + epoll/kqueue | Lua 脚本（有限） | 终端表格 | 高（维护缓慢） |
| hey | Go | goroutine + 通道 | 无 | 终端表格 | 中 |
| vegeta | Go | 固定速率 + worker 池 | 无（纯 CLI） | 二进制/文本/JSON | 高 |
| k6 | Go (内核) + JavaScript | VU 虚拟用户 + 事件循环 | JavaScript ES6 | JSON / 云端 / 实时仪表盘 | 极高（Grafana 生态） |
契约压测视角： 工具对 HTTP 方法、Header、Body 的灵活控制能力，以及是否支持断言和阈值检查，是选型的关键分水岭。
4.2 四维对比：性能、易用性、可编程性、可观测性
4.2.1 性能与资源消耗
- wrk：单机压测性能之王。利用多线程 + 原生 epoll，单机可轻松打满 10 万 QPS。适合纯吞吐量摸底。
- hey：Go 原生实现，性能接近 wrk 的 70%~80%，但内存占用更低。适合快速验证。
- vegeta：固定速率模型，性能稳定但峰值略低于 wrk。适合持续负载测试。
- k6：VU 模型有额外 JS 引擎开销，单机极限约 3~5 万 QPS。但分布式扩展能力强。
4.2.2 易用性与上手成本
| 工具 | 安装方式 | 典型命令长度 | 学习曲线 |
|---|---|---|---|
| wrk | 源码编译 / brew | 短（1~2 行） | 低 |
| hey | go install / 二进制 | 极短（1 行） | 极低 |
| vegeta | go install / 二进制 | 中（2~3 行管道） | 中 |
| k6 | 二进制 / Docker | 长（需写 JS 脚本） | 中高 |
4.2.3 可编程性与契约验证
- wrk：通过 Lua 脚本可定制请求构造和响应处理，但无法做复杂断言。
- hey：无脚本能力，仅支持固定 URL 和 Header。
- vegeta：无脚本能力，但可通过管道组合 jq 做后处理。
- k6：唯一支持契约断言的工具。可在 JS 脚本中直接检查状态码、响应体字段、响应时间阈值，并支持自定义指标。
// k6 契约断言示例
import http from 'k6/http';
import { check, sleep } from 'k6';
export default function () {
const res = http.post('http://api.example.com/users', JSON.stringify({
name: 'test',
email: 'test@example.com'
}), { headers: { 'Content-Type': 'application/json' } });
check(res, {
'status is 201': (r) => r.status === 201,
'response has id': (r) => JSON.parse(r.body).id !== undefined,
'response time < 200ms': (r) => r.timings.duration < 200,
});
sleep(1);
}
4.2.4 可观测性与报告
| 工具 | 实时输出 | 历史报告 | 集成能力 |
|---|---|---|---|
| wrk | 终端表格 | 无 | 低 |
| hey | 终端表格 | 无 | 低 |
| vegeta | 终端 + JSON 流 | 支持（二进制存储） | 中（可管道至 InfluxDB） |
| k6 | 实时仪表盘 + 终端 | 支持（JSON / 云端） | 高（Grafana / Prometheus / Datadog） |
4.3 选择标准与适用场景矩阵
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| REST API 契约压测（含断言） | k6 | 原生支持状态码、响应体、响应时间断言；可集成到 CI/CD |
| 单接口吞吐量极限摸底 | wrk | 多线程 epoll 模型，单机性能最高；Lua 可定制请求 |
| 开发阶段快速验证 | hey | 一行命令启动，零配置；适合临时调试 |
| 持续负载测试（SLA 验证） | vegeta | 固定速率模型稳定；支持二进制存储和报告生成 |
| 分布式压测 / 云端执行 | k6 | 原生支持 k6 Cloud / 分布式执行；Grafana 生态 |
| 复杂业务场景编排 | k6 | JS 脚本支持多步骤、条件分支、自定义指标 |
4.4 契约压测场景下的工具选型建议
核心结论：对于《Go Web 服务契约压测》课程，k6 是首选工具，原因如下：
- 唯一支持在压测过程中直接编写契约断言的工具。
- 输出结构化 JSON 结果，便于后续分析和报告生成。
- 与 Grafana 生态深度集成，可构建实时监控仪表盘。
- 支持 CI/CD 流水线集成（Jenkins / GitHub Actions / GitLab CI）。
避坑提示：不要用 wrk 或 hey 做契约验证。它们只输出吞吐量和延迟分布，无法判断响应内容是否符合契约。如果团队已在使用 vegeta，可结合 jq 做后处理断言，但维护成本远高于 k6。
4.5 工具组合推荐
在实际项目中，建议采用 k6 + wrk 的组合策略：
- k6：负责日常契约压测、CI 门禁、SLA 验证。
- wrk：负责性能极限摸底、容量规划、调优前后对比。
这种组合既能保证契约正确性，又能掌握性能天花板，是 Go 微服务压测的最佳实践。