在系统上线初期，很多开发者最关心的往往是“接口能不能跑通”、“功能有没有 Bug”。但当业务量激增、流量洪峰到来时，真正决定系统稳定性的，往往是那些平时不起眼的“非功能性指标”。
你有没有遇到过这样的场景：某个热点商品被高频请求，或者某个下游服务突然响应变慢，结果导致你的核心 API 线程池瞬间被占满，整个系统出现连锁故障？
API 的流量防护，是每一个走向成熟的开发者必须跨越的门槛。今天，我们就来拆解 API 高可用架构中的核心武器：限流、熔断与降级。
一、 第一道防线：限流（Rate Limiting）—— 给系统戴上“限速器”
限流的核心目的，是保护系统不被瞬间的超大流量击穿。它就像高速公路上的收费站，无论外面有多少车，只允许固定数量的车通过。
- 常见的限流算法
计数器法（固定窗口）：最简单直接。比如限制 1 分钟内最多 100 次请求。但存在“临界突变”问题（在第 59 秒和第 1 秒各发 100 次，2 秒内实际处理了 200 次）。
滑动窗口法：将时间窗口切分成多个小格子，平滑了临界突变问题，是大多数网关（如 Nginx、Redis）的默认选择。
漏桶算法（Leaky Bucket）：强制请求以固定的速率流出，适合需要严格平滑流量的场景（如数据库写入）。
令牌桶算法（Token Bucket）：以固定速率向桶中放入令牌，请求必须拿到令牌才能被处理。它允许一定程度的突发流量（桶满时瞬间拿走所有令牌），是目前微服务网关（如 Spring Cloud Gateway、Sentinel）最常用的算法。 - 限流的维度
不要只做全局限流，必须多维度组合：
IP 限流：防范高频自动化请求。
用户级限流：防范恶意刷单或频繁获取验证码。
接口级限流：保护核心数据库，比如限制“商品详情”接口 QPS 为 5000，限制“下单”接口 QPS 为 500。
二、 第二道防线：熔断（Circuit Breaker）—— 系统的“保险丝”
限流防的是“外部流量”，而熔断防的是“内部依赖”。
当你的 API 需要调用下游服务（如支付网关、物流接口）时，如果下游服务突然异常或响应极慢，你的线程会一直阻塞等待。如果不做处理，你的服务也会因为线程池耗尽而受到连带影响。
熔断器的三种状态：
Closed（关闭）：一切正常，请求正常放行。
Open（打开）：当错误率或慢调用比例超过阈值（如 50%），熔断器打开。此时所有对下游的请求直接被拦截，不再真正调用下游，而是立即返回错误或兜底数据。这保证了你的主服务能够继续运行。
Half-Open（半开）：经过一段冷却时间后，熔断器会放行少量请求去探测下游是否恢复。如果成功，则关闭熔断器；如果依然失败，则继续保持打开状态。
三、 第三道防线：降级（Degradation）—— 断臂求生的“急救包”
当系统真的面临极大压力，或者非核心依赖出现异常时，必须有“降级”策略。
降级的核心思想是：保核心，弃边缘。
返回兜底数据：比如推荐服务出现异常，商品详情页的“猜你喜欢”模块直接隐藏，或者返回静态的热门商品列表，而不是让整个页面无法加载。
关闭非核心功能：大促期间，为了保证下单和支付链路的绝对畅通，可以主动降级“积分发放”、“评价展示”、“物流轨迹实时更新”等功能。
静态化：在极端情况下，将动态接口替换为 CDN 上的静态 JSON 文件。
四、 落地实践：如何优雅地接入流量防护？
在实际工程中，不建议自己手写限流和熔断逻辑，应该充分利用成熟的开源组件：
Java 生态：Alibaba Sentinel（功能全面，支持控制台动态配置）、Resilience4j（轻量级，Spring Cloud 官方推荐）。
网关层：Nginx（limit_req 模块）、Kong、APISIX。
分布式限流：利用 Redis + Lua 脚本实现全局限流，或者使用 Redisson 的 RRateLimiter。
💡 避坑指南：
限流后的提示要友好：不要直接给用户返回 500 Internal Server Error，应该返回 429 Too Many Requests 并提示“当前访问人数过多，请稍后再试”。
熔断阈值要合理：不要设置得太敏感，否则网络稍微抖动就会触发熔断；也不要太迟钝，导致连锁故障已经发生才生效。
必须有监控：限流和熔断的触发情况必须接入 Prometheus + Grafana，做到“触发即告警”，及时发现并处理异常。
结语：
API 的稳定性，不是靠运气，而是靠设计出来的。限流、熔断、降级，这三道防线构成了高可用系统的底座。在系统上线前，不妨问自己一个问题：“如果现在的流量翻 10 倍，或者下游服务出现异常，我的系统还能平稳运行吗？”
