网关层负责全局流量整形和基础防护，业务层负责精细化业务限流和降级，两者分工的核心在于流量过滤的粒度与成本权衡。
网关层限流和业务层限流的区别
在微服务架构中，限流是保障系统稳定的关键手段，但网关层和业务层的限流方式差异很大，了解这些区别,才能合理分配职责。
定位差异：全局防守 vs 业务定制
网关层限流像一个大门保安，对所有进入的流量做统一检查，不关心具体业务，只根据IP、路径、全局QPS等维度做粗粒度过滤，业务层限流则是每个房间的管家，熟悉业务逻辑，能针对特定用户、商品、订单做细粒度控制。
实现手段：集中式 vs 分布式
网关层限流通常依赖集中式组件，如Nginx、Kong、Spring Cloud Gateway，结合Redis或本地计数器实现，业务层限流更多在代码内部，通过RateLimiter、Sentinel、Resilience4j等库实现分布式限流,需要同步状态。
成本与灵活性对比
| 维度 | 网关层限流 | 业务层限流 |
|---|---|---|
| 开发成本 | 配置即可，较低 | 需要编码，较高 |
| 运维成本 | 集中管理，较低 | 分散在各服务，较高 |
| 灵活性 | 低，仅支持通用规则 | 高，可定制业务规则 |
| 性能影响 | 在网关统一处理，对业务无侵入 | 业务进程内计算，有一定开销 |
行业共识认为，两者的成本差异决定了限流职责的初步划分，网关层适合处理通用、高频的限流场景，业务层适合处理复杂、个性化的限流逻辑。
如何划分网关层与业务层的限流职责
明确区别后，关键是如何划分具体职责,以下原则可以帮助团队做出合理决策。
基于流量来源划分
- 外部流量：网关层拦截来自外部的恶意流量和突发流量，如IP黑名单、地区限制、全局限流。
- 内部流量：业务层处理内部的正常流量，如用户级别的调用频率、服务间的依赖限制。
基于业务重要性划分
- 核心业务（如支付、下单）：需要在业务层做精细限流，避免误伤，一个VIP用户频繁调用，网关层不应直接拒绝,而是交由业务层判断。
- 非核心业务（如查询、日志）：可以在网关层统一限流,减轻业务压力。
基于响应时间划分
- 延迟敏感业务：网关层限流优先，在请求到达业务前就拒绝,节省资源。
- 允许排队业务：业务层限流可以更平滑地处理瞬间流量,通过队列或降级策略。
限流策略在网关层和业务层怎么分配：一个实战案例
假设一个电商系统，同时处理正常购买和秒杀活动，网关层配置全局限流：每秒最多1000请求，超过则返回503，业务层则针对秒杀接口做用户级限流：每个用户每秒最多1次请求，并检查用户等级，这样，网关层防止了流量洪峰冲垮服务，业务层保障了公平性,这种分配方式在微服务限流网关层业务层分工中非常常见。
场景化分工实践：从灰度到全量
不同场景下，网关层和业务层的分工侧重不同,以下列出了常见场景的推荐做法。
网关层限流场景
- 防DDoS攻击：在网关层按IP、User-Agent进行限流,阻断恶意流量。
- 多租户隔离：为不同客户分配独立配额,在网关层直接拦截超额请求。
- 地域限制：根据请求来源地区进行限流,比如仅允许中国IP访问。
实操步骤：在Nginx配置中，使用limit_req_zone定义共享内存区域和速率，然后在location中应用limit_req，设置burst和nodelay。limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; limit_req zone=one burst=20 nodelay;。
业务层限流场景
- 秒杀活动：按用户ID、商品ID进行限流，确保公平性，使用Sentinel的
@SentinelResource注解定义资源,设置QPS阈值。 - 积分兑换：按用户等级每日限制兑换次数，在业务代码中通过Redis计数器实现,每天重置。
- 接口降级：当依赖服务超时，业务层主动限流并返回降级结果，使用Resilience4j的RateLimiter,设置超时等待时间。
实操步骤：在Spring Boot应用中引入Sentinel，定义资源名，配置QPS阈值，并设置降级回调函数。@SentinelResource(value = "checkout", blockHandler = "checkoutBlock")
。
业内专家指出，混合使用限流时，需要避免重复限制，网关层按URL限流，业务层又按相同URL限流，会导致请求被双重拒绝，解决方法是统一限流维度，让网关层关注全局,业务层关注局部。
网关层与业务层限流分工常见问题
网关层限流和业务层限流可以互相替代吗？
不能，网关层限流无法感知业务上下文，比如无法区分VIP用户和普通用户；业务层限流无法覆盖全局异常流量，比如整个集群的突发请求，两者互补，建议同时使用，网关限流和业务限流如何分工,关键在于流量特征的粒度。
划分限流职责时应该考虑哪些成本因素？
主要考虑硬件开销和开发维护成本，网关层限流通常由运维团队配置，成本较低但规则有限；业务层限流需要开发团队编码，成本较高但灵活，多数情况下，团队会先以网关层限流起步，再逐步引入业务层限流优化，统计发现，仅网关层限流就能解决相当一部分流量冲击,但剩余精细场景需要业务层介入。
如何确保网关层和业务层限流不冲突？
统一限流指标是关键，网关层限制总QPS，业务层限制用户级别QPS，两者维度不同，不会冲突，如果维度相同，可以通过设置优先级，让网关层放行所有请求，业务层做最终决定,或者通过传递限流标记避免重复计数。
限流分工的本质是成本与灵活性的平衡，网关层担当第一道防线，业务层负责精准控制,两者协同才能有效保障系统稳定。