主题
第 1 章 · 负载均衡是什么
生活类比：你去银行办业务，如果全行只有 1 个柜台，中午高峰必然排长队，柜员累到崩溃，系统一挂全行停业。银行的做法是——开 多个柜台，派一位 大堂经理 在门口引导：「您去 3 号窗」「您去 7 号窗」。这位大堂经理，就是 负载均衡器（Load Balancer，简称 LB）。
1.1 学习目标
读完本章，你应该能：
- 用一句话解释「什么是负载均衡」
- 说出「没有 LB」时的 3 个典型痛点
- 区分「负载均衡」和「反向代理」（它们常在一起，但不是一回事）
- 知道 LB 在架构图中的位置
1.2 从一个真实场景说起
假设你写了一个博客网站，部署在自己电脑上：
用户浏览器 ──HTTP──► 你的电脑:8080 ──► 博客程序刚开始每天 10 个访客，一切正常。某天文章上了热搜，瞬间来了 1 万人同时刷新：
| 现象 | 原因 |
|---|---|
| 网页打不开 / 极慢 | 单台机器 CPU、带宽被打满 |
| 偶尔能打开，过一会又挂了 | 进程 OOM 被系统杀掉 |
| 你重启服务，所有人同时重连 | 又一波流量冲击，再次崩溃 |
这就是经典的 单点故障（Single Point of Failure，SPOF）。
解法：加机器 + 加调度
┌──► 服务器 A（博客实例 1）
用户 ──► 负载均衡器 ─┼──► 服务器 B（博客实例 2）
└──► 服务器 C（博客实例 3）- 流量被 分散 到多台机器 → 每台压力变小
- 某台挂了，LB 自动跳过 → 用户无感知（理想情况）
- 流量涨了，再加机器 就行 → 水平扩展（Scale Out）
负载均衡（Load Balancing） 的本质就是：
在多个能提供相同服务的服务器之间，按某种策略分配 incoming 请求，从而提升 吞吐量、可用性、可扩展性。
1.3 三个核心价值（记住这三个词）
① 高可用（Availability）
生活类比：超市有 5 个收银台，4 号台收银员临时请假，顾客自动被引到其它台——超市不用关门。
- 后端某台宕机，LB 把流量切到健康节点
- 配合健康检查，实现 故障自动转移（Failover）
② 高吞吐（Throughput）
生活类比：双 11 临时加开 20 个收银台，总收银能力线性提升。
- 单机 QPS 有上限（CPU、内存、网卡、磁盘 I/O）
- 多机并行处理，总 QPS ≈ 单机 QPS × 机器数（近似线性）
③ 可扩展（Scalability）
生活类比：客流大了就加柜台，客流小了就减柜台，不用换一家更大的银行。
- 垂直扩展（Scale Up）：换更贵的机器——有天花板，且贵
- 水平扩展（Scale Out）：加更多普通机器——互联网的主流做法，LB 是水平扩展的「入口」
1.4 负载均衡 ≠ 反向代理（易混概念）
很多人把这两个词混用。它们经常 出现在同一个组件里（比如 Nginx），但职责不同：
| 概念 | 做什么 | 生活类比 |
|---|---|---|
| 反向代理 | 代表后端接收请求，客户端不知道真实服务器是谁 | 酒店前台：客人只跟前台说话，不知道保洁在哪层 |
| 负载均衡 | 在多个后端之间 选择一台 来处理这个请求 | 前台决定：这房间的打扫交给 A 保洁还是 B 保洁 |
反向代理关心的是：「用户看到的是我一个入口」
负载均衡关心的是：「这个请求具体交给后面哪台机器」Nginx 做反向代理时，如果 upstream 里写了多台后端，同时 就做了负载均衡。
1.5 负载均衡器放在哪？
常见拓扑（从简单到复杂）：
拓扑 A：LB 紧贴应用（最常见）
Internet ──► [Nginx LB] ──► [App] [App] [App]适合：中小型 Web 服务、API 网关前置。
拓扑 B：多层 LB（大厂常见）
Internet ──► [DNS/GSLB] ──► [机房入口 L4 LB] ──► [L7 网关] ──► [微服务 Pod...]- DNS 层：按地理位置解析到最近机房（广州用户 → 广州机房）
- L4 层：基于 IP/端口快速转发，吞吐极高
- L7 层：能看 HTTP 路径，做路由、鉴权、限流
拓扑 C：客户端 LB（微服务内部）
服务 A ──►（内置 LB 逻辑）──► 服务 B 的实例 1 / 2 / 3没有独立 LB 硬件/进程，调用方 SDK 自己维护服务列表并选择实例（如 gRPC、Spring Cloud LoadBalancer）。
1.6 没有 LB 时，手工分摊行不行？
早期确实有人这么干：
html
<!-- 页面里写死三台服务器，随机跳转 -->
<script>
const servers = ['http://1.2.3.4', 'http://5.6.7.8', 'http://9.10.11.12'];
location.href = servers[Math.floor(Math.random() * 3)];
</script>问题一大堆：
| 问题 | 说明 |
|---|---|
| 无法感知后端健康 | 随机到一台已宕机的机器，用户直接报错 |
| 会话不一致 | 用户两次请求落到不同机器，登录态丢失 |
| 暴露后端地址 | 安全差，且后端 IP 变更要改前端 |
| 策略太粗糙 | 随机不等于公平，更不等于最优 |
所以生产环境 几乎一定有专门的 LB 层。
1.7 一个完整的请求旅程（建立全局感）
以「用户刷微博时间线」为例（简化版）：
1. 用户手机发起 HTTPS 请求
2. DNS 解析 → 返回 LB 的 VIP（虚拟 IP）
3. 请求到达机房入口 LB（可能是 L4）
4. 转发到 L7 网关（APISIX / Nginx）
5. 网关做：TLS 终结、鉴权、限流、路由
6. LB 算法选中一个「时间线服务」实例
7. 时间线服务可能再 RPC 调用「用户服务」「推荐服务」——内部又有 LB
8. 响应原路返回一层 LB 往往不够，现代分布式系统是多级 LB 叠加的。初学先掌握「入口 LB + 算法 + 健康检查」即可，后面章节会展开。
1.8 本章自测
负载均衡解决的核心问题是什么？
→ 单点瓶颈、可用性、水平扩展。「反向代理」和「负载均衡」关系？
→ 常在同一组件；反向代理隐藏后端，负载均衡选择后端。水平扩展 vs 垂直扩展？
→ 加机器 vs 换更强的机器；互联网主流是水平扩展 + LB。为什么不在前端 JS 里随机选服务器？
→ 无法健康检查、会话难保持、暴露后端、策略简陋。
1.9 常见误区
| 误区 | 真相 |
|---|---|
| 「LB 就是把请求平均分」 | 还有很多策略：加权、最少连接、一致性哈希……「平均」只是其中一种 |
| 「上了 LB 就不会挂了」 | LB 自己也可能成为单点，需要主备或集群；后端全挂 LB 也无能为力 |
| 「LB 越贵越好」 | 小项目 Nginx 足够；大促才需要硬件 LB + 多层架构 |
| 「负载均衡只能用在 Web」 | 数据库读副本、Redis Cluster、Kafka 分区、DNS 都是负载均衡思想 |
1.10 一句话总结
负载均衡 = 大堂经理：站在入口，把客流 聪明地 分到多个柜台，让整体 更快、更稳、能扩容。
下一章 → 02 · 架构与分层：搞懂 L4 和 L7 到底差在哪——这是面试第一题。