熔断器Circuit Breaker
你可能会说
支付依赖连续超时后别让所有请求继续等，先快速失败或降级，过一会儿再探测它是否恢复。
当外部依赖连续失败时主动切断调用并快速返回降级结果，避免自身被拖垮，并在稍后自动探测恢复的保护机制。例如结算页面调用第三方支付连续超时，继续盲目等待会耗尽自己的线程与连接。熔断器借用了电路断路器的物理机制：正常时保持通路（Closed/闭合）；连续失败达到阈值后切断通路（Open/断开开路）并快速返回降级结果；等待一段时间后进入半开路（Half-Open）放少量请求探测，成功则重新闭合通路，失败则再次断开。它不同于单次超时或重试，也不能修好依赖本身。
也常被叫作断路器熔断机制服务熔断
依赖失败时，熔断器怎样阻止故障继续扩散
订单请求通过熔断器
支付服务200 OK
熔断状态Closed
可观察证据成功率与延迟都在阈值内
依赖健康时，请求正常通过。
三种状态决定请求是否继续发送
问题与关键机制：依赖连续超时或失败会让调用方的等待和资源占用累积；达到条件后从 Closed 进入 Open，快速失败或降级，等待后只在 Half-Open 放少量请求探测。
反馈决定恢复还是继续隔离：探测成功才回到 Closed，探测失败则重新 Open。这样可观察的改善是调用方不再被拖满，但熔断器不会修复或保证依赖本身可用。
第二个场景：天气查询：行程页面依赖外部天气接口；连续失败时可暂时返回带更新时间的缓存预报并停止调用，稍后用少量请求探测，成功后再恢复正常查询。
你可以这样告诉 AI Agent
给支付依赖加熔断：正常时 Closed，连续失败后进入 Open，快速失败或返回明确的降级结果；等待后进入 Half-Open，只放少量探测请求，成功才恢复 Closed。模拟超时和恢复，验收状态变化、用户反馈和探测请求都可观察。
延伸阅读 · 权威出处
快速练习