负载均衡核心目标：把流量 / 请求分发到多个服务实例，避免单点过载，提升吞吐量、可用性、容错能力，贯穿请求入口、服务调用、数据存储全链路。按实现层级分为：四层负载、七层负载、服务发现内置负载均衡、数据库负载均衡，同时包含算法、容错、一致性相关机制。
一、四层负载均衡（传输层 L4）
工作在 TCP/UDP 层，基于 IP + 端口做转发，不解析应用层协议，转发速度极高。
典型实现
LVS（Linux Virtual Server）
内核态实现，性能极强，百万级并发；三种模式：NAT、DR（直接路由，最常用）、TUN 隧道。
DR 模式：请求经过 LVS，响应直接后端服务器返回客户端，不回包经过 LB，性能最优。
硬件 F5、A10：专用硬件负载均衡设备，高性能高可靠，成本高。
特点：只看 IP 端口，无法识别 HTTP URL、Header、Cookie；适合 TCP 长连接、数据库、RPC 流量。
二、七层负载均衡（应用层 L7）
解析 HTTP/HTTPS/RPC 协议，可以基于 URL、Header、Cookie、权重做更智能的分发。
典型实现
Nginx / Nginx‑Plus
nginx
upstream模块实现七层负载均衡，可做反向代理、SSL 卸载、限流、缓存。
nginx
upstream backend {
server 192.168.1.101:8080 weight=2;
server 192.168.1.102:8080 weight=1;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
HAProxy：同时支持 L4+L7，性能优秀，支持健康检查、会话保持，大量用于 Web、MySQL 代理。
云厂商 SLB/ALB：阿里云 ALB、AWS ALB，托管式七层负载均衡。
特点：可以按业务逻辑路由；CPU 消耗高于四层，需要解析协议报文。
三、客户端侧负载均衡（服务发现模式，微服务主流）
无中心代理，客户端本地做负载均衡，SpringCloud、Dubbo、gRPC 都是这套模式。
流程：
服务实例启动注册到注册中心（Nacos/Eureka/Consul）；
客户端从注册中心拉取服务实例列表，缓存本地；
客户端本地执行负载均衡算法，直接调用目标实例，流量不经过中央代理。
组件举例
Dubbo：内置负载均衡（随机、轮询、一致性 hash、最小活跃数）
Spring Cloud LoadBalancer：SpringCloud 官方客户端 LB
gRPC：客户端负载均衡 + NameResolver 服务发现
优点：无代理瓶颈；缺点：每个客户端都要集成 LB 逻辑，实例列表缓存要处理变更。
四、服务端代理模式（Sidecar 边车代理，ServiceMesh）
代表：Istio + Envoy
Sidecar（Envoy）部署在每个业务 Pod 旁边，所有进出流量经过 Sidecar，由 Sidecar 完成负载均衡、熔断、限流、重试。
业务代码完全不需要感知负载均衡逻辑，能力下沉到 Sidecar；
支持高级策略：按版本灰度、流量镜像、熔断、超时控制；
代价：增加一层代理，带来少量性能开销。
五、负载均衡常用分发算法
会话保持：比如基于 Cookie，同一个用户始终打向同一个实例；分布式系统尽量少依赖会话保持，优先无状态设计。
六、关键配套机制（负载均衡必须配合）
1. 健康检查
剔除故障节点，不把请求转发给挂掉实例
四层：TCP 握手探测
七层：HTTP GET/POST 健康接口
注册中心：心跳上报，实例不健康就从列表摘除
2. 故障转移 & 重试
实例调用失败，负载均衡自动选择其他节点重试；
注意幂等，非幂等接口不能随便重试，防止重复创建订单。
3. 会话黏连 vs 无状态
会话黏连会破坏负载均衡效果，最优实践：服务无状态，会话放 Redis 等外部存储。
4. 限流、熔断、降级
负载均衡只管分发，无法防止雪崩，要配合熔断：某个实例大量报错，就暂时隔离该节点。
七、存储层负载均衡
不止 Web/RPC，数据库、缓存同样需要负载均衡：
MySQL：ProxySQL、MaxScale，读写分离，读请求负载均衡到多个从库。
Redis 集群：Redis Cluster 哈希槽分片，客户端 / 代理做分片负载均衡；Twemproxy。
对象存储：多副本，请求分散到多节点。
八、分层架构组合（生产常见完整链路）
用户请求 → 四层 SLB (LVS) → 七层 Nginx/ALB → 微服务（客户端 LB / Istio Envoy） → 数据库代理 → 存储
LVS 扛大流量，做接入层；
Nginx 做 SSL 卸载、路由、限流；
微服务层做服务发现、灰度、熔断；
存储代理做读写分离。
九、几种方案对比
十、容易踩坑
只做负载均衡，没有健康检查，故障节点继续接收流量；
过度使用会话黏连，流量分布严重不均衡；
重试没有限制，故障时造成请求风暴；
四层 LB 下源 IP 丢失，后端拿不到真实客户端 IP，需要开启
X‑Forwarded‑For；一致性 hash 虚拟节点配置不合理，扩容缩容大量缓存失效。
本文原创作者易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