网关层与业务层限流不是二选一，而是漏斗式分工：网关层做入口粗筛和全局防护，业务层做语义细筛和核心资源保护。把这两层放对位置，系统在大促和突发流量下才不会一边被刷爆、一边误杀正常用户，下面按分工边界、场景拆解和配合方法讲清楚。
为什么限流要拆成两层？先看两层各自看得见什么
你可以把网关层想成小区大门,业务层是单元门，大门拦的是明显可疑的人流，单元门才知道谁家来了多少客人、家里坐不坐得下，限流也一样，每一层只处理自己看得懂的信息。
网关层：站在门口，先挡住明显不合理的流量
网关层的位置在认证、路由和协议转换附近，能看到 IP、租户、API 路径、Header、总 QPS、并发连接数，它适合做粗粒度、全局性的限流。
- 按 IP 限制请求频率，挡住脚本刷接口。
- 按租户或 appKey 限制总调用量，保护开放平台。
- 按路由限制 QPS，防止某个接口把后端拖垮。
- 按并发连接数做入口保护,配合黑白名单和防爬策略。
常见操作路径并不复杂,Nginx 在 http 块定义 limit_req_zone，在 location 里启用 limit_req；Spring Cloud Gateway 在路由上挂 RequestRateLimiter 过滤器，用 Redis 令牌桶按用户 ID 或 IP 做 key；APISIX 在路由上启用 limit-count 插件，key_type 选 var，key 用 remote_addr 或 consumer_name，这些配置的共同点是：网关层不关心订单状态，也不关心库存还有多少。
业务层：进到屋里，才知道谁在办什么事
业务层能看到用户等级、订单状态、商品热度、活动库存、数据库连接池和下游依赖，它适合做细粒度、语义化的限流。
- 秒杀扣库存时,按商品 ID 做热点参数限流。
- 优惠券领取时,按活动 ID 做集群限流。
- 短信验证码接口按手机号和 IP 组合限流。
- 订单创建接口按用户 ID 和会员等级分配配额。
- 库存服务用信号量隔离数据库连接,防止慢查询拖垮连接池。
在 Spring 生态里，可以用 Sentinel 给资源定义热点规则，blockHandler 统一处理拒绝逻辑；也可以基于 Redis + Lua 做分布式令牌桶，把阈值放在配置中心动态调整。业务层限流的价值不在“拦得多”，而在“拦得准”。
| 对比维度 | 网关层限流 | 业务层限流 |
|---|---|---|
| 限流对象 | IP、租户、路由、API 路径 | 用户、商品、活动、订单、下游资源 |
| 判断依据 | 入口流量特征 | 业务状态和资源瓶颈 |
| 粒度 | 粗粒度 | 细粒度 |
| 主要作用 | 挡外敌、保全局 | 识内情、保核心 |
| 典型风险 | 看不到业务语义，容易误杀或漏放 | 重复建设，入口被打进来后才限流 |
行业共识认为,限流不是越靠前越好，而是分层过滤，网关层把明显超额的流量挡在外面，业务层把真正稀缺的资源守住，两者各司其职。
网关层和业务层限流有什么区别？先看分工边界
网关层负责“粗”和“全”
网关层适合承担全局配额，比如单 IP 每分钟请求数、单租户总 QPS、单路由并发连接数、开放 API 的调用方配额，它的优势是统一、快、覆盖面广，一次配置能保护后面一片服务。
但网关层有两个边界要守住：
- 不要试图在网关层判断“这个用户是不是黑卡”“这个商品是不是热点”，这些信息网关通常拿不到。
- 不要让网关层承担所有业务规则的限流,否则网关配置会越来越重，变更也越来越慢。
业务层负责“细”和“准”
业务层适合承担资源保护和业务规则，比如库存扣减、优惠券领取、订单创建、支付回调、短信发送，这些接口的瓶颈往往不在入口，而在数据库、缓存、下游服务或业务状态。
业务层限流要避免一个常见问题：每个服务各写一套，更稳的做法是统一限流 SDK，把规则放在配置中心，按服务、接口、资源维度维护，这样既能精细控制，又不会把限流逻辑散落在代码里。
什么时候网关层必须限流
- 开放平台按调用方配额收费或分级服务。
- 大促入口需要先挡掉明显异常的 IP 和脚本流量。
- 网关后面挂了很多服务,需要按路由做整体保护。
- 需要快速上线黑白名单和频率限制,不想改业务代码。
什么时候业务层必须限流
- 秒杀、抢购、优惠券领取等有明确热点资源的场景。
- 订单创建、支付回调等涉及数据库写入的接口。
- 短信、邮件、推送等调用外部资源的接口。
- 下游服务容量有限,需要按调用方或业务维度隔离。
微服务架构下限流放在网关还是业务层？按场景拆
南北向流量：网关先粗筛，业务层再细筛
外部用户请求从网关进入,属于南北向流量，网关层先按 IP、租户、路由做第一道粗筛，业务层再按用户、商品、活动做第二道细筛，两层阈值不要用同一个维度重复卡，否则容易出现“网关放过了、业务层又按同一规则拦一次”的误杀。
东西向流量：网关通常不掺和，业务层自己兜底
服务之间的内部调用属于东西向流量,很多网关并不经过，这类流量更适合在业务层用 RPC 限流、线程池隔离、信号量隔离或服务网格侧车来做。网关层管入口，业务层管资源，这个边界在微服务架构下尤其重要。
北京电商系统网关层限流怎么做？按端和租户分桶
以北京电商系统网关层限流怎么做为例,入口通常分 App、小程序、H5 和开放平台，网关层先按端和租户做配额，App 端单 IP 频率限制、开放平台按 appKey 限总调用量、H5 端按路由限 QPS，业务层再按活动和商品做细筛，秒杀商品单独提高保护等级，这样既不会让网关配置爆炸，也不会让业务服务裸奔。
API网关限流配置多少钱？成本要算三笔账
API网关限流配置多少钱,不能只看软件报价，成本通常分三块：
- 软件许可成本：开源网关如 APISIX、Kong 没有商业许可费，云厂商 API 网关通常按调用次数、实例规格或带宽计费。
- 人力运维成本：自建网关要投入部署、插件开发、监控告警和容量规划，这部分往往比软件费用更高。
- 变更试错成本：限流阈值配错会导致误杀或漏放，需要灰度发布、压测和回滚机制。
中小规模场景下,开源方案加托管 Redis 往往更灵活；调用量稳定且团队不想运维时，云网关按量计费更省心。价格不是分工依据，流量结构和团队运维能力才是。
| 场景 | 网关层职责 | 业务层职责 |
|---|---|---|
| 开放 API | 按 appKey 配总调用量 | 按租户套餐和功能点限流 |
| 电商大促 | 按 IP、路由粗筛 | 按商品、活动、用户细筛 |
| 内部服务调用 | 通常不参与 | RPC 限流、线程池隔离 |
| 多租户 SaaS | 按租户总 QPS 分桶 | 按套餐和资源池限流 |
高并发场景下网关层与业务层限流怎么配合
高并发场景下网关层与业务层限流怎么配合,核心是做成漏斗：网关层先挡住超额入口流量，业务层再守住核心资源，最后用降级和排队兜底。
- 用 wrk 或 JMeter 做阶梯压测，记录单实例安全承载、P99 延迟和错误率。
- 在网关按路由配置集群限流,key 用 IP、租户或 appKey，拒绝策略返回统一的 429。
- 在业务服务用 Sentinel 配置热点参数规则，按商品 ID、用户 ID 或活动 ID 限流。
- 给核心接口配置快速失败、排队等待或预热模式，避免流量突刺直接打穿数据库。
- 把阈值放进配置中心,先灰度小流量，观察 429 比例、线程池活跃数和数据库连接池使用率。
- 统一错误码和重试策略,网关层拒绝的请求不要让客户端疯狂重试。
需要监控的指标也要分层：网关层看入口 QPS、429 比例、P99 延迟；业务层看资源 QPS、线程池队列长度、数据库连接池使用率、下游错误率，近年来，云原生网关和 Service Mesh 把部分限流能力下沉到数据面，但业务语义仍然留在业务层。网关层保入口，业务层保核心，这个分工没有变。
网关层与业务层限流分工Q&A
问：网关层限流了，业务层还要限流吗？
要，网关层看不到库存、订单状态和数据库连接池，业务层要兜住核心资源和业务规则，两层维度错开，网关管入口总量，业务层管资源热点。
问：小团队没有独立网关，能不能只在业务层限流？
可以，但入口防护会弱一些，更实际的做法是先用 Nginx 的 limit_req 做轻量网关层粗筛，再在业务层用 Sentinel 或 Redis 令牌桶做细筛，成本不高，边界也清楚。
问：网关层和业务层限流阈值怎么定？
以压测容量为基线，网关层按入口总容量和租户配额定，业务层按资源瓶颈和业务规则定，阈值放在配置中心，灰度调整并保留回滚开关，阈值来自压测和容量评估，不来自拍脑袋。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/784715.html
