4. API Gateway 限流架构模式：集中式 vs 分布式、网关层 vs 业务层、本地 vs 集群

在微服务架构中，限流的实现方式并非单一。根据控制点、决策范围和资源隔离程度，可以划分为三组核心架构模式。理解这些模式的差异，是进行参数调优的前提。

4.1 三大限流架构维度对比

4.2 集中式限流 vs 分布式限流

集中式限流：所有网关节点共享同一个全局计数器（通常存储在 Redis 或 Etcd 中）。请求到达时，网关向中心存储发起原子增减操作，判断是否超过阈值。

• 优点：全局精确，无节点间偏差。
• 缺点：每次请求增加一次网络 RTT（往返时延），中心化组件成为性能瓶颈。
• 适用场景：对精度要求极高、集群规模较小（< 10 节点）、QPS 低于 10 万的场景。

分布式限流：每个网关节点独立维护本地计数器，通过“配额分配”或“近似同步”算法（如令牌桶 + 定期同步）实现整体约束。

• 优点：无中心依赖，延迟极低，水平扩展能力强。
• 缺点：存在瞬时超限窗口（误差通常在 5%~15%），需要容忍一定偏差。
• 适用场景：高 QPS（> 50 万）、集群规模大、允许少量突发超限的业务。

4.3 网关层限流 vs 业务层限流

网关层限流：限流逻辑部署在 API Gateway 中，对所有进入微服务集群的流量进行统一管控。

• 优势：集中管控、配置热更新、与业务代码解耦。
• 劣势：无法感知业务语义（如用户等级、订单优先级），只能基于 URL、Header、IP 等通用维度。

业务层限流：限流逻辑嵌入在具体的微服务（如订单服务、支付服务）中，通常使用 Sentinel、Resilience4j 等库实现。

• 优势：可以结合业务上下文（如 VIP 用户放宽限流、按商品品类差异化限流）。
• 劣势：每个服务重复实现，治理分散，配置变更需要重新部署。

4.4 本地限流 vs 集群限流

本地限流：每个进程独立维护计数器，不与其他节点通信。实现简单，使用 Guava RateLimiter 或 AtomicLong 即可完成。

• 典型参数：单节点 QPS = 1000，集群 5 节点，总吞吐 = 5000（但可能因流量不均导致单节点过载）。
• 风险：流量倾斜时，部分节点被限流而其他节点空闲，整体利用率下降。

集群限流：多个节点共享限流状态，通常通过 Redis 的 Lua 脚本或 Etcd 的分布式锁实现全局协调。

• 典型参数：集群总 QPS = 5000，每个节点动态获取配额，流量倾斜时自动补偿。
• 代价：引入额外的网络同步开销，故障时可能触发“限流雪崩”。

4.5 架构模式组合决策矩阵

在实际的 API Gateway 项目中，上述三组模式需要组合决策。以下矩阵总结了常见组合及其典型场景：