摘要：你是不是也遇到过这种情况？线上分布式系统突然报 “接口超时”，日志里只看到 “TimeoutException”，既没报错堆栈，也找不到具体哪个服务出问题 —— 像我前阵子帮电商客户排查问题时，就卡了 3 天，从网关查到数据库，改了超时时间、加了重试机制，结果
你是不是也遇到过这种情况？线上分布式系统突然报 “接口超时”，日志里只看到 “TimeoutException”，既没报错堆栈，也找不到具体哪个服务出问题 —— 像我前阵子帮电商客户排查问题时，就卡了 3 天，从网关查到数据库，改了超时时间、加了重试机制，结果故障还在反复，最后还是阿里架构师给的思路帮我搞定了。今天就把这个实战案例拆透，教你遇到类似问题不用慌，3 步就能定位根因
先跟你还原下当时的场景：客户是做生鲜电商的，分布式架构用的是 Spring Cloud，核心链路是 “用户下单→订单服务调用库存服务→库存服务调用仓储服务”。某天早高峰突然出现大量 “订单创建超时”，监控显示订单服务调用库存服务时，50% 的请求超过 3 秒，直接触发了网关的超时熔断。
一开始我们以为是 “超时时间设短了”，把订单服务调用库存服务的超时时间从 3 秒改成 5 秒，结果更糟 —— 超时请求占比降到 30%，但出现了新问题：库存服务的线程池满了，大量请求排队，导致其他接口也开始超时。后来又怀疑是网络波动，找运维查了交换机日志，没发现丢包；查数据库慢查询，仓储服务的 SQL 执行时间都在 100ms 以内，也没问题。
就这么卡了 3 天，每天早高峰故障必现，客户那边催得紧，我连觉都睡不好。直到朋友推荐了一位阿里 P8 架构师，他听我说完情况，只问了 3 个问题：“有没有链路追踪日志？有没有监控服务间的调用耗时分布？有没有排查过服务依赖的中间件？” 这 3 个问题直接点醒了我 —— 原来我之前的排查方向全错了。
后来我按照架构师的思路，重新梳理排查流程，才发现问题根本不是 “超时时间” 或 “网络”，而是 3 个容易被忽略的细节，你以后遇到类似问题，也可以按这个逻辑查：
之前我只看了订单服务的日志，没管完整链路，其实分布式问题第一步要做的是 “链路可视化”。我们用 SkyWalking 补了全链路追踪，才发现：订单服务调用库存服务时，真正的接口处理时间只有 500ms，但 “等待线程池” 的时间却占了 2.5 秒—— 也就是说，库存服务的线程池不够用，请求在排队，而不是接口本身处理慢。
这里要跟你说个坑：很多人遇到超时就改 “Feign 调用超时时间”（比如把 readTimeout 从 3 秒改 5 秒），但如果是 “线程池排队” 导致的超时，改超时时间只会让请求在队列里排更久，反而会耗尽调用方的线程资源，引发连锁故障 —— 就像我们之前改了超时时间后，订单服务的线程也开始堆积，就是这个原因。
确定是库存服务线程池满了之后，我们又疑惑：库存服务平时 QPS 也就 200，线程池核心数设的是 10，按理说足够，为什么会满？后来查库存服务的日志才发现，库存服务调用 Redis 时，出现了大量 “连接超时”——Redis 实例是阿里云的，那天早高峰 Redis 的 CPU 使用率突然升到 90%，导致库存服务的 Redis 客户端连接阻塞，每个请求占用线程的时间从 50ms 变成 2 秒，线程池里的线程被占着不放，新请求只能排队。
这又是一个容易踩的坑：分布式接口超时，不一定是 “服务 A 调用服务 B” 的问题，可能是服务 B 依赖的中间件（Redis、MQ、数据库）出了问题。比如我之前只查了仓储服务的数据库，却没查库存服务依赖的 Redis，差点就漏掉了根因。
找到 Redis 的问题后，我们又发现一个隐患：库存服务的 Redis 客户端用的是 Jedis，而且没配置 “超时重试 + 熔断”—— 当 Redis 连接超时时，Jedis 会默认重试 3 次，每次重试等待 1 秒，相当于一个请求要阻塞 3 秒才会抛出异常。更糟的是，库存服务的代码里，调用 Redis 的方法没加 “超时时间限制”，导致线程被无限占用。
这里要跟你强调：调用任何中间件或第三方服务时，一定要加 “超时时间” 和 “熔断降级”。比如 Jedis 要配置 “connectTimeout=500ms，soTimeout=500ms”，再配合 Sentinel 或 Resilience4j 做熔断，避免一个中间件故障拖垮整个服务。
后来按照阿里架构师的建议，我们分 3 步解决了问题，现在这个生鲜电商的订单链路，早高峰超时率稳定在 0.1% 以下，你遇到类似问题也可以直接用：
如果线上突然出现接口超时，没时间查根因，可以先做 “应急处理”：
第一步：给调用方加 “限流”，比如用 Sentinel 给订单服务调用库存服务的接口设 QPS 上限，超过上限的请求直接返回 “系统繁忙，请稍后再试”，避免库存服务线程池被耗尽；第二步：给依赖中间件加 “降级”，比如库存服务调用 Redis 超时后，暂时用本地缓存返回 “默认库存”（适合非核心场景），先保证接口不超时，后续再补数据。这里给你贴一段 Sentinel 限流的核心配置代码，Spring Cloud 项目直接加在接口上就行：
// 库存服务接口：给查询库存的方法加限流，QPS上限100@SentinelResource(value = "getStockcount", blockHandler = "getStockCountBlockHandler", // 限流降级后的处理方法 fallback = "getStockCountFallback") // 接口抛出异常后的降级方法@RequestMapping("/stock/count")public ResultgetStockCount(@RequestParam("goodsId") Long goodsId) { // 正常业务逻辑：调用Redis查询库存 Integer count = redisTemplate.opsForValue.get("stock:" + goodsId); return Result.success(count == null ? 0 : count);}// 限流后的处理：返回默认库存（适合非核心场景）public ResultgetStockCountBlockHandler(Long goodsId, BlockException e) { log.warn("查询库存被限流，goodsId:{}", goodsId, e); return Result.success(100); // 暂时返回默认库存100}// 接口异常后的处理：返回0，避免报错public ResultgetStockCountFallback(Long goodsId, Throwable e) { log.error("查询库存异常，goodsId:{}", goodsId, e); return Result.success(0);}应急之后，一定要补监控，避免下次再踩坑。阿里架构师建议我们重点加 3 类监控：
第一类：链路追踪监控，用 SkyWalking 或 Zipkin，监控每一段调用的耗时（比如 “订单服务→库存服务” 的网络耗时、“库存服务→Redis” 的处理耗时），一旦某一段耗时超过阈值就告警；第二类：中间件监控，给 Redis、MySQL、MQ 加监控，重点看 “连接数”“CPU 使用率”“响应时间”，比如 Redis 的响应时间超过 100ms 就告警；第三类：线程池监控，给每个服务的核心线程池加监控，监控 “活跃线程数”“队列等待数”，比如队列等待数超过 50 就告警。我现在每天上班先看这 3 个监控面板，有异常提前处理，再也不用等线上故障爆发才救火。
最后是长期方案，从架构上减少超时风险。架构师跟我说，分布式系统要尽量做到 “弱依赖 + 异步化”，比如：
把 “强依赖” 改成 “弱依赖”：像订单服务调用库存服务，如果只是 “查询库存”，可以做本地缓存兜底，就算库存服务超时，也能用缓存返回数据；如果是 “扣减库存”，必须保证一致性，那就用 “本地消息表 + MQ” 做异步，避免同步调用超时；拆分 “大接口”：如果一个接口要调用 3 个以上服务，就拆成多个小接口，用异步线程并行调用，减少总耗时。比如之前订单服务要调用 “库存、优惠券、用户等级”3 个服务，同步调用总耗时 2 秒，改成异步并行后，总耗时降到 800ms。其实分布式系统的超时问题，看起来复杂，本质都是 “链路不透明”“依赖没兜底”—— 只要做好 “链路追踪 + 监控告警 + 降级兜底”，大部分问题都能快速解决。我这次踩的坑，可能你之前也遇到过，比如 “改超时时间反而更糟”“中间件故障导致服务超时”。
现在想问问你：你在开发中遇到过哪些棘手的分布式故障？是怎么排查解决的？比如有没有遇到过 “调用链路里藏着隐性依赖”“中间件连接池耗尽” 这类问题？欢迎在评论区分享你的经历，咱们一起交流避坑技巧。如果有具体问题，也可以说出来，我会尽量帮你分析思路，咱们互相学习进步～
来源：从程序员到架构师
