网关必须做负载均衡，因为单节点网关是典型单点故障源，宕机即全站中断；而流量波峰明显、垂直扩容成本高上限低，唯有横向扩展多实例+LB才能保障高可用与弹性伸缩能力。
为什么网关必须做负载均衡
单节点网关是系统最典型的单点故障源。一旦宕机，所有外部HTTP请求全部中断，协议转换、鉴权、限流等能力瞬间失效。而真实业务场景中，流量具有明显波峰特征——比如电商大促、秒杀活动、突发安全事件上报，瞬时QPS可能翻数倍。仅靠垂直扩容（升级单机CPU/内存）成本高、上限低、恢复慢。横向扩展才是根本解法：部署多个网关实例组成算力集群，再由负载均衡器统一承接入口流量，按需分发。这不仅是容量问题，更是可用性问题——Nginx或LVS能自动摘除异常节点，保障99.9%以上的服务连续性。
Nginx作为网关前置LB的实操要点
Nginx是最常用、最轻量、最易落地的网关层负载均衡方案，适用于绝大多数HTTP/S场景。
-
配置stream模块处理TCP层转发：API网关常暴露非HTTP端口（如8080、9000），需在nginx.conf顶层启用
stream{}块，而非仅用http{}。否则无法透传原始TCP连接，影响长连接、gRPC或CrowdSec类二进制协议。 -
上游服务健康检查要显式开启：默认Nginx不主动探测后端状态。需添加
health_check interval=3 fails=2 passes=2，避免把请求打到已僵死但未断连的网关实例上。 -
权重与连接复用兼顾：用
weight=5可区分实例性能差异；keepalive 32复用后端连接池，降低TIME_WAIT堆积和TLS握手开销。 -
故障转移必须配
proxy_next_upstream：仅设on不够，建议组合error timeout http_502 http_503 http_504，确保一次失败立即换节点重试。
结合注册中心实现动态负载（Nacos/Spring Cloud）
纯静态Nginx配置在微服务环境下维护成本高。更推荐“注册中心+网关内置LB”双层架构：
-
网关自身集成LoadBalancer：Spring Cloud Gateway通过
lb://service-name语法自动从Nacos/Eureka拉取健康实例列表，无需在Nginx里硬编码IP。路由配置中直接写服务名，动态感知扩缩容。 - Nginx退为边缘接入层：只负责最外层HTTPS卸载、WAF规则、DDoS防护和跨AZ流量分发；内部服务间调用交由网关自身的响应式负载均衡器处理，降低延迟。
- 数据库与配置必须共享：多网关实例共用同一套PostgreSQL或MySQL元数据（如路由规则、黑白名单、限流策略），否则会出现策略不一致。CrowdSec、自研网关均需此设计。
- 注意会话保持边界：HTTP层可基于cookie或header做sticky session；但RPC泛化调用（如Dubbo泛化、gRPC）本身无会话概念，不应强依赖IP Hash，否则破坏负载均衡公平性。
LVS适合什么场景？何时该换它
LVS工作在内核IP层，吞吐能力远超Nginx，但配置复杂、调试困难，适合对性能有极致要求且协议较单一的场景。
- 适用场景：百万级并发连接、固定端口的四层透传（如网关集群统一监听8080）、金融核心链路要求亚毫秒级转发延迟。
- 慎用场景：需要URL重写、Header修改、JWT校验、动态路由匹配等七层功能——LVS做不到，必须搭配Nginx或网关自身处理。
- DR模式是首选：Real Server直接返回客户端，Director只负责入向分发，性能最高。但要求所有节点在同一局域网，且需配置ARP抑制防止地址冲突。
- 务必配Heartbeat或Keepalived：LVS Director本身是单点，必须用Keepalived实现VIP漂移，否则又引入新单点。
