Go 微服务 gRPC 服务频繁超时 (504) 的排查
本文探讨在使用 Go 微服务框架 go-micro v2 开发的 gRPC 服务中，用户请求频繁超时返回 504 错误的原因。该问题在 QPS 约为 3000 时尤为明显，即使服务器负载不高。请求流程经 Kong 网关转发至上游 Go 服务。
Kong 网关错误日志示例：
<code>2022/12/04 20:08:28 [error] 13383#0: *111383271 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 42.218.168.26, server: kong, request: "GET /go.xx.xxx/api/find-msg-list/xxxx/1051 HTTP/1.1", upstream: "grpc://192.168.255.165:8896", host: "xx.xxxx.cn", referrer: "https://xxx.xxx.cn/live/xxxx?module=Investment_JDTJ"</code>
日志显示读取上游服务响应头超时。可能原因包括网络延迟、服务端处理缓慢、负载均衡配置错误等，而非仅仅是 gRPC 的 maxconcurrentstreams 设置过低（默认值 100）。
问题分析：
-
超时根本原因： 单纯怀疑
maxconcurrentstreams过低是不够的。需要更深入的排查，例如网络延迟、服务端瓶颈（数据库查询缓慢、CPU/内存占用过高等）、Go 服务代码逻辑问题等。 -
go-micro v2 中
maxconcurrentstreams设置： go-micro v2 对 gRPC 进行封装，没有直接设置maxconcurrentstreams的方法。需要寻找替代方案，例如调整服务端资源或优化代码。
建议的排查步骤：
为了精确诊断，建议使用 tcpdump 等网络抓包工具在 Kong 网关和后端服务器同时抓包分析。这能帮助我们：
- 观察请求和响应的详细过程，识别潜在的网络延迟或阻塞。
- 确认是否大量请求在等待响应头，以及等待时间。
- 找出服务端处理缓慢的具体环节（例如数据库查询）。
通过抓包分析结合服务器监控数据，可以更有效地定位超时问题根源，并制定针对性的解决方案。 仅仅依靠猜测 maxconcurrentstreams 并不能解决问题。
