1. 限流概述：微服务架构中为什么需要限流
1.1 微服务架构中的流量失控风险
在微服务架构中，服务被拆分为多个独立部署的单元，彼此通过轻量级通信协议（如 HTTP/REST、gRPC）协作。这种架构带来了弹性伸缩、独立部署等优势，但也引入了新的流量管理挑战：
- 流量突发：促销活动、热点事件、爬虫攻击等导致瞬间流量激增，远超服务正常处理能力。
- 级联故障：单个服务因过载而响应变慢，导致上游服务线程阻塞、资源耗尽，最终引发整个调用链崩溃（雪崩效应）。
- 资源争抢：多个服务共享数据库、缓存、消息队列等后端资源，无限制的流量会压垮共享基础设施。
- 成本失控：云原生环境下，无节制的流量会直接推高计算资源（Pod、VM）的自动扩缩容成本。
核心观点：限流不是为了防止系统正常运转，而是为了在流量超过系统承载阈值时，主动拒绝部分请求，保障核心服务的可用性和稳定性。
1.2 限流与熔断降级的关系
限流、熔断、降级是微服务架构中保障系统稳定性的三个核心手段，它们既有区别又相互配合。下表梳理了三者的核心差异：
| 机制 | 触发条件 | 作用位置 | 核心目标 | 典型恢复方式 |
|---|---|---|---|---|
| 限流 | 请求速率/并发数超过预设阈值 | 入口（API Gateway、服务入口） | 控制流量速率，防止过载 | 流量回落到阈值以下后自动恢复 |
| 熔断 | 错误率/超时率超过阈值（如 50%） | 调用方（Consumer 侧） | 快速失败，防止级联故障 | 熔断器打开后，经过冷却时间尝试半开 |
| 降级 | 熔断触发或人工决策 | 业务逻辑层 | 提供有损服务，保障核心功能 | 返回兜底数据、执行本地缓存逻辑 |
实践建议：在微服务架构中，通常采用“限流在前、熔断在中、降级在后”的防御策略。API Gateway 负责入口限流，服务间调用使用熔断器（如 Resilience4j、Sentinel），业务层实现降级逻辑。
三者之间的关系可以用以下流程图直观展示：
1.3 API Gateway 在限流中的核心角色
在微服务架构中，API Gateway 作为所有外部请求的单一入口，承担着流量管控的第一道防线。其核心角色体现在以下几个方面：
- 统一限流策略：在网关层集中配置限流规则，避免在每个微服务中重复实现，降低维护成本。
- 多维度限流：支持基于 IP、用户 ID、API 路径、请求参数等多维度的限流，实现精细化流量控制。
- 全局与局部结合：既能对整体入口流量做全局限流，也能针对特定服务或路由做局部限流。
- 与熔断降级联动：网关限流拒绝的请求可以直接返回标准错误响应（如 429），避免无效请求穿透到后端服务。
- 可观测性：网关层可以统一采集限流指标（拒绝数、通过数、等待队列长度），为容量规划和动态调优提供数据支撑。
常见误区：不要认为在网关层做了限流，服务内部就不需要熔断降级了。网关限流只能控制入口流量，无法防止服务间调用链中的级联故障。正确的做法是“网关限流 + 服务熔断”双层防护。
以下架构图展示了 API Gateway 在微服务限流体系中的核心位置：
1.4 限流的核心价值总结
| 价值维度 | 具体表现 | 业务收益 |
|---|---|---|
| 可用性保障 | 防止系统过载导致崩溃 | 核心业务持续可用，SLA 达标 |
| 资源保护 | 控制数据库连接、线程池、内存使用 | 降低基础设施成本，避免资源争抢 |
| 公平性 | 多租户场景下按配额分配流量 | 防止单个用户/客户端抢占全部资源 |
| 成本控制 | 限制无价值流量（爬虫、恶意攻击） | 减少无效计算资源消耗 |
| 可预测性 | 系统在已知负载范围内稳定运行 | 容量规划更准确，运维更从容 |
学习预告：本章后续将深入讲解 API Gateway 中常见的限流算法（令牌桶、漏桶、滑动窗口等），以及如何根据业务场景选择合适的限流策略和参数调优方法。