引子
先问个问题：几百万人在同一秒打开一个 App，请求是怎么被接住的？ 为什么双十一抢购页面没崩？为什么半夜某台服务器悄悄挂了，你刷抖音刷得照样欢？
很多人会说，因为后端有很多台服务器嘛。
对，但只对了一半。机器多了，新的问题跟着就来了：请求给谁？某台坏了怎么办？流量涨了怎么加机器？
干这些活的就是负载均衡器（Load Balancer）。我当年第一次听说它，以为就是个 "分流量" 的，后来才发现它干的活比这多得多。这篇文章用 7 个场景，把它到底是干嘛的说清楚。
1. 均匀分发：别让一台机器累死，其他机器闲死
最经典的用法。用户请求涌进来，负载均衡器按一定规则分给后面的服务器，常见的规则有轮询（一家一次）、加权轮询（配置高的多干点）、最少连接（谁手上的活少给谁）。
流量摊开了，没有哪台机器会被单独压垮，整体系统能扛的量自然就上去了。
顺带说一句，这几种算法没有谁最好，只有谁更合适。请求都差不多的场景用轮询就够了；机器配置参差不齐，就上加权。
2. SSL 卸载：解密的活儿，别折腾后端
现在满大街都是 HTTPS。你可能不知道，TLS 握手里的非对称加密是相当吃 CPU 的，如果每台后端服务器都要自己解一遍密，等于让干正事的人天天分心干杂活。
负载均衡器可以把这个活揽过来：加密流量到它这儿统一解密，往后端走的都是明文（内网里这样是安全的，也是行业常规做法）。
后端的 CPU 省下来了，就能多干活。机器不用升级，性能白白提升一截，这笔账很划算。
3. 会话保持：让用户每次都找到同一台机器
想象一个场景：你往购物车里加了件东西，结果刷新一下页面，购物车空了。
为什么？你的会话数据存在 A 机器上，下一次请求却被分到了 B 机器。B 不认识你，自然什么都查不到。
会话保持就是解决这个问题的：通过源 IP 哈希、Cookie 插入这类办法，保证同一个用户的请求始终落到同一台机器上。
只要业务是 "有状态" 的，比如登录、购物车，这个功能就少不了。
补充：现在微服务更推荐无状态 + Redis 共享会话，慢慢减少对会话保持的依赖。
4. 故障转移：机器会坏，服务不能停
服务器是会坏的，硬盘、内存、进程，谁都说不准哪天出问题。这事没法避免，能做的是坏了之后反应快不快。
负载均衡器发现某台机器不响应了，会自动把它踢出去，流量全部走剩下的健康机器。整个过程用户基本无感，顶多觉得慢了零点几秒。
放在没有负载均衡的年代，一台机器挂掉就是一次事故。现在，只是流量换了个去处而已。
5. 水平扩展：流量涨了？加机器
流量涨了怎么办？两条路：
- 垂直扩展：换一台更贵、配置更强的大服务器
- 水平扩展：多加几台普通机器
实践里基本都选后者。大家伙再贵也有上限，而且单点风险大；普通机器随便加，加到负载均衡器后面，流量立刻摊薄。
再配上云平台的自动伸缩，高峰自动加机器，低谷自动缩回去，容量跟着流量走，钱也花在刀刃上。
6. DDoS 缓解：坏流量别想过去
负载均衡器是所有流量的必经之路，这个位置天然适合当保安。
DDoS 攻击的套路是用海量垃圾请求把你的服务灌爆。负载均衡器配合限流、清洗中心这些手段，把恶意流量挡在门外，只放合法请求进后端。
当然，超大流量的 DDoS 还得靠云厂商的专业清洗服务，负载均衡是这道防线上离后端最近的一环。
7. 健康检查：故障转移背后的 "体检医生"
前面第 4 条说的 "发现机器挂了就踢出去"，靠的就是健康检查。
原理很简单：负载均衡器定期去戳每台后端机器，戳一下 TCP 端口通不通，或者请求一个接口看返回对不对。 不正常？从转发列表里踢掉。过一会儿恢复了？再加回来。
每台后端的状态它都心里有数，流量永远只发给还活着的机器。有了它，故障转移才不是一句空话。
最后收个尾
7 个场景看着杂，其实能归拢成一句话： 负载均衡 = 分流 + 容灾 + 扩展
- 分流：均匀分发、SSL 卸载、会话保持，让每台机器的算力都花在刀刃上
- 容灾：故障转移、DDoS 缓解、健康检查，出了问题能快速兜底
- 扩展：水平扩展，业务涨了系统跟得上
单体架构时代，机器一挂业务就断。而现在，一台机器挂掉不过是流量重新分配的一个信号。你每天用的那些 "从来没挂过" 的服务，背后大概率都是这套机制在默默干活。
