服务降级与熔断机制实战：让系统优雅地挂

促销活动开始10分钟，商品服务挂了。

然后呢？订单服务调商品服务超时，线程池打满。用户服务调订单服务超时，线程池也打满。整个系统像多米诺骨牌一样全倒了。

这就是经典的雪崩效应。

解决方案：熔断和降级。

雪崩是怎么发生的

用户请求 │ ▼ ┌─────────┐ 调用 ┌─────────┐ 调用 ┌─────────┐ │ 用户服务 │ ────────▶ │ 订单服务 │ ────────▶ │ 商品服务 │ ← 挂了 └─────────┘ └─────────┘ └─────────┘ │ ▼ 线程等待超时 │ ▼ 线程池满了 │ ▼ 订单服务也挂了 │ ▼ 用户服务也挂了

一个服务挂，全链路崩。

熔断器原理

熔断器有三种状态：

┌─────────────────────────────────────┐ │ │ ▼ │ ┌───────┐ 失败率超阈值 ┌───────┐ 冷却后 ┌───────────┐ │ 关闭 │ ────────────▶ │ 打开 │ ───────▶ │ 半开 │ │ CLOSED│ │ OPEN │ │ HALF-OPEN │ └───────┘ └───────┘ └───────────┘ ▲ │ │ 成功率恢复 │ └──────────────────────────────────────────┘

• CLOSED：正常状态，所有请求通过
• OPEN：熔断状态，请求直接失败，不调下游
• HALF_OPEN：试探状态，放一部分请求过去试试

Sentinel实战

阿里开源的Sentinel，生产环境用得最多。

基本配置

<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-core</artifactId><version>1.8.6</version></dependency>

// 定义资源@SentinelResource(value="getProduct",blockHandler="getProductBlockHandler",fallback="getProductFallback")publicProductgetProduct(LongproductId){returnproductService.getById(productId);}// 熔断/限流时的处理publicProductgetProductBlockHandler(LongproductId,BlockExceptione){log.warn("getProduct被熔断: {}",productId);returnProduct.defaultProduct();// 返回默认商品}// 异常时的降级publicProductgetProductFallback(LongproductId,Throwablet){log.error("getProduct异常降级: {}",productId,t);returnProduct.defaultProduct();}

熔断规则

// 配置熔断规则DegradeRulerule=newDegradeRule();rule.setResource("getProduct");rule.setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType());// 按错误率熔断rule.setCount(0.5);// 错误率50%rule.setMinRequestAmount(20);// 最小请求数rule.setTimeWindow(10);// 熔断时长10秒rule.setStatIntervalMs(10000);// 统计时间窗口DegradeRuleManager.loadRules(Collections.singletonList(rule));

参数解释：

• 10秒内请求超过20次，且错误率超过50%，触发熔断
• 熔断10秒后进入半开状态

限流规则

FlowRulerule=newFlowRule();rule.setResource("getProduct");rule.setGrade(RuleConstant.FLOW_GRADE_QPS);// 按QPS限流rule.setCount(100);// 每秒100次FlowRuleManager.loadRules(Collections.singletonList(rule));

Resilience4j实战

Spring Cloud官方推荐，比Hystrix轻量。

熔断配置

resilience4j:circuitbreaker:instances:productService:sliding-window-type:COUNT_BASEDsliding-window-size:10minimum-number-of-calls:5failure-rate-threshold:50wait-duration-in-open-state:10spermitted-number-of-calls-in-half-open-state:3

参数解释：

• 基于最近10次调用统计
• 至少5次调用才开始计算
• 失败率超过50%触发熔断
• 熔断10秒后半开
• 半开状态放3个请求试探

代码使用

@CircuitBreaker(name="productService",fallbackMethod="getProductFallback")publicProductgetProduct(LongproductId){returnrestTemplate.getForObject("http://product-service/products/"+productId,Product.class);}publicProductgetProductFallback(LongproductId,Exceptione){log.warn("商品服务熔断，返回默认值: {}",productId);returnProduct.defaultProduct();}

组合使用

