负载均衡负责流量调度与粗粒度限流，网关聚焦业务语义与细分策略，二者分工是“无状态分流”与“有状态精控”的结合。
为什么需要细粒度限流，而不是一刀切
传统限流模式往往在网关层设置全局阈值,比如每秒放行1000个请求，这种方案在面对单一流量模型时勉强可用，但一旦业务场景复杂，问题就暴露了。
举个例子,一个电商系统在秒杀活动中，商品查询接口与下单接口的流量特征完全不同，查询接口可能瞬时涌入数万请求，而下单接口受限于库存，压力相对平稳，如果网关层用一个总限流值去压制，查询接口的高并发会直接拖垮整个网关，导致下单接口的请求被无辜拒绝，这就是行业共识所强调的“限流粒度不足导致业务雪崩”。
细粒度限流的核心在于区分不同用户等级、不同API优先级、不同服务实例的健康状态。 比如VIP用户请求优先放行，普通用户请求降级处理；核心交易接口限流阈值高，非核心日志接口阈值低，这种策略需要流量调度层与业务处理层协同配合，负载均衡与网关各司其职。
负载均衡与网关的分工边界
负载均衡：流量入口的“门卫”
负载均衡器处于流量入口的最前端,负责网络层的流量分发，它的限流能力集中在连接级别和IP级别，属于粗粒度控制。
负载均衡能做什么：
- 基于IP地址或网段进行请求频率限制,防止DDoS攻击打穿后端
- 基于连接数限制,避免后端服务器被过多长连接压垮
- 基于节点健康状态,自动摘除故障实例实现基本熔断
负载均衡不擅长什么：
- 无法识别HTTP请求头中的用户Token,无法区分VIP与普通用户
- 无法分析请求路径,比如无法单独对“/api/order”路径设置100 QPS
- 无法感知业务状态,比如商品库存还剩多少，是否需要触发限流降级
行业观点认为,在四层负载均衡（如LVS、Nginx Stream）层面，限流策略应保持简单，如果在此处做复杂逻辑，性能损耗会显著增加，且配置难以维护，多数情况下，Nginx七层负载均衡配合limit_req模块，可以实现基于IP的请求频率限制，这已经足够应对流量清洗场景。
网关：业务语义的“哨兵”
网关位于负载均衡之后,直接面向微服务实例。它的限流能力覆盖应用层所有语义，是细粒度策略的执行者。
网关能做什么：
- 根据请求路径、方法、参数进行差异化限流，/api/order”路径限流500 QPS，“/api/search”路径限流2000 QPS
- 根据用户ID、用户等级进行限流，VIP用户额度高，普通用户额度低
- 根据请求来源（App端、Web端、第三方开放平台）分别设置阈值
- 联动服务熔断与降级,当后端服务超时率超过阈值时，网关直接返回降级响应
网关限流的具体实现：
- 基于令牌桶算法,支持突发流量平滑处理
- 基于漏桶算法,保证请求速率绝对恒定
- 基于滑动窗口,避免临界时间点流量突刺
举个例子,Spring Cloud Gateway结合Redis实现分布式限流，可以精准控制每个用户的请求频率，比如设置“每个用户每秒最多调用5次下单接口”，超出后返回429状态码，并在响应头中告知用户“限流解除时间”，这种能力负载均衡器无法提供。
如何协同：负载均衡粗筛，网关精控
第一道防线：负载均衡做流量清洗
负载均衡器的首要任务是过滤恶意流量和异常流量,比如统计每个IP的连接数，如果某个IP在10秒内新建了1000个连接，明显是攻击行为，直接拒绝，这种策略不需要解析HTTP请求体，性能开销极低，每秒可处理百万级连接。
具体操作路径：
- 在Nginx http块中配置limit_conn_zone，限制单IP并发连接数
- 在stream块中配置limit_conn,限制TCP连接速率
- 结合geo模块,对境外IP或黑名单IP直接返回444
这一层限流的目标是“粗中带快”，不追求精确，只追求在极端流量下保护后端系统不被打死。
第二道防线：网关做业务级限流
经过负载均衡清洗后,流量到达网关，网关开始解析请求上下文，执行精细化的业务限流策略。
操作步骤示例：
- 在网关路由配置中,为每个微服务接口设置默认限流阈值
- 通过请求头中的用户ID,查询Redis中该用户的调用次数，判断是否超限
- 如果是VIP用户,动态调整阈值，比如默认阈值提升3倍
- 如果接口调用量超过阈值,返回降级响应，同时记录日志用于后续扩缩容决策
网关限流配置的关键参数：
- 令牌桶容量：决定突发流量耐受度
- 令牌填充速率：决定长期平均QPS
- 超时等待时间：达到限流时是否排队等待，还是直接拒绝
配置同步与动态调整
负载均衡与网关的限流策略并非一成不变,业务高峰期（比如双十一）需要动态调整阈值，避免误杀正常流量。机制是：网关通过监控平台实时上报限流命中率，运维人员根据数据调整负载均衡的粗粒度阈值，或通过配置中心下发新策略给网关。
网关发现“/api/order”接口限流命中率超过30%，说明后端压力过大，需要降级，此时配置中心将负载均衡中该接口的后端权重调低，从而减少进入网关的流量，这种联动机制能有效避免级联故障。
实践建议：选择适合你的分工模型
轻量级模型，适合中小团队
- 负载均衡使用Nginx,做IP级别限流，配置简单
- 网关使用Spring Cloud Gateway或Kong，做API级别限流，集成Redis
- 监控工具使用Prometheus,采集网关限流指标，人工决策调整
企业级模型，适合高并发场景
- 负载均衡使用F5或LVS,配合Nginx做七层分流，限流策略集中在连接管理
- 网关使用高性能网关如Kong或Shenyu,支持热加载限流插件
- 引入集中配置中心（如Apollo、Nacos），策略下发自动化
- 结合服务网格（如Istio），在Sidecar层面实现更细粒度的流量控制
常见误区：
- 在四层负载均衡解析HTTP请求,这会消耗大量CPU，且维护成本高
- 网关限流阈值设置过死,导致正常流量被误杀，建议设置20%的缓冲余量
- 网关不做限流,全部依赖负载均衡，这会导致业务语义丢失，无法精准控制
负载均衡与网关的限流分工可以概括为“粗筛精控”，前者解决流量入口的安全与稳定，后者实现业务层面的精细化管理，两者协同，才能保证系统在突发流量下既稳定又精准。不要试图让网关承担所有限流责任，也不要在负载均衡层做复杂业务判断。 清晰的分工边界，是构建高可用微服务架构的基础。
Q&A：负载均衡和网关限流有什么不同
Q：负载均衡能代替网关做限流吗？
不能，负载均衡的限流能力集中在网络层和连接层，无法感知HTTP请求中的业务信息，比如用户等级、请求路径，网关限流可以做到用户维度、API维度，两者不可替代，需要配合使用。
Q：网关限流是不是越细越好？
不是，过于细粒度的限流策略会增加CPU和内存开销，也可能导致业务逻辑过于复杂，建议根据业务核心程度划分优先级，对核心接口做细粒度限流，非核心接口使用粗粒度限流。
Q：如何选择网关限流算法？
常用算法有令牌桶和漏桶，令牌桶适合允许突发流量的场景，漏桶适合要求请求速率绝对均匀的场景，多数业务场景下，令牌桶算法配合滑动窗口即可满足需求。