熔断器Circuit Breaker

你可能会说

支付依赖连续超时后别让所有请求继续等，先快速失败或降级，过一会儿再探测它是否恢复。

当外部依赖连续失败时主动切断调用并快速返回降级结果，避免自身被拖垮，并在稍后自动探测恢复的保护机制。例如结算页面调用第三方支付连续超时，继续盲目等待会耗尽自己的线程与连接。熔断器借用了电路断路器的物理机制：正常时保持通路（Closed/闭合）；连续失败达到阈值后切断通路（Open/断开开路）并快速返回降级结果；等待一段时间后进入半开路（Half-Open）放少量请求探测，成功则重新闭合通路，失败则再次断开。它不同于单次超时或重试，也不能修好依赖本身。

也常被叫作断路器熔断机制服务熔断

依赖失败时，熔断器怎样阻止故障继续扩散

订单服务调用支付服务正常转发

订单请求通过熔断器

支付服务200 OK

熔断状态Closed

可观察证据成功率与延迟都在阈值内

依赖健康时，请求正常通过。

三种状态决定请求是否继续发送

问题与关键机制：依赖连续超时或失败会让调用方的等待和资源占用累积；达到条件后从 Closed 进入 Open，快速失败或降级，等待后只在 Half-Open 放少量请求探测。

反馈决定恢复还是继续隔离：探测成功才回到 Closed，探测失败则重新 Open。这样可观察的改善是调用方不再被拖满，但熔断器不会修复或保证依赖本身可用。

第二个场景：天气查询：行程页面依赖外部天气接口；连续失败时可暂时返回带更新时间的缓存预报并停止调用，稍后用少量请求探测，成功后再恢复正常查询。

选择题选择一个你认为最合适的答案

支付依赖已经连续失败，新的结算请求还在不断等待。熔断器下一步应该怎样做？

继续增加重试次数，让每个请求都等到支付成功立即回到 Closed，并把所有新请求照常发送给失败依赖进入 Open，快速失败或返回降级结果，稍后再以 Half-Open 探测

你可以这样告诉 AI Agent

给支付依赖加熔断：正常时 Closed，连续失败后进入 Open，快速失败或返回明确的降级结果；等待后进入 Half-Open，只放少量探测请求，成功才恢复 Closed。模拟超时和恢复，验收状态变化、用户反馈和探测请求都可观察。