@CircuitBreaker(name="productService",fallbackMethod="fallback")@RateLimiter(name="productService")@Retry(name="productService")@Bulkhead(name="productService")publicProductgetProduct(LongproductId){returnproductService.getById(productId);}

执行顺序：Retry → CircuitBreaker → RateLimiter → Bulkhead → 实际调用

降级策略

策略一：返回默认值

publicProductgetProductFallback(LongproductId,Exceptione){// 返回一个空商品，让页面能展示returnProduct.builder().id(productId).name("商品加载中...").price(BigDecimal.ZERO).stock(-1)// -1表示库存未知.build();}

策略二：返回缓存数据

publicProductgetProductFallback(LongproductId,Exceptione){// 从本地缓存取Productcached=localCache.get("product:"+productId);if(cached!=null){cached.setFromCache(true);// 标记来自缓存returncached;}// 缓存也没有，返回默认值returnProduct.defaultProduct();}

策略三：静态数据兜底

publicList<Product>getHotProductsFallback(Exceptione){// 返回预先准备好的静态热门商品returnstaticHotProducts;}

适合首页推荐、热门榜单这类场景。

策略四：功能降级

publicOrderResultcreateOrder(Orderorder){// 正常流程：实时校验库存// 降级流程：异步校验，先让订单创建成功if(isProductServiceDown()){// 商品服务挂了，跳过库存校验order.setStockCheckSkipped(true);// 发消息异步补偿mqTemplate.send("stock-check-later",order);}returnorderService.create(order);}

线程池隔离

另一种防雪崩的方式：线程池隔离。

@HystrixCommand(commandKey="getProduct",threadPoolKey="productPool",threadPoolProperties={@HystrixProperty(name="coreSize",value="10"),@HystrixProperty(name="maxQueueSize",value="20")})publicProductgetProduct(LongproductId){returnproductService.getById(productId);}

每个服务用独立线程池，一个服务慢不影响其他。

Resilience4j用Bulkhead实现：

resilience4j:bulkhead:instances:productService:maxConcurrentCalls:10# 最大并发数maxWaitDuration:100ms# 等待时间

超时配置

超时配置很关键，配错了熔断器不生效。

调用链超时

用户 → 网关(10s) → 用户服务(8s) → 订单服务(5s) → 商品服务(3s)

原则：上游超时 > 下游超时

常见配置

# Feign客户端feign:client:config:default:connectTimeout:2000readTimeout:5000# RestTemplate@Bean public RestTemplate restTemplate(){HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory(); factory.setConnectTimeout(2000); factory.setReadTimeout(5000); return new RestTemplate(factory);}

超时 vs 熔断

请求超时 5s，熔断冷却 10s 场景：商品服务响应变慢（6s） 1. 请求发出 2. 等待5s，超时失败 3. 触发fallback 4. 统计失败率 5. 失败率超阈值，熔断打开 6. 后续请求直接走fallback（不用等5s了） 7. 10s后半开，试探 8. 如果成功，关闭熔断

熔断的意义：快速失败，不浪费时间等超时。

监控告警

熔断了要能看到。

Sentinel Dashboard

java -jar sentinel-dashboard-1.8.6.jar --server.port=8080# 应用接入java -Dcsp.sentinel.dashboard.server=localhost:8080\-Dproject.name=order-service\-jar order-service.jar

Prometheus指标

Resilience4j原生支持Prometheus：

management:endpoints:web:exposure:include:health,prometheus,circuitbreakers

# 熔断器状态 resilience4j_circuitbreaker_state{name="productService"} # 失败率 resilience4j_circuitbreaker_failure_rate{name="productService"} # 调用次数 resilience4j_circuitbreaker_calls_total{name="productService"}

运维实践

我们有几个服务部署在不同城市的机房，需要统一监控熔断状态。用星空组网把各地节点连起来后，Prometheus可以直接采集所有节点的metrics，监控配置简单多了。

总结

熔断降级核心要点：

降级策略选择：

系统设计的时候就要想好：哪些功能可以降级，降级后返回什么。别等出事了才想。

熔断降级这块有实战经验的欢迎交流~