熔断器
Circuit Breaker
高级通用熔断器（Circuit Breaker）是保护服务调用的一种机制：当下游服务持续失败时，暂时停止向它发请求，过一段时间再试探是否恢复。这样能避免故障拖慢整个产品，例如支付接口出问题时，不让结账页面一直等到超时。
你可能会说：「第三方接口一直报错时，能不能先别继续请求它，等它恢复后再自动试试？」
动手看看结账支付接口故障时
1
用户提交支付后，请求先经过熔断器，再到支付接口。接口正常时，熔断器只负责放行。
要点熔断器是怎么决定何时再发请求的？
- 1
先统计失败，再决定是否熔断
正常情况下，请求照常发往下游。我们会在一段时间内观察失败情况；如果失败达到设定条件，就让熔断器打开。这样判断依据是近期调用结果，而不是某一次偶发报错。
- 2
打开后快速返回可处理的结果
熔断器打开时，请求不会继续打到故障服务。你可以给用户明确提示，也可以在业务允许时返回备用结果。这样做的好处是减少无效等待，也给下游留出恢复空间。
- 3
等待后用少量请求试探恢复
等待一段时间后，熔断器会进入试探阶段，让少量请求通过。如果调用恢复稳定，就重新放开；如果仍然失败，就继续熔断。具体怎样算恢复，需要结合业务能接受的错误情况来定。
容易混淆的地方
超时限制的是单次请求能等多久；熔断器看的是一段时间内的调用结果，决定接下来的请求还要不要发。重试则是在失败后再发一次请求，可能帮助处理偶发故障；但下游持续故障时，反复重试会增加负担，所以通常要限制重试，并让它受熔断状态约束。
什么时候用
适合用
- 你的 App 依赖第三方支付接口；它持续失败时，结账页需要尽快提示用户，而不是让每笔订单都等到超时。
- AI 工具调用外部模型服务；服务故障时，先停止新调用，改为提示稍后再试或切换到可用的备用服务。
- 后台报表依赖另一项服务；它故障时，你希望报表入口快速返回错误，同时不拖慢后台其他功能。
不适合用
- 只是担心某个请求偶尔响应慢、但服务总体正常时，先设置合理的超时；这不是熔断器要解决的问题。
- 目标只是限制用户或客户端的请求频率时，用速率限制；熔断器判断的是下游调用是否持续失败。
- 一个页面只读取本地静态配置，没有可能持续故障的外部调用时，不需要加熔断器；直接处理读取错误就够了。
练一练选一个答案，看看解释
你的网站在结账时调用第三方支付服务。该服务连续报错后，每个用户仍要等待请求超时，结账页也变慢了。你会让 AI Agent 怎么改？
让 AI 帮你做复制给 AI Agent 直接用
请为结账服务调用第三方支付接口的部分加入熔断器：根据近期失败情况暂停调用，熔断期间快速返回可展示的错误；等待后用少量请求试探恢复。同时保留单次请求超时，并说明阈值、等待时间和监控指标如何配置。