微服务架构中，网关层和服务层的限流策略如何协同工作
在微服务架构中，网关层与服务层的限流并非相互替代，而是分工明确的协同关系。它们共同构成了一道纵深防御体系，确保系统稳定。
🎯 角色分工：各司其职
| 层级 | 核心职责 | 实现方案 |
|---|---|---|
| 网关层 | 全局入口防护： 作为系统的唯一入口，负责粗粒度的、面向所有外部流量的统一限流。 | •Nginx：基于 IP、地理位置等进行限流，防御 DDoS 和恶意请求。 •API 网关(如 Spring Cloud Gateway)：基于接口、用户、AppID 等进行限流，支持分布式。 •开放平台：在此层完成签名校验、统一鉴权和防刷。 |
| 服务层 | 精细化业务保护： 作为系统的最后防线，负责细粒度的、针对内部服务和关键资源的限流。 | •Sentinel：实现 QPS/线程数限流、熔断降级、热点参数限流。 •Resilience4j：通过注解实现方法级的限流和熔断。 •Guava RateLimiter：用于单机内的本地限流（如保护某个关键 Bean）。 |
🤝 协同模式：分层拦截，逐级过滤
一个典型的请求链路如下，每一层都扮演着“过滤网”的角色：
外部请求 → 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 监控各层级的限流触发情况，当频繁触发时，及时告警并考虑扩容或优化。
🚀 总结：构建纵深防御体系
微服务架构下的限流，应构建“网关层全局兜底 + 服务层精细防护”的分层防御体系。
- 网关层：作为流量总闸门，负责宏观的、通用的限流策略。
- 服务层：作为业务保险丝，负责微观的、针对核心资源的精细化保护。
两者协同工作，既能有效抵御外部洪峰，又能防止内部故障扩散，共同保障系统的稳定与高可用。