斯迈尔齿科服务熔断和服务降级，是微服务面试里出现频率极高的两个概念，也是线上稳定性治理里绕不开的两个动作。最近我筛简历的时候发现一个现象：候选人能把 Hystrix 的三个状态背得滚瓜烂熟，但问到“你们项目里熔断和降级分别怎么落地、出了故障怎么配合”时，就回答得特别虚。这题问的不是记忆力，是你有没有真的在流量和故障里被锤过。今天借“每日一道面试题 12”这个场景，聊聊我自己的理解，以及我在订单链路里做过的事。
1. 先别背定义：熔断和降级分别保护的是谁
这里先给一个最直白的结论：熔断做的是资源保护，降级做的是业务兜底。一个是机制，一个是策略。
很多人把熔断理解成“超时后的兜底”，把降级理解成“故障时返回默认值”，方向对，但没有触及关键。熔断保护的是调用方自己的资源，或者说保护整个调用链路的稳定性；降级保护的是最终用户体验，是在不可用场景下用一种有损的方式继续提供服务。
1.1 熔断是资源保护机制，降级是业务兜底策略
可以打个比方。你是前台，隔壁部门系统总是卡住。熔断是你给自己设的规则：如果连续 5 次挂掉，接下来 10 分钟内我不再主动找它，所有请求直接说“稍后再办”；降级是你在给访客答复时的策略：对方系统挂了，我就先给访客递一张手工登记表，而不是让访客在柜台前面干等。前者保护你自己的工作节奏，后者保证服务窗口还能运转。
具体到微服务里，熔断器通过状态机控制对下游服务的调用：正常情况下正常调用，异常率达到阈值后直接短路，后续请求快速失败，不再继续消耗连接池和线程池；降级则是当调用失败、超时、熔断触发或者人工主动切换时，执行一段兜底逻辑，比如返回缓存数据、默认值、空列表。
两者的关系用一张表可以看得比较清楚：
| 对比项 | 服务熔断 | 服务降级 |
|---|---|---|
| 核心目的 | 保护调用方进程/线程不被下游故障拖垮 | 故障发生时主流程仍能返回可用结果 |
| 触发方式 | 错误率、慢调用率、并发异常达到阈值后自动触发 | 可由熔断、异常、超时触发，也可以人工主动触发 |
| 典型行为 | 快速失败，拒绝继续调用下游 | 执行 fallback：缓存、默认值、空结果 |
| 粒度 | 通常针对某个下游服务/接口/资源 | 通常针对业务流程里的某个功能点 |
| 状态 | 有状态：闭路-开路-半开 | 无强状态，更像规则/策略 |
1.2 两者常被混在一起，是因为工程上经常配套出现
Hystrix、Resilience4j、Sentinel 这些框架里，熔断之后通常会走到 fallback，所以很多人以为“熔断就是降级”。其实熔断器只负责让请求不要继续打到下游，fallback 才负责接下来怎么回应调用方。
如果去掉 fallback，熔断后接口会直接抛异常；加上 fallback，熔断后接口才变成了降级响应。这是两者最容易被搞混的地方：你在框架里看到的往往是一个组合能力，不是同一个概念。
所以面试时不要只说一句话，要能拆开讲：熔断是“我不能等你了”，降级是“虽然等不到你，但我换个方式把活干完”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 熔断的状态机与阈值计算：为什么不能只靠超时
我最早搭订单详情接口的时候，只做了超时控制，没有加熔断。上线一段时间后发现，超时控制挡不住资源耗尽。这里面的逻辑，很多人没想透。
2.1 Closed / Open / Half-Open 三种状态在回答什么问题
熔断器的三个状态，其实分别回答三个问题：能不能调、要不要停、能不能恢复。
- Closed 闭路：下游正常，请求正常放行，维护滑动窗口里的成功、失败、慢调用数据。
- Open 开路：下游异常达到阈值