性能调优指标与高并发实战¶

gRPC 拥有极其卓越的性能上限，但在高吞吐、大规模微服务集群中，若使用姿势不当（如频繁创建连接、流控窗口过小、消息体过大），依然可能成为系统的瓶颈。

1. 压测工具：`ghz` 快速基准测试¶

ghz 是 gRPC 领域事实上的基准压测工具（相当于 HTTP 领域的 ApacheBench 或 wrk）。

常用压测指令¶

# 模拟 50 并发、共 10,000 次请求压测本地服务
ghz --insecure \
  --proto=./api/v1/order.proto \
  --call=order.v1.OrderService.CreateOrder \
  -d '{"user_id":"benchmark-user","amount":99.0}' \
  -c 50 \
  -n 10000 \
  127.0.0.1:50051

关键输出指标解读¶

RPS（Requests Per Second）：每秒处理请求数，评估系统吞吐量。
P99 / P99.9 延迟：长尾延迟，直接反映系统在极端并发下的平稳性。

2. 核心性能调优维度¶

① 必须复用 Channel（通道池化管理）¶

致命反模式：在每次业务函数调用时新建 grpc.Dial，调用完成后 Close()。
这会导致每次 RPC 都要经历 TCP 三次握手、TLS 协商与 HTTP/2 SETTINGS 交换，产生极高的延迟并迅速耗尽操作系统本地临时端口（TIME_WAIT 爆炸）。
正确姿势：gRPC 的 ClientConn 是并发安全且长久保持的。全局只需维持一个实例；若单连接因网卡或单一 CPU 核心软中断达到极限（通常单连接承载 2万~4万 QPS），可建立包含 2~4 个连接的固定连接池（Connection Pool）。

② 流量控制窗口与 BDP 调优（Bandwidth-Delay Product）¶

HTTP/2 使用滑动窗口控制流速。默认流控窗口为 64KB。在跨地域或高带宽长延时网络中，小窗口会导致发送端频繁等待 WINDOW_UPDATE，无法跑满带宽。

在 Go 中调大窗口参数：

server := grpc.NewServer(
    // 单个 Stream 接收窗口调整为 4MB
    grpc.InitialWindowSize(4 * 1024 * 1024),
    // 整条 Connection 接收窗口调整为 16MB
    grpc.InitialConnWindowSize(16 * 1024 * 1024),
)

③ 消息大小限制与大包陷阱¶

gRPC 默认对接收单条消息设置了 4MB（4,194,304 字节） 的安全阈值。若超过会抛出错误：ResourceExhausted: Received message larger than max (xxx vs 4194304)。

如需调整：

opts := []grpc.DialOption{
    grpc.WithDefaultCallOptions(
        grpc.MaxCallRecvMsgSize(100 * 1024 * 1024), // 调至 100MB
        grpc.MaxCallSendMsgSize(100 * 1024 * 1024),
    ),
}

[!WARNING] 不要无节制地调大单条消息限制。过大的消息（如几十 MB 的大文件）在序列化时会导致内存瞬间翻倍，引发 GC 停顿（STW）。对于大文件传输，必须改用客户端流或服务端流分块（如 64KB 一块）流式传输。

④ 压缩算法权衡（Gzip vs None）¶

gRPC 支持使用 gzip 压缩传输消息体： - CPU vs 带宽权衡：在内网 10Gbps/100Gbps 极速局域网内，带宽极其充裕，开启 Gzip 会使 CPU 消耗上升 20%~40%，反而增加延迟。 - 最佳场景：跨公网调用、云跨可用区（跨 AZ 流量计费）或者数据体为大文本/JSON 镜像时，开启压缩能显著削减网络带宽账单。