服务熔断和降级有什么区别？熔断器如何判断故障与恢复？

知识点详解：推荐服务坏了，为什么只写 try/catch 还不够？

降级让本次请求有结果，熔断让后面的请求少白等

假设首页需要推荐服务。调用超时后，页面使用一份已准备好的默认列表。

这个替代返回就是降级。但是下一位用户仍然发起调用，继续等超时。大量请求一起等待，就可能占住线程、连接与其他资源。

熔断器观察到持续故障后，可以让后面的调用在本地快速失败，不再每次都尝试访问。应用再根据这次失败选择允许的替代结果。

所以它们可以配合，但不等于同一个动作。应用也可以在没有熔断时，因为超时或过载进行降级。

三个状态不是开关名字，而是三种调用策略

关闭状态允许请求正常访问依赖，同时记录结果。不是“关闭了服务”，而是熔断保护没有阻断这条调用。

打开状态阻止调用，避免继续冲击已知故障的依赖。不是等到每个请求超时以后才拒绝。

等待条件满足后进入半开，允许有限数量的探测请求。探测仍失败，就重新打开；满足恢复规则，才返回关闭。

官方 Circuit Breaker 模式强调这类失败检测与恢复过程。具体框架在窗口、探测数和转换时机上还有自己的配置，不能把某个默认参数写成普遍标准。

失败率，没有样本和范围就容易误导

假设只调用两次，一次失败，比例就是一半。它是否足够证明依赖持续故障？需要结合最小调用数或其他触发规则。

窗口也要明确。看最近一段时间还是最近一批调用，结果可能不同。慢调用有时和明确异常一样，会占用大量资源，也可以按具体实现纳入规则。

至于用户传错参数、业务明确拒绝、鉴权失败，不应不加区分地都算成依赖宕机。哪些异常代表基础能力不可用，要按接口语义分类。

这些参数应该来自真实流量与故障目标，不是随手抄一份“失败率 50%”就完成设计。

半开为什么只能少量试探？

依赖刚恢复，可能还没恢复到正常容量。如果每个应用实例同时把大量积压请求放回去，服务很容易再次被压垮。

所以探测要有限，并考虑多实例之间的总体量。必要时配合退避、随机化和逐步增加流量。

还有一个容易漏的条件：熔断器通常不负责取消已经在执行的调用。超时、并发隔离和连接资源限制，需要另行安排。

降级结果，也必须有可信的语义

推荐服务不可用，返回默认推荐，用户仍能浏览页面，这通常可以接受。

但支付服务结果未知，不能直接降级成“支付成功”。订单扣款、库存等高风险动作，需要确认状态与幂等边界，替代结果不能伪造业务事实。

缓存降级也要说明数据可能过期。敏感状态是否允许旧数据，要按风险决定，而不是“有缓存就返回”。

面试官继续追问

熔断和限流有什么区别？

限流主要控制允许进入的流量；熔断根据依赖健康情况决定是否继续调用。它们可以组合，但触发依据与解决问题不同。

加了熔断，还需要超时吗？

需要。没有合理超时，关闭阶段的调用可以长期占住资源，故障结果也迟迟回不来。熔断不是单次请求执行期限。

怎么验证恢复不会再次压垮服务？

在授权的测试环境注入慢响应和错误，检查打开阶段是否真的减少依赖调用，半开探测是否受限，再观察恢复时的总流量。只看到页面返回了默认列表，不足以证明熔断正确。

面试速记卡

• 熔断：根据依赖健康，决定是否继续调用。
• 降级：原能力不可用时，提供明确、可信的替代交付。
• 状态：关闭统计，打开阻断，半开有限探测。
• 统计：窗口、样本与错误分类缺一不可。
• 边界：超时和并发隔离另做，降级不能伪造业务成功。