熔断器

引言：当服务"生病"时 还记得我们在前面学过的限流吗？限流是对流量的主动防御——就像景区设置的日接待量上限，人满了就不让进。 但在微服务世界里，除了流量洪峰，还有另一个更隐蔽的威胁：依赖服务的故障传播。 想象这样一个场景： 你的订单服务依赖商品服务查询商品信息。某天凌晨，商品服务的数据库出现了慢查询问题，导致商品查询接口响应时间从10ms飙升到5秒。 订单服务不知情，继续调用商品服务。每次调用都要等5秒才超时。大量请求线程被阻塞，线程池很快被耗尽。 于是，订单服务也"挂了"。接着，依赖订单服务的购物车服务、支付服务也接连崩溃… 一场雪崩就这样发生了。 这就是微服务架构的阿喀琉斯之踵：故障会沿着调用链传播，一个服务的问题可能导致整个系统瘫痪。 熔断降级就是为了解决这个问题而生的。它的核心思想是： 当依赖服务出现故障时，主动"断开"对它的调用，避免故障传播。就像壮士断腕，牺牲局部，保全整体。 这就是"断臂求生的艺术"。 熔断的本质：防止故障蔓延 什么是熔断？ 熔断（Circuit Breaking）的本质是故障隔离机制。 当系统检测到某个依赖服务出现异常（如响应超时、异常率过高），就主动切断对该服务的调用，快速返回一个"降级结果"（如默认值、缓存数据、友好提示），避免调用方线程被长时间阻塞。 熔断的三个关键要素： 故障检测：持续监控依赖服务的健康状况 快速失败：检测到故障后，快速返回而不是继续等待 自动恢复：故障恢复后，自动恢复正常调用 为什么需要熔断？ 在微服务架构中，服务之间通过网络调用相互依赖，形成了复杂的调用链路。这种架构有一个天然的脆弱性： 单个服务的故障会迅速扩散，导致雪崩效应。 举个例子： 用户服务 → 订单服务 → 商品服务 → 库存服务 ↓ 支付服务 如果库存服务出现故障（如数据库慢查询），会发生： 库存服务：响应变慢，每个请求耗时5秒 商品服务：调用库存服务被阻塞，线程池占满 订单服务：调用商品服务超时，自己的线程池也被占满 用户服务：调用订单服务失败，无法提供服务 整个系统：因为一个小问题而全面瘫痪 熔断的作用就是切断这条传播链： 商品服务检测到库存服务故障，熔断对库存服务的调用 商品服务返回降级结果（如显示"暂时无法查询库存"） 商品服务自身保持正常运行 订单服务、用户服务不受影响 类比：家用电路熔断器 熔断（Circuit Breaker）这个名字来源于我们日常生活中的电路熔断器。 电路熔断器的工作原理 想象你家的配电箱： 正常工作：电流正常，熔断器保持闭合，电路正常供电 过载保护：当电流过大（如同时开太多电器），熔断器检测到异常 自动断开：熔断器立即跳闸，切断电路，避免电线过热引发火灾 手动恢复：排除故障后，可以手动合上开关，恢复供电 软件中的熔断器工作原理完全一样： 电路熔断器 软件熔断器 电流过大 服务响应慢/异常多 自动断开电路 停止调用服务 避免火灾 防止线程耗尽 手动合闸 自动尝试恢复 熔断器状态机：三种状态 Sentinel的熔断器是一个有状态的对象，它有三种状态： 1. 关闭状态（Closed） 这是熔断器的初始状态和正常工作状态。 特征： ...