调用下游时候发现超时一般怎么排查

定位具体下游哪个服务超时

一般工程侧，各公司会有一些 trace 追踪平台或者工具，能够查出来调用链的情况，然后下游服务的调用时间也会有展示出来

如果在调用方的超时错误日志中强制记录下游服务唯一标识（如服务名/IP+端口），这样上游也能很快判定出下游哪个服务有问题（好的方式）

找到该超时服务具体哪里有问题

网络层：
比如排查下网络延迟，tcp 握手耗时
比如排查对比是否同一机房/跨机房调用延迟，企业工程上可能需要求助运维同学

服务端性能指标：
排查下问题时间段 cpu 性能指标是否超过 80%
排查线程池队列堆积情况
排查下是否有频繁 Full GC 导致服务暂停
有些企业平台侧能看到上有调用超时的记录情况图表

依赖资源分析：
排查 sql 慢查询（mysql 的 slow_query_log），企业工程侧一般会有一些 mysql 平台能看到这些慢查询记录
排查缓存的响应时间和命中率情况
排查可能第三方接口的性能较弱影响了自己的业务

代码层面死锁或阻塞调用：
java 使用 jstack 导出线程堆栈，通过阿尔萨斯追踪方法内部调用耗时情况

配置的检查：
比如下游超时参数设置是否合理
比如负载均衡策略是否导致请求都打到某些节点

解法

通过一些工具和经验排查

测试时候可以用压力测试工具产生大量线上流量来造出超时场景，来帮助排查找到原因

线上出现后，影响较大需要熔断降级处理。长期可以针对性的优化，比如数据库问题优化数据库，多线程问题优化多线程代码