📌 微服务节点某一个节点出现了降级，但是其他服务都正常，是什么原因造成的？

在微服务架构中，一个服务通常会部署多个实例（Node），并通过Nacos、Eureka、Consul等注册中心进行服务注册，再结合Spring Cloud LoadBalancer、Ribbon或网关进行流量分发。理论上，同一个服务的所有节点代码完全一致，因此很多开发人员认为："如果发生降级，应该所有节点一起降级。"

然而在实际生产环境中，经常会遇到下面这种现象：

这种问题往往比整个服务不可用更难排查，因为它通常意味着问题已经缩小到某一个实例，而不是整个微服务。

本文将从Spring Cloud、Sentinel、Hystrix、Resilience4j、JVM、数据库、线程池、连接池以及操作系统多个角度，系统分析为什么同一个微服务只有一个节点发生降级，而其他节点却完全正常。

🎯 一、问题背景

假设订单服务部署了4个实例：

负载均衡器按照轮询策略分发请求：

• Node-1 正常返回
• Node-2 正常返回
• Node-3 返回Fallback
• Node-4 正常返回

客户端表现为：

• 大约25%的请求失败。
• 重试一次可能立即恢复。
• 接口偶发进入降级逻辑。

🚀 二、核心原理

无论是Sentinel、Hystrix还是Resilience4j，它们的降级判断几乎都是基于当前实例进行统计，而不是整个集群统一统计。

每个实例都会维护自己的运行状态，例如：

• 当前QPS
• 线程数
• 平均RT
• 异常比例
• 异常数量
• CPU负载
• 系统Load
• 线程池等待数

因此，只要某一个节点资源异常，就可能提前触发熔断或降级，而其他节点由于资源充足，依然能够正常提供服务。

📌 三、数据结构分析

以Sentinel为例，每个节点都会维护独立的统计窗口：

由于统计数据完全隔离，因此Node-3进入熔断，并不会影响其他节点。

🔥 四、算法分析

下面按照实际线上故障出现频率进行分析。

① JVM发生Full GC

如果某一个节点出现频繁Full GC，Stop The World可能持续数百毫秒甚至数秒。

• 接口RT急剧上升
• 请求大量堆积
• 超时数量增加
• 最终触发降级

② 数据库连接池耗尽

例如HikariCP连接池已经达到最大连接数：

大量线程等待数据库连接，请求响应时间急剧增加，最终触发熔断。

③ 某节点线程池被打满

例如：

新请求无法继续执行，只能等待或者拒绝，从而进入降级逻辑。

④ 热点数据全部落到一个节点

由于一致性Hash、本地缓存或Session保持，部分热点请求可能集中访问同一个实例，导致该节点CPU、内存、线程池压力远高于其他节点。

⑤ 某节点网络异常

• 网络丢包
• DNS异常
• 交换机故障
• TCP重传增加

这些都会导致RT持续升高，从而进入降级。

⑥ 本地缓存失效

例如Guava Cache、Caffeine缓存全部失效，大量请求直接访问数据库，而其他节点缓存仍然命中，最终只有一个节点RT明显增加。

🚀 五、执行流程

可以看到，整个过程中只有Node-3资源耗尽，因此降级也只发生在Node-3。

✅ 六、实际案例

某电商系统部署了6个订单服务实例，线上突然出现20%的订单创建失败。

排查发现：

• 只有一个Pod发生降级。
• CPU达到98%。
• GC一分钟执行15次。
• 数据库连接全部耗尽。
• 线程池等待超过3000个请求。

进一步分析日志发现，该节点本地缓存由于一次配置发布被全部清空，大量请求直接访问数据库，引起数据库连接池阻塞，RT从30ms增长到2500ms。

最终Sentinel连续检测到慢调用比例超过阈值，自动进入熔断状态，而其他节点缓存仍然有效，因此一直正常运行。

🚀 七、优缺点分析

💬 八、面试常见问题

✅ 九、总结