本篇要回答的问题：服务端为什么需要负载均衡？流量调度有哪几种典型手段（DNS / 网络层 / 应用层），各自的取舍是什么？负载均衡除了均衡流量，还顺带解决了什么问题？
上一讲说服务端比桌面多出两类基础软件：负载均衡与存储。本讲专攻第一类——流量调度与负载均衡，回答 34 讲留下的"为什么需要负载均衡"。
先厘清几个度量概念
| 概念 | 含义 |
|---|---|
| 连接数（并发数） | 同时在服务中的请求数（已发 Request 但未收完 Response） |
| IOPS | 平均每秒完成的请求（一问一答）数量，判断做事效率 |
| 入向流量 | ≈ IOPS × 请求包平均大小 |
| 出向流量 | ≈ IOPS × 应答包平均大小 |
流量调度：把海量客户并发的请求包，按特定策略分派到不同服务端实例的过程。
DNS 流量调度（最基础）
一个域名 DNS 解析到多个 IP，每个 IP 对应一个实例。没用常规负载均衡软件也完成了调度。
两个不足：
| 问题 | 原因 |
|---|---|
| 升级不便 | 要升级 IP1 须先从解析中摘除，但 DNS 有层层缓存，就算 TTL 写 15 分钟，一天后仍有零星请求打到 IP1。单实例升级周期极长（1 天/实例 × 10 实例 = 10 天，太夸张） |
| 调度不均衡 | DNS 可轮换返回 IP 顺序，但"域名解析均衡 ≠ 真正流量均衡"：客户端有缓存、DNS 层层缓存，到 DNS 服务器的比例已很少，结果不可控 |
网络层负载均衡（以 LVS 为例）
在网络层（IP 层）做负载均衡，代表是章文嵩博士的 LVS（Linux Virtual Server）。三种调度模式：
| 模式 | 原理 | 性能 |
|---|---|---|
| VS/NAT | 网络地址转换，请求和响应都经调度器中转 | 最差 |
| VS/TUN | IP 隧道把请求转发给真实服务器，响应由 RS 直接返回客户 | 较好（调度器只处理请求） |
| VS/DR | 改写请求报文的 MAC 地址转发，响应由 RS 直接返回客户 | 最好（比 TUN 少了 IP 隧道开销） |
VS/DR 三步（CIP/CMAC 为客户端 IP/MAC，VIP 为虚拟 IP）：
| 步 | 动作 |
|---|---|
| 1 | 客户端发请求：源 IP=CIP、目标 IP=VIP；源 MAC=CMAC、目标 MAC=DMAC |
| 2 | 到达 LVS 调度器（Director Server）：保持源/目标 IP 不变，仅改目标 MAC 为 RMAC，转发给真实服务器 RS |
| 3 | RS 处理后直接响应客户端 |
关键技巧：VIP 同时绑定在调度器和所有 RS 上（故名"虚拟 IP"）。难点是 ARP——查询 VIP 对应 MAC 必须得到调度器；做法是在 RS 上把 VIP 绑到
lo接口并抑制 ARP，避免 IP 冲突。
特点与缺点：
| 维度 | 说明 |
|---|---|
| 优点 | 通用性强、性能优势高（底层做） |
| 缺点 | 某 RS 挂掉而调度器尚未感知时，转发到它的请求会失败，只能靠客户端重试 |
应用层负载均衡（应用网关）
要避免上面那种请求失败，答案是服务端重试——靠应用层负载均衡（应用网关）。当前应用网关绝大多数是 HTTP 应用网关（Nginx、Apache 等），因懂应用层协议细节而能力强大。
流程：网关收到 HTTP Request → 按调度算法转发给某 RS → 收到 Response → 转发给客户端。重试很好做：发现某 RS 挂了，把同一请求重发给其他 RS。
重要细节：为支持重试，HTTP 请求需被保存。不保存也能重试，但只能覆盖"请求一个字节都没发出去"的场景；断电/崩溃时有大量进行中的请求不满足该前提。小请求直接存内存即可；文件上传型请求含文件内容，可能要靠临时文件等手段保存。
优雅升级
负载均衡顺带让业务服务器升级变方便。两种前端的升级步骤对比：
| 前端类型 | 升级步骤 |
|---|---|
| LVS（网络层） | ① 通知调度器下线该 RS → ② 调度器从 RS 集合移除、不再调度新流量 → ③ 通知 RS 退出 → ④ RS 处理完在途请求后主动退出 → ⑤ 更新到新版并重启 → ⑥ 重新加回 RS 集合 |
| HTTP 应用网关 | ① 通知 RS 退出 → ② RS 进入退出态：新请求直接拒绝（返回特殊 Status Code），处理完在途请求后主动退出 → ③ 更新到新版并重启 |
HTTP 应用网关因支持重试，升级过程明显更简单（拒绝的新请求会被网关重试到别的实例）。
总结
本讲从流量调度的度量概念讲起，给出三档调度手段：DNS（最基础，但升级不便、调度粗糙）、网络层 LVS（通用高性能，但 RS 故障窗口内请求会失败、靠客户端重试）、应用层 HTTP 网关（懂协议、能服务端重试、升级最简单）。负载均衡的最大价值是让多业务服务器压力均衡，并顺带使优雅升级成为可能。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 流量调度 | 把海量并发请求按策略分派到不同实例 |
| IOPS | 每秒完成的一问一答数量，衡量效率 |
| DNS 调度 | 一域名解析到多 IP，简单但升级不便、不均衡 |
| LVS / VS/DR | 网络层负载均衡；DR 改 MAC 转发、响应直返，性能最好，VIP 多机绑定+ARP 抑制 |
| HTTP 应用网关 | 应用层负载均衡，懂 HTTP，可服务端重试、升级简单 |
| 优雅升级 | 借负载均衡先下线/拒新请求、排空在途请求再升级 |
一句话速记
流量调度三档递进：DNS 最糙、LVS（VS/DR 改 MAC 直返）最快但故障窗口靠客户端重试、HTTP 网关懂协议能服务端重试因而升级最优雅——负载均衡的价值不止均压，更让优雅升级成为可能。
几条值得记住的判断
- DNS 缓存是天敌：层层缓存让 DNS 调度既难升级又难均衡。
- 重试位置决定体验：网络层靠客户端重试，应用层能服务端重试、对用户更友好。
- 重试需保存请求：尤其文件上传型请求，要靠临时文件保存以支持崩溃后重试。
思考题
文中留两问：① 为什么说负载均衡软件的抗压能力往往比业务服务器强很多（提示：负载均衡实例数/业务实例数 ≪ 1，且 DNS 不均衡导致不同 LB 实例压力也不均）？② 为什么需要负载均衡——你能从"均压 + 优雅升级"两个角度把它讲清楚吗？
