负载均衡无标准答案，只有适配场景的方案：四层快但功能少，七层功能全但开销大；nginx轻量灵活，haproxy稳定专业，lvs性能高但仅四层，f5功能强但成本高；客户端lb适合微服务，dns lb风险高需慎用。
负载均衡没有“标准答案”，只有“适配场景”的方案。选错类型，轻则浪费资源，重则引发会话丢失、连接堆积或健康检查误判。
四层 vs 七层：协议层级决定你能做什么
四层（TCP/udp）负载均衡只看 IP+端口，不解析 http 头，转发快、开销小，适合高并发透传场景（如 websocket、mysql、redis）。但你没法基于 Host 或 Path 做路由，也做不了 https 卸载。
七层（HTTP/HTTPS）能读请求内容，支持 rewrite、header 改写、URL 匹配、ssl 终止等，Nginx 和 HAProxy 默认走七层。但代价是 CPU 消耗高、延迟略增，万级 QPS 下需压测验证吞吐瓶颈。
- 用 LVS 或 F5 做四层入口 + Nginx 做七层分发，是常见分层架构
- 云厂商 SLB 默认四层（性能高），ALB 才是七层（功能全），别混用控制台选项
- 若后端服务本身已做 TLS 终止（如 spring Boot 配了 keystore），就别在 LB 层再做 SSL 卸载，否则多一次加解密
Nginx / HAProxy / LVS / F5：怎么选不翻车
不是越贵越好，也不是越新越稳——关键看你的运维能力与流量特征。
-
Nginx：轻量、配置灵活、自带缓存和限流，适合中小团队。但默认不支持动态权重调整（需配合 lua 或 openresty），健康检查仅靠tcp_check或简单 HTTP 状态码，易漏判长连接卡死 -
HAProxy：专为负载均衡设计，leastconn、http-check、stick-table原生支持好，监控指标丰富（stats uri直接暴露），适合对稳定性要求高的业务 -
LVS：内核态转发，性能天花板高（10G+ 网卡轻松扛百万并发），但仅支持四层，配置复杂（ipvsadm命令晦涩），无原生日志和细粒度路由能力 -
F5 BIG-IP：硬件+软件一体化，WAF、DNS 负载、iRules 编程能力强，但 license 昂贵、升级需停机窗口，中小公司慎入
客户端负载均衡（ribbon/Feign）为什么越来越常见
微服务场景下，服务发现 + 客户端 LB 正在替代传统中心化网关。它绕开了单点 LB 的容量瓶颈和故障域，把决策权交给调用方。
- Ribbon 已进入维护模式，spring cloud 2020+ 推荐用
spring-cloud-starter-loadbalancer - 必须配合注册中心（如 Nacos/eureka）使用，否则
ServiceInstanceListSupplier拿不到可用实例 - 注意线程模型：WebFlux（Reactor）下要用响应式 LB 实现，否则阻塞线程池会导致连接耗尽
- 默认策略是轮询，但没做连接数感知——若某实例 TCP 连接已满，仍可能被选中，需自定义
ReactorServiceInstanceLoadBalancer
DNS 负载均衡：看着简单，实际最危险
靠 DNS 返回多个 A 记录实现“负载”，成本低、部署快，但问题隐蔽：
- TTL 设置过长（如 300s），后端宕机后用户仍会持续访问故障 IP，最长要等 5 分钟才刷新
- 客户端本地 DNS 缓存、运营商递归 DNS 缓存、浏览器预加载都可能绕过你的 TTL 控制
- 完全无法感知后端真实负载，高峰期容易雪崩；也不支持权重、健康检查、会话保持
- 仅建议用于静态资源 CDN 回源、跨地域容灾（如主站挂了切到备用域名），绝不用于核心 API 流量分发
真正难的不是选哪种方式，而是识别出“当前流量特征是否匹配该方案的假设前提”——比如用 IP Hash 做会话保持，却忽略了 NAT 环境下大量用户共用一个出口 IP；又比如在容器环境里给 Pod 配固定权重，却忘了副本数随时伸缩。这些细节，往往比算法本身更影响线上稳定性。