面经策

什么是服务熔断？ ​

  • 标签：Spring Cloud、服务熔断、后端、微服务

🏛 业务架构师 ​

服务熔断是断路器模式在微服务的落地：当下游调用的失败率超过阈值，断路器跳闸，一段时间内所有请求不再真正发出去，直接快速失败/走降级；冷却期后半开探测，下游恢复则闭合。三态：Closed（正常）→ Open（熔断）→ Half-Open（试探）。

业务本质：牺牲局部保全全局的止损机制。没有熔断的连锁反应：支付下游变慢 → 订单服务线程全部阻塞在等待 → 订单服务自身不可用 → 依赖订单的服务接连倒下——服务雪崩。熔断就是把故障隔离在第一跳：支付挂了，订单服务的线程不陪葬，下单主流程还能跑（支付降级为"稍后重试"）。

我的落地要点：

  • 熔断必须配降级：熔断后返回什么要有业务答案——返回缓存快照（商品页用上次数据）、默认值（推荐位上热销榜）、异步补偿（支付记待处理，恢复后补扣）。没有降级方案的熔断只是把错误换了个姿势——降级体验要和产品提前定义，而不是故障当晚现场拍脑袋；
  • 阈值要贴业务：按窗口内失败率/慢调用比例（50% 失败、或 P99 超 1s 占比过半），不同下游不同配置——支付下游敏感度不同于日志下游；
  • 熔断的位置与层级：网关层（对外的过载保护）+ 调用方层（Sentinel/Resilience4j 精细到接口）双层布防；
  • 可观测与演练：熔断事件告警（它发生=已经在止损）、定期故障演练验证降级路径真的能跑通——没演练过的预案是心理安慰。

一句话：熔断是给系统的"保险丝"，装保险丝的功夫在平时，值钱的是故障那一刻的从容。

🏗 系统架构师 ​

服务熔断是微服务的自动保险丝：当下游服务错误率/慢调用比例超阈值时，熔断器跳闸，后续请求快速失败（fail-fast）不再真正调用下游，直接走降级逻辑；过一段时间放少量探测请求（半开态），下游恢复则闭合，依旧故障则继续熔断。

三态状态机（Closed → Open → Half-Open）正是熔断器模式的精髓：关闭态正常放行并统计；打开态拒绝一切（如 10 秒窗口内错误率 > 50% 触发）；半开态放 N 个试探请求，按结果决定恢复或再熔断。

为什么要熔断：故障下游会拖死上游——线程池被慢调用占满、连接堆积，故障沿调用链向上蔓延（服务雪崩）。熔断用"主动牺牲该下游调用"换上游自身和整体链路的存活，本质是把不可控等待变成可控失败。

工程落地：

  • Sentinel（阿里系，规则动态推送、控制台、流控降级熔断一体）或 Resilience4j（轻量函数式，Spring Cloud 官方推荐）；
  • 关键参数：错误率/慢调用比例阈值、最小请求数（避免小流量误熔断）、熔断时长、半开试探数；
  • 熔断必须配降级兜底（缓存旧值、默认值、友好提示）才有业务意义；
  • 范围要精细到"接口 + 异常类型"，不要粗粒度熔掉整个服务。

一句话：限流保护自己不被流量打垮，熔断保护自己不被下游拖垮，两者是高可用的一体两面。

💻 全栈开发专家 ​

熔断 = 依赖服务故障时，主动"跳闸"快速失败，防止故障蔓延和资源耗尽。类比电路保险丝。

工作机制（三状态循环）：

text
CLOSED（正常放行，统计失败率）
   │ 失败率/慢调用比例超阈值（如 10s 内 50%）
   ▼
OPEN（熔断，请求直接走 fallback，不再调用下游）
   │ 经过冷却时间（如 10s）
   ▼
HALF-OPEN（放行少量探测请求）
   │ 成功→回 CLOSED；失败→回 OPEN

为什么需要它：下游变慢而不是挂掉时最危险——调用方线程/连接被拖住逐个耗尽，把"局部慢"放大成"全站雪崩"。熔断 + 快速失败把资源保住，等下游恢复。

Sentinel 的落地配置（我项目里的实际用法）：

java
@SentinelResource(value = "queryUser", fallback = "queryUserFallback")
public User queryUser(Long id) { return rpc.getUser(id); }
public User queryUserFallback(Long id, Throwable t) {
    return cache.getOrDefault(id, User.EMPTY);  // 兜底：缓存/默认值
}

规则：慢调用比例（RT>500ms 计为慢，比例>50% 熔断 10s）或异常比例，控制台动态下发。

和降级的区别：熔断是自动触发的保护动作，降级是预设的兜底策略（熔断后走的就是降级逻辑）。三件套记住：超时是底线，熔断是保险丝，降级是逃生通道。