Spring Cloud服务熔断与降级

咱们今天不讲童话咱们讲“系统保命学”。在微服务架构里服务之间就像是一群互相借钱的酒肉朋友。平时你好我好大家好一旦有个“朋友”服务A破产了挂了或者赖账超时如果不加控制这种恐慌会瞬间传染给借钱给他的B、C、D最后导致整个朋友圈整个系统集体跳楼。这就是雪崩效应。为了防止集体跳楼我们需要一种机制熔断与降级。今天的主角是Hystrix虽然老了但它是祖师爷原理通用和Sentinel阿里出品青出于蓝。第一层雪崩效应——多米诺骨牌的惨案底层原理假设你有 100 个线程Tomcat 线程池。服务 A 调用 服务 B。突然服务 B 卡死了比如数据库死锁每个请求都要耗时 5 秒才能返回。第 1 秒来了 10 个请求A 调 BB 没反应。A 的 10 个线程被阻塞挂起等待 B。第 2 秒又来了 10 个请求A 的线程池被占用了 20 个。第 5 秒来了 100 个请求。A 的 100 个线程全部在等 B 的回应。线程池耗尽第 6 秒用户 C 访问服务 A 的“登录”功能这功能本来不需要调 B。但是因为 A 的线程池满了C 的请求连 A 的门都进不去结果B 挂了导致 A 也挂了。A 挂了导致整个网关挂了。全站宕机。第二层熔断器的三种状态——“渣男”心理变化史熔断器本质上是一个状态机。我们可以把它想象成一个被渣男下游故障服务伤透了心的女神熔断器。1. 关闭状态CLOSED—— 热恋期状态一切正常。行为女神对渣男言听计从请求直接放行。底层逻辑计数器记录失败次数。只要失败次数 阈值比如 5 次就一直是 CLOSED。2. 打开状态OPEN—— 分手期触发渣男连续 5 次迟到/撒谎请求超时/异常达到了阈值。行为女神瞬间黑化。底层逻辑熔断器状态变为 OPEN。快速失败Fail Fast后续来的所有请求根本不会去调用下游服务直接抛出异常或者执行降级逻辑。目的给下游服务“喘息”的时间也保护上游线程池不被拖死。3. 半开状态HALF_OPEN—— 考察期触发在 OPEN 状态停留了一段时间比如 5 秒这叫“熔断时长”。行为女神心软了决定给渣男最后一次机会。底层逻辑状态变为 HALF_OPEN。放行一个请求探测请求去试试水。情况 A如果这个请求成功了 - 渣男改邪归正 - 状态变回CLOSED。情况 B如果这个请求失败了 - 渣男无可救药 - 状态变回OPEN继续闭关。第三层代码层面的“保命”实现咱们用伪代码类似 Sentinel/Hystrix 的逻辑来看看底层是怎么实现的。核心代码熔断器逻辑public class CircuitBreaker { // 状态枚举 enum Status { CLOSED, OPEN, HALF_OPEN } private Status status Status.CLOSED; private int failureCount 0; private int failureThreshold 5; // 失败阈值 private long lastFailureTime 0; private long retryTimeWindow 5000; // 重试时间窗口5秒 // 核心方法执行请求 public Object execute(Request request) { // 1. 检查是否需要尝试恢复从 OPEN - HALF_OPEN if (status Status.OPEN) { if (System.currentTimeMillis() - lastFailureTime retryTimeWindow) { status Status.HALF_OPEN; System.out.println(进入半开状态试探一下...); } else { // 还在冷却期直接拒绝 throw new RuntimeException(熔断器已打开拒绝访问); } } try { // 2. 真正调用下游服务 Object result callRemoteService(request); // 3. 调用成功后的处理 onSuccess(); return result; } catch (Exception e) { // 4. 调用失败后的处理 onFailure(); throw e; } } private void onSuccess() { failureCount 0; // 重置计数器 status Status.CLOSED; // 如果是半开状态现在也变回关闭 } private void onFailure() { failureCount; lastFailureTime System.currentTimeMillis(); // 5. 判断是否达到熔断阈值 if (failureCount failureThreshold) { status Status.OPEN; System.out.println(达到阈值熔断器打开); } } }第四层降级——熔断后的“备胎”计划熔断只是止损我不调你了但用户请求还在啊你得给用户个交代。这就是降级。降级不是“报错”而是“妥协”。场景双11大促库存服务挂了。不降级页面显示“系统异常500 Error”。用户骂娘降级页面显示“库存加载中...”或者显示一个默认的兜底数据或者把非核心的“推荐商品”隐藏只保留“购买按钮”。用户理解代码实现伪代码try { // 尝试调用核心服务 return userService.getUserInfo(userId); } catch (CircuitBreakerOpenException e) { // 熔断发生了执行降级逻辑 return getLocalCacheUserInfo(userId); // 返回本地缓存的旧数据 } catch (Exception e) { // 其他异常 return new User(默认用户, 头像.jpg); // 返回默认值 }第五层Hystrix vs Sentinel —— 祖师爷 vs 进化体虽然原理一样但实现细节上有代差。Hystrix祖师爷停止维护隔离策略线程池隔离。它给每个依赖服务都开一个独立的线程池。优点彻底隔离一个服务挂了不占主线程。缺点太重了线程上下文切换极其消耗性能。熔断算法基于滑动窗口的计数器。改个熔断阈值比如从 50% 改到 60%对不起通常得重启服务或者你费劲巴拉地集成 Archaius 配置中心。只能做熔断和降级。它就像个保安只会说“这人病了别让他进”Sentinel进化体隔离策略信号量隔离主要 线程池隔离。默认使用信号量Semaphore其实就是控制并发数比如只允许 10 个请求同时调 B 服务。优点轻量级没有线程切换开销性能极高。流量控制Sentinel 不仅仅是熔断它还能做限流QPS 控制。底层数据结构使用了滑动时间窗口LeapArray。它不是简单的记个数而是把时间切成很多小格子比如 1 秒切成 50 个格子每个格子 20ms。这样可以更精准地统计“最近 1 秒”的失败率而不是“从系统启动到现在”的失败率。自带控制台Dashboard。你在网页上拖个滑块改个数字秒级生效无需重启。运维和运营人员都能自己改这才是生产环境需要的。Java和Go双修。现在的微服务架构很多是混合语言Java 写核心Go 写网关或旁路Sentinel 能通吃。不仅能熔断还能限流QPS 控制、系统自适应保护CPU 飙高自动降级、热点参数限流比如限制同一个用户 ID 的访问频率。它不仅是保安还是交通指挥官。维度Hystrix (老前辈)Sentinel (新霸主)胜出者维护状态 停止维护✅ 活跃更新Sentinel隔离方式线程池开销大重信号量开销小轻Sentinel熔断策略仅基于异常比例异常比例、慢调用、异常数Sentinel限流功能弱需结合其他组件强QPS、并发数、热点Sentinel规则配置代码/配置文件需重启控制台/API实时生效Sentinel监控面板需搭建 Turbine简陋原生 Dashboard强大Sentinel生态整合Spring Cloud NetflixSpring Cloud AlibabaSentinel建议场景一新项目Greenfield Project选 Sentinel。毫无疑问。配合Spring Cloud Alibaba利用它的SentinelResource注解几行代码就能实现熔断、降级、限流。部署一个 Sentinel Dashboard系统稳定性监控一目了然。场景二老项目维护Legacy Project如果老项目已经用了 Hystrix 且运行稳定不要为了换而换。重构是有风险的。但如果有新模块开发或者准备做架构升级建议逐步迁移到 Sentinel。场景三Go 语言项目选 Sentinel或者 Go 原生的限流库如go-resilienceHystrix 的 Go 版本go-hystrix也是很久没维护了。一句话总结Hystrix 是上个时代的英雄值得尊敬但 Sentinel 才是这个时代的王者能帮你打赢现在的流量战争。拥抱 Sentinel别回头。总结雪崩是线程池耗尽导致的连锁反应。熔断是状态机CLOSED - OPEN - HALF_OPEN目的是快速失败保护系统。降级是熔断后的兜底方案目的是用户体验。Hystrix用线程池隔离稳但重Sentinel用信号量隔离快且轻还带流量控制。一句话“在分布式系统里承认‘由于下游故障我无法提供服务’并不丢人硬撑着直到把自己拖死才是最大的愚蠢。”