在微服务架构中，网关层与服务层的限流并非相互替代，而是分工明确的协同关系。它们共同构成了一道纵深防御体系，确保系统稳定。

🎯 角色分工：各司其职

🤝 协同模式：分层拦截，逐级过滤

一个典型的请求链路如下，每一层都扮演着“过滤网”的角色：

外部请求 → Nginx → API 网关 → 微服务 A → 微服务 B

1. 第一层：Nginx (边缘防护)

• 目标：拦截恶意流量，如 DDoS 攻击、单一 IP 的疯狂刷接口。
• 策略：基于 IP 或地理位置进行限流，例如限制单个 IP 每秒最多 10 次请求。超出阈值的请求在到达网关前即被拒绝。

2. 第二层：API 网关 (全局限流)

• 目标：保护整个后端服务集群，防止流量过载。
• 策略：基于接口、用户、AppID 等维度进行限流。例如，限制/api/order接口对所有用户的总 QPS 为 1000。
• 协同方式：网关的限流阈值应小于后端服务的承载能力，为服务层预留处理余量。例如，网关限 1000 QPS，服务层设计为能稳定处理 800 QPS。

3. 第三层：服务层 (精细防护)

• 目标：保护核心业务和资源，防止雪崩效应。
• 策略：
  • 核心接口：对“下单”、“支付”等关键接口进行严格的 QPS 限制。
  • 核心资源：针对热点数据（如某热门商品）进行限流，防止数据库被击穿。
  • 内部调用：使用 Resilience4j 或 Sentinel 对下游服务调用进行限流和熔断，避免级联故障。

💡 实战策略：如何协同配置

1. 流量配额分配
采用“漏斗式”配额分配，确保层层递减：

• 系统总容量：1000 QPS
• Nginx 层：限制为 900 QPS，拦截异常流量。
• 网关层：限制为 800 QPS，作为全局流量红线。
• 服务层：核心服务 A 分配 500 QPS，非核心服务 B 分配 300 QPS。

2. 限流维度设计

• 网关层：侧重宏观维度，如按 AppID、接口、IP 段进行限流。
• 服务层：侧重微观维度，如按用户 ID、热点参数（商品 ID）、方法级别进行限流。

3. 降级策略联动

• 网关层：返回统一的降级响应，如429 Too Many Requests或排队页面。
• 服务层：执行更具体的降级逻辑，如返回缓存数据、默认值，或直接抛出业务异常。

4. 动态配置与监控

• 配置中心：使用 Nacos、Apollo 等统一管理网关和服务层的限流规则，实现动态调整。
• 监控告警：通过 Prometheus + Grafana 监控各层级的限流触发情况，当频繁触发时，及时告警并考虑扩容或优化。

🚀 总结：构建纵深防御体系

微服务架构下的限流，应构建“网关层全局兜底 + 服务层精细防护”的分层防御体系。

• 网关层：作为流量总闸门，负责宏观的、通用的限流策略。
• 服务层：作为业务保险丝，负责微观的、针对核心资源的精细化保护。

两者协同工作，既能有效抵御外部洪峰，又能防止内部故障扩散，共同保障系统的稳定与高可用。

🔥 关注公众号【云技纵横】，目前正在更新分布式缓存进阶技巧和干货