3. 压测工具选型：wrk、hey、vegeta、ghz（gRPC）、自研压测框架对比

在尾延迟诊断场景中，压测工具的选择直接影响测试结果的准确性和可复现性。不同的工具在并发模型、协议支持、统计输出、资源开销等方面存在显著差异。本章对主流压测工具进行系统性对比，帮助你在不同场景下做出合理选型。

3.1 工具概览与核心定位

以下表格从协议支持、并发模型、统计能力、适用场景四个维度对五类工具进行横向对比：

3.2 工具深度对比

3.2.1 wrk：高性能 HTTP 压测标杆

wrk 使用 C 语言编写，基于多线程和 epoll/kqueue 事件驱动模型，能够在单机上产生极高的并发压力。其核心优势在于：

• 极低资源开销： 单线程可管理数万个连接，适合大规模并发场景。
• Lua 脚本扩展： 支持自定义请求构造、响应处理、延迟记录。
• 实时统计输出： 测试过程中实时显示延迟平均值和标准差。

典型用法示例：

# 30秒压测，16个线程，100个连接
wrk -t16 -c100 -d30s --latency http://target:8080/api

# 使用Lua脚本自定义请求
wrk -t4 -c50 -d10s -s custom.lua http://target:8080/api

3.2.2 hey：Go 生态的轻量压测工具

hey 由 Go 语言编写，利用 goroutine 实现并发，安装简单，适合快速验证。其特点包括：

• 零依赖： 单二进制文件，无需安装运行时。
• 内置直方图： 输出延迟分布直方图，便于直观观察延迟分布。
• 支持自定义 Header 和 Body： 通过命令行参数灵活构造请求。

典型用法：

# 100个并发，总共发送1000个请求
hey -n 1000 -c 100 -h2 http://target:8080/api

# 输出详细延迟分布
hey -n 5000 -c 50 -o csv http://target:8080/api

3.2.3 vegeta：恒定速率压测与 SLA 验证

vegeta 的设计理念是“恒定攻击速率”，而非“最大并发”。它通过攻击器（attacker）以固定速率发送请求，适合模拟真实用户流量。核心特性：

• 速率控制： 精确控制每秒请求数（RPS），支持线性/指数递增。
• 实时报告： 支持终端实时显示延迟百分位和吞吐量。
• 结果导出： 支持 JSON、CSV、直方图等多种输出格式。

典型用法：

# 以每秒500请求的速率压测30秒
echo "GET http://target:8080/api" | vegeta attack -rate=500 -duration=30s | vegeta report

# 输出百分位延迟报告
echo "GET http://target:8080/api" | vegeta attack -rate=1000 -duration=60s | vegeta report -type=text

3.2.4 ghz：gRPC 压测专用工具

ghz 是专为 gRPC 服务设计的压测工具，支持一元调用、服务端流、客户端流和双向流四种模式。其关键能力：

• Protobuf 原生支持： 直接读取 .proto 文件构造请求。
• 流式压测： 支持 gRPC 流式接口的持续压测。
• 元数据注入： 支持自定义 gRPC metadata 和超时设置。

典型用法：

# 一元调用压测，100个并发，持续30秒
ghz --insecure \
    --proto ./api.proto \
    --call mypackage.MyService.UnaryCall \
    -d '{"name": "test"}' \
    -c 100 -z 30s \
    target:50051

# 输出详细延迟分布
ghz --insecure \
    --proto ./api.proto \
    --call mypackage.MyService.UnaryCall \
    -d '{"name": "test"}' \
    -c 50 -n 10000 \
    --format=pretty \
    target:50051

3.2.5 自研压测框架：应对复杂场景的终极方案

当现有工具无法满足以下需求时，自研压测框架成为必要选择：

• 自定义协议： 如 WebSocket、MQTT、私有 TCP/UDP 协议。
• 复杂业务逻辑： 需要模拟多步骤事务、条件分支、状态依赖。
• 全量延迟记录： 需要记录每次请求的完整时间戳，用于离线分析。
• 分布式压测： 需要多节点协同压测，汇总结果。

一个典型的 Go 自研压测框架结构如下：

// 核心压测引擎示例
type LoadTester struct {
    client    *http.Client
    rate      int           // 目标RPS
    duration  time.Duration // 压测时长
    results   chan *Result  // 结果通道
    stopCh    chan struct{} // 停止信号
}

func (lt *LoadTester) Run() {
    ticker := time.NewTicker(time.Second / time.Duration(lt.rate))
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            go lt.sendRequest()
        case <-lt.stopCh:
            return
        }
    }
}

func (lt *LoadTester) sendRequest() {
    start := time.Now()
    resp, err := lt.client.Get("http://target:8080/api")
    latency := time.Since(start)
    lt.results <- &Result{
        Latency: latency,
        Error:   err,
        Status:  resp.StatusCode,
    }
}

3.3 工具选型决策流程

以下 SVG 流程图展示了在不同场景下的工具选型决策路径：

3.4 尾延迟诊断场景下的工具选择建议

针对尾延迟诊断这一核心目标，不同工具在延迟精度和统计能力上存在差异：

3.5 工具选型总结

以下 SVG 图展示了各工具在“易用性”与“灵活性”两个维度上的定位：