熔断器模式

为什么分布式系统需要熔断

在微服务架构里，服务 A 调用服务 B，服务 B 调用服务 C。如果 C 响应变慢，B 的线程池会被打满，A 的请求也开始积压，最终整个调用链崩溃——这叫级联故障。2012 年 Netflix 开源 Hystrix 库，专门解决这个问题，一时间成为 Java 微服务的标配。

熔断器有三个状态：关闭（Closed）——正常放行所有请求，统计失败率；打开（Open）——失败率超过阈值后直接短路，立即返回降级结果；半开（Half-Open）——熔断超时后放入少量试探请求，若成功则关闭熔断，若还是失败则重新打开。[1]

实现与降级策略

Hystrix 已于 2018 年停止主动开发，目前推荐的替代品是 Resilience4j（Java 生态）和 Sentinel（阿里巴巴开源，支持流控和降级）。在服务网格场景下，Istio 的 Outlier Detection 可以在代理层实现熔断，无需修改业务代码。

熔断触发后需要返回「降级」响应：商品详情页调用评论服务超时，降级为返回空评论列表；推荐服务不可用时，降级为返回热门商品列表。降级内容要提前设计，不能临时拍脑袋。