技能介绍

当 gRPC 负载测试变成重复劳动

gRPC 服务上线前，团队通常会写临时脚本跑一轮压力测试。但服务迭代几次后，proto 文件更新了，请求参数变了，测试脚本要么失效，要么只能覆盖最粗浅的场景。想验证一次真实的容量规划，你得手动构造各种边界请求，控制并发数，再从一堆日志里扒延迟和错误率。更糟的是，这些脚本往往散落在个人电脑里，换个人接手就得从头理解。

重复造轮子的代价不只是时间，还有测试本身的可靠性。手工拼装的请求缺少统一的 fixture 管理，回归对比几乎不可能，新引入的性能退化常常被当成"正常波动"。

这个技能做了什么

该技能基于 ghz 工具，把 gRPC 负载测试拆成三个可控的输入：

接口描述来源：直接读取 .proto 文件、预编译的 .protoset 包，或通过服务反射自动发现接口。这意味着你不需要手写任何消息结构。
请求 fixture：将代表性请求数据组织成可复用的文件，测试时按需加载和重放。支持在单轮测试中混合多个 fixture，模拟真实流量组合。
执行控制：通过参数控制并发连接数、总请求量、持续时间等，而非一刀切地打满。

执行后，技能会收集延迟分布、错误率、吞吐量等指标，并输出机器可读的报告。这份报告可以直接接入回归流程，用来对比不同版本间的性能差异，或者在性能排查时提供基线数据。

适用边界与注意点

需要可用的服务端点：该技能只负责发起请求，不会替你启动或 mock gRPC 服务。你的目标服务必须已经处于可连接状态，且 proto 定义与实际接口一致。
反射并非万能：如果服务端未开启 reflection 服务，你需要自行提供 proto 文件或 protoset 包。否则工具无法推断消息结构。
fixture 质量决定测试质量：技能不会帮你生成业务数据。fixture 的覆盖范围、数据真实性直接影响测试结果的参考价值。建议从生产环境日志或服务端请求记录中提取样本。
指标粒度有限：ghz 提供的延迟统计基于客户端视角，不包含服务端内部处理耗时。如果需要服务端监控数据，仍需配合服务端的 metrics 或 tracing 体系。