【Java大厂面试实录】谢飞机闯关Spring Cloud+Resilience4j：从音视频降级到电商秒杀熔断

面试官："请用一个真实业务场景，说明你如何用 Resilience4j 实现服务降级？"

谢飞机（挠头）："啊？降级？就是...不让它崩？"

面试官（微笑）："好，那我们从最简单的开始。"

第一轮：音视频场景——初识降级

Q1：假设你们的音视频平台，用户点击播放按钮后，需要调用一个第三方字幕翻译服务。如果这个服务超时或宕机，用户会看到什么？

A1： 用户会卡在加载界面，或者直接报错“字幕加载失败”。这体验极差，尤其对付费会员。

Q2：Resilience4j 的 CircuitBreaker 和 Fallback 如何配合解决这个问题？

A2： 我们给这个翻译接口配一个 CircuitBreaker。正常时它放行请求；一旦连续失败达到阈值（比如5次），就跳闸（OPEN状态），后续请求直接不发给下游，而是立刻执行我们预设的 fallback 方法。

Q3：这个 fallback 方法里，你会返回什么？

A3： 返回一个空字幕对象，或者一个默认的“字幕服务暂不可用”提示。前端拿到后，就显示默认字幕或友好提示，而不是白屏。这就是降级——牺牲一部分功能，保主体流程可用。

第二轮：电商秒杀——熔断进阶

Q4：秒杀开始瞬间，库存服务被海量请求打垮。此时，订单服务调用库存服务，发现全超时。Resilience4j 怎么避免订单服务也被拖垮？

A4： 这就是熔断器的核心价值。库存服务一崩，CircuitBreaker 状态变成 OPEN，订单服务的所有线程立刻得到 fallback 响应（如“库存服务繁忙”），不会傻等超时。这保护了订单服务自身的线程池和资源，防止雪崩。

Q5：熔断器 OPEN 后，怎么知道库存服务恢复了？

A5： 它会进入 HALF_OPEN 状态。比如设置 waitDurationInOpenState=60s，60秒后，允许一个试探性请求过去。如果成功，就关闭熔断器（CLOSED）；如果还失败，就再开一次。

第三轮：供应链金融——隔离与重试

Q6：你们的融资申请服务，要同时调用征信查询、核心企业确权、银行放款三个外部系统。其中一个慢，会影响另外两个吗？

A6： 不会。我们用 Bulkhead（舱壁隔离）。给每个依赖分配独立的线程池或信号量。征信慢，只耗尽它自己的5个线程，确权和放款的服务线程完全不受影响。

Q7：如果银行放款接口偶尔网络抖动失败，你怎么办？

A7： 用 Retry。配置最大重试3次，间隔指数退避（100ms, 200ms, 400ms）。但必须加 CircuitBreaker 一起用：如果重试3次全失败，就触发熔断，下次直接 fallback，不再浪费资源重试。

面试官结语

面试官（点头）："很好，谢飞机同学，你把 Resilience4j 的四大核心——CircuitBreaker, Fallback, Bulkhead, Retry——都串在真实的业务流里讲清楚了。特别是能区分‘降级’是给用户看的兜底，‘熔断’是给系统保命的开关，这点很关键。回去等通知吧。"

【小白技术点总结】

• 降级（Fallback）：不是技术，是产品策略。当依赖不可用时，返回一个“有损但可用”的结果，保障主流程。
• 熔断（CircuitBreaker）：是系统韧性技术。像电路保险丝，自动切断故障依赖，防止连锁崩溃。状态：CLOSED → OPEN → HALF_OPEN → CLOSED。
• 隔离（Bulkhead）：防止单点故障扩散。线程池隔离（重量级）、信号量隔离（轻量级）。
• 重试（Retry）：针对瞬时故障（网络抖动）。必须配合熔断，否则雪上加霜。

一句话记住：Fallback 是兜底方案，CircuitBreaker 是安全开关，Bulkhead 是防火墙，Retry 是温柔的再试一次。