负载均衡（Load Balancing）
负载均衡的核心很简单：
把请求分给多台后端，让系统能抗流量、抗故障、还能平滑扩容。
它解决什么问题
- 单机扛不住流量
- 单点故障导致整站不可用
- 发布新版本容易中断服务
- 某个热点接口没法单独扩容
所以负载均衡不只是“分流”，还负责高可用和流量治理。
常见层次
| 层次 | 看什么 | 适合什么 |
|---|---|---|
| DNS | 域名解析结果 | 粗粒度分流 |
| L4 | IP、Port、TCP/UDP | 高性能转发 |
| L7 | URL、Host、Header | Web 系统、网关、灰度 |
如果是常见 Web 服务，最常用的是七层负载均衡。
常见算法
| 算法 | 特点 | 适合场景 |
|---|---|---|
| 轮询 | 简单平均分配 | 机器规格差不多 |
| 加权轮询 | 配置高的机器分更多流量 | 节点规格不一致 |
| 最少连接 | 优先发给连接少的节点 | SSE、WebSocket、长连接 |
| IP Hash | 同一客户端尽量落同一节点 | 临时会话保持 |
一个典型架构
Client -> Load Balancer -> App1 / App2 / App3 -> DB / Cache / MQ
负载均衡放在入口层后，客户端只看见一个统一域名，后端实例可以随时增减。
一个 Nginx 示例
upstream app_backend {
least_conn;
server 127.0.0.1:8001 weight=5;
server 127.0.0.1:8002 weight=3;
server 127.0.0.1:8003 weight=2;
}
server {
listen 80;
location / {
proxy_pass http://app_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
这段配置表达了 3 件事：
- 后端有多个实例
- 入口统一由 Nginx 接收请求
- 分发策略是
least_conn
最容易踩的坑
- 只做分流，不做健康检查
- 应用有状态，却直接上多实例
- 负载均衡本身成了单点
- 忘了透传
X-Forwarded-For等头部
总结
负载均衡本质上是入口层调度器。
它真正带来的不是“平均发请求”，而是：
多实例、高可用、可扩容、可治理。