高并发系统的稳定性不取决于单个组件多强而取决于“保护策略是否成体系”。很多团队有了限流却没有熔断有了熔断却没有降级最后线上仍然出现级联故障。本文聚焦三件事什么时候限流、什么时候熔断、什么时候降级。【场景下游抖动引发全链路超时】常见故障链路下游服务 RT 变高。上游线程池被阻塞。重试放大流量连接池耗尽。核心接口被拖垮。这类问题的本质是“没有在边界处阻断故障传播”。【策略1限流控制入口流量】限流用于“系统还活着但流量超出处理能力”。常见算法固定窗口实现简单但边界抖动明显滑动窗口更平滑令牌桶支持突发流量工程上最常见if (!tokenBucket.tryAcquire()) { return ApiResponse.fail(请求过多请稍后重试); }实践建议按接口分级限流核心接口优先按租户/用户限流避免单点挤占为限流拒绝打独立指标【策略2熔断隔离不稳定依赖】熔断用于“下游已经不稳定继续调用只会扩大损失”。状态机Closed正常放行Open快速失败Half-Open小流量探测恢复if (breaker.isOpen(payment-service)) { return fallback(支付服务繁忙请稍后重试); } try { return paymentClient.pay(req); } catch (Exception ex) { breaker.recordFailure(payment-service); throw ex; }实践建议熔断粒度按“依赖服务 接口”划分熔断阈值按错误率和慢调用率双维度设置半开探测流量要严格受控【策略3降级保证核心功能可用】降级用于“资源不足时优先保核心路径”。示例推荐/评论可降级下单/支付不可降级if (systemLoad.high()) { return ApiResponse.ok(降级返回, cachedSummaryData); }实践建议先定义业务优先级核心、重要、可延后每个服务要有明确降级开关降级结果要可观测不可“静默失败”【组合策略先限流再熔断最后降级】可复用链路public Result handle(Request req) { if (!rateLimiter.allow(req.api(), req.userId())) return rejected(); if (breaker.isOpen(req.dependency())) return degraded(); try { return invokeDownstream(req); } catch (Exception e) { breaker.recordFailure(req.dependency()); return degraded(); } }这套顺序的目标是限流挡住外部压力熔断隔离内部故障降级保证核心可用【稳定性治理检查清单】入口是否有分级限流关键依赖是否配置熔断与半开探测是否定义了业务降级优先级降级是否有明确返回策略是否有拒绝率、熔断率、降级率监控是否做过压测和故障演练