在微服务架构中一次大促流量洪峰、一个下游服务超时都可能引发连锁反应最终导致整个系统雪崩。保障系统稳定性的手段有很多但最核心、最常用的莫过于三把利器限流、熔断、降级。它们各自解决不同层面的问题又常常组合使用。理解它们的原理与边界是每个后端工程师的必修课。限流把流量挡在门外限流的本质是主动控制请求速率确保系统不被超出处理能力的流量压垮。它是最前端的防线通常在网关层或服务入口处实施。常见的限流算法有四种计数器简单粗暴单位时间内计数超过阈值就拒绝但存在临界问题。滑动窗口将时间切分为多个小窗口平滑统计解决临界突变。漏桶请求像水一样流入桶中以恒定速率流出强行削峰。令牌桶以固定速率生成令牌请求需拿到令牌才能执行允许一定程度的突发流量。实践中令牌桶最常用。以 Guava RateLimiter 为例java复制下载RateLimiter limiter RateLimiter.create(100); // 每秒100个令牌 if (limiter.tryAcquire()) { // 处理请求 } else { // 返回 429 Too Many Requests }限流的难点在于阈值设定。设高了起不到保护作用设低了会误伤正常用户。建议结合压测数据、历史峰值和业务容忍度动态调整并区分核心与非核心接口——订单创建可以放宽而营销查询可以严格限制。熔断切断故障传播链如果说限流防的是“外部洪水”熔断防的就是“内部溃堤”。当某个下游服务持续失败或超时继续调用只会耗尽线程池、拖垮当前服务。熔断器就像电路中的保险丝一旦检测到故障率超标立即切断调用快速失败。熔断器有三种状态关闭正常放行请求同时统计失败率。打开失败率超过阈值如 50%直接拒绝所有请求不再调用下游。半开打开一段时间后放行少量请求试探若成功则关闭熔断否则继续打开。以 Resilience4j 为例java复制下载CircuitBreakerConfig config CircuitBreakerConfig.custom() .failureRateThreshold(50) .waitDurationInOpenState(Duration.ofSeconds(10)) .slidingWindowSize(20) .build();熔断的关键在于快速失败避免线程被长时间阻塞。配合超时设置效果更佳。需要注意的是熔断阈值和窗口大小要根据接口的 SLA 来定核心接口应更敏感非核心接口可适当放宽。降级有策略地放弃降级是熔断和限流的“兜底方案”。当系统压力过大或依赖不可用时主动关闭某些非核心功能把资源留给核心链路。降级不是失败而是有策略地牺牲。常见的降级策略包括返回兜底数据推荐服务不可用时返回热门榜单或默认推荐而不是空白页。异步补偿积分发放失败时先记录日志后续通过定时任务补发。功能开关大促期间关闭“商品评价”等非核心功能释放数据库连接。缓存兜底数据库压力大时直接返回缓存中的旧数据并提示“数据可能延迟”。降级需要提前设计而不是故障发生时才临时决定。建议为每个依赖定义降级预案并通过配置中心动态开关。例如用 Sentinel 的SentinelResource注解指定 fallback 方法java复制下载SentinelResource(value queryOrder, fallback queryOrderFallback) public Order queryOrder(Long orderId) { return orderClient.getById(orderId); } public Order queryOrderFallback(Long orderId) { return Order.empty(); // 返回空订单或缓存订单 }三者的协同分层防御限流、熔断、降级并非孤立使用而是构成一套分层防御体系入口层限流网关对 API 做整体限流挡住超额流量。服务层熔断对下游依赖配置熔断器防止单点故障扩散。业务层降级当熔断或限流触发时执行预定义的降级逻辑保证核心业务可用。例如电商大促时网关限流每秒 10 万请求订单服务调用库存服务若库存服务超时率超过 50%熔断器打开订单服务降级为“预扣库存异步确认”用户仍能下单只是确认稍晚。这样系统整体可用性远高于所有依赖都强一致。总结限流、熔断、降级是保障系统稳定性的三把利器分别对应“控制入口”“切断故障”“优雅兜底”。它们无法让系统永不故障但能让系统在故障时体面地降级而不是彻底崩溃。真正的高手不是等故障发生后才去救火而是在架构设计之初就把这三道防线埋进代码里。记住稳定性不是靠运气而是靠设计。