前端负载均衡

一句话

你以为前端负载均衡（load balancing）是「在机房前面摆一台设备」，其实它是一条三层接力、且没有任何一层能独当一面的链条：DNS 只能做粗粒度、反应迟缓的地理分流；路由（任播 anycast）只能按网络拓扑意义上的「近」投递；真正把一条连接钉在一台后端上的是 VIP 层的网络负载均衡器——它的核心手艺是用无共享状态的一致性哈希代替连接表，并让回程流量绕开自己。

Glossary · 术语表

坐标

本章属全书第 III 部分「实践」里的负载均衡二连：Ch19 管流量进机房之前（DNS、任播、VIP），Ch20 管进了机房之后（子集化、加权轮询、跛脚鸭）；再往下是 Ch21「处理过载」——因为分派做得再好，也总有分不掉的那一刻。对应现实里的一整类系统：CDN 与全球接入层、云厂商的全球负载均衡器、自建机房前那一排四层 LB。

这章要解决什么

本章开篇立的论是「光有算力不解决问题」：机房再多、机器再强，也不等于用户被服务好。原因有三层。

• 容量不在一个地方。服务分布在全球若干站点，A 站点的富余对 B 站点的过载毫无帮助——除非流量能被引导过去。
• 距离直接换成延迟。量级：跨大西洋一个往返约 70–90 毫秒，跨太平洋约 100–160 毫秒，而一次 TLS 1.2 完整握手要 2 个往返。接入点选错一次，等于在页面打开之前就白送用户一两百毫秒。
• 请求不等价。一次命中缓存的静态请求和一次要查后端的搜索请求，成本可能差一两个数量级——「每秒请求数」这个单位本身就不足以描述负载。

不解决会怎样？两种病症：冷热不均——某站点排队到 p99 飙升、另一站点 CPU 三成闲着；以及更难受的撤不下来——站点要维护或已出故障，却没有任何旋钮能在几分钟内把流量挪走，因为决定权散落在全世界的 DNS 缓存里。

核心内容，讲透

一、DNS 分派：能用，但它是「分布」不是「均衡」

做法最朴素：权威 DNS 按查询来源返回不同地址，或一个域名挂多条 A 记录做轮询。便宜、通用、不占数据面，但本章把它的三道硬墙摆得很清楚。

第一，你看不见用户，只看见解析器。权威服务器几乎从不与用户直接对话，中间隔着递归解析器。你只知道解析器的地址，既不知道它背后有多少用户，也不知道那些用户离它多远。补丁是 EDNS0 的客户端子网扩展（后标准化为 RFC 7871，2016）：解析器在查询里带上用户 IP 的一段前缀（如 /24），权威服务器就能按用户而非按解析器决策。代价有三：只有实现了它的解析器才有效；答案从「一份」变成「按子网各一份」，打碎解析器的缓存；还交出了用户地址的一部分，是公认的隐私折扣。

第二，你控制不了缓存。TTL 只是建议——解析器会缓存，有的会把过短的 TTL 抬上去，客户端和应用层还各有一层缓存。所以想把一个站点摘出去，你等的是最长的那份缓存过期，而不是你设的 TTL。压到几十秒能改善反应速度，代价是每次过期多一次解析往返（直接加进用户感知的首字节时间），以及成比例增长的查询量。

第三，你控制不了客户端怎么挑。返回多条记录时，客户端通常用第一条，也可能自己排序或并发尝试；而 DNS 响应本身有尺寸约束（传统 UDP 回包 512 字节，要靠 EDNS0 才放得开），能塞的地址数有限。

结论很克制：DNS 只适合粗粒度的地理分流，别指望它做真正的均衡——它既感知不到实时负载，也收不回已经发出去的答案。

二、任播：让路由替你选站点

把同一个 VIP 从多个站点通过 BGP 同时宣告出去，互联网的路由自己把用户的包送到其中一个。好处立竿见影：不必按地域发不同的 DNS 答案，不受缓存拖累；站点故障时只要撤掉宣告，路由在秒到分钟级自己收敛到别处——这是这一层最实用的应急开关。

权衡在哪？BGP 眼里的「近」是路径属性上的近（跳数、策略偏好），不是延迟上的近，你可能被送去一个绕路的站点。更硬的一条是连接稳定性：若路由在一条 TCP 连接活着的时候变化，后续包落到另一个站点，那里没有这条连接的任何状态，用户拿到的是重置。实践上靠两件事缓解——站点内多台负载均衡器做成无状态、同构、算得一致（见下一节），以及在接入层放全局代理：任一站点都能把请求转给该去的后端，「换了站点」于是不再必然等于「连接作废」。

三、VIP 层：一条连接必须永远落在同一台后端

VIP 不属于任何一张网卡，而由一组网络负载均衡器共同宣告；上游路由器用 ECMP 把包撒到其中任意一台，每台再决定这个包交给哪个后端。难点只有一个，但很硬：TCP 是有状态的，同一条连接的每个包都必须交给同一个后端，否则连接立即作废。两种做法：

• 连接跟踪表：以五元组为键记住「这条流给了谁」。直观，但它是状态——内存随并发连接数长（几百万条流仅这张表就是 GB 量级），而且这台 LB 一重启、或 ECMP 因增删设备把同一条流撒到另一台 LB，表就对不上了。
• 一致性哈希：直接从五元组算出后端，不存任何状态。于是同组里每台 LB 对同一条流算出同样的答案，ECMP 怎么撒都不影响，LB 重启也不丢决定。

Google 的 Maglev 把两者叠加：一致性哈希作地基（无状态、随时可重算），连接跟踪表只作上层优化——在后端集合真的变化时保护已建立的连接。

为什么非得是一致性哈希，普通的 hash mod N 不行？算一下就清楚：后端从 10 台加到 11 台，取模的结果几乎全变——只有约 1/11 ≈ 9% 的流碰巧落回原处，约 91% 的连接被打断。一致性哈希把这个数字倒过来：只有约 1/11 的流需要搬家，其余原地不动。代价是它只保证「谁都算得一致」，不保证「分得均匀」——偏斜要靠虚拟节点（或 Maglev 那种预生成的查找表）压下去。

四、怎么把包递给后端：NAT 还是封装 + DSR

选好后端还得把包送过去。两条路，代价完全不同。

NAT：改写包的目的地址。代价是回程必须再绕回 LB（否则客户端看到的源地址不对），于是 LB 同时背上行和下行。而下行远大于上行——请求几百字节、响应几十 KB 到几 MB，量级差常在 10 倍以上——LB 就成了带宽瓶颈，还得为每条流保状态。

封装 + DSR：把原包整包裹进一个新 IP 包（GRE 或 IPIP），外层目的地址是后端；后端解封装后看到的仍是原始目的地址（VIP 配在它的环回接口上），处理完直接把响应发回客户端，不经过 LB。于是 LB 只处理上行，容量按「上行包速率」算而不是「总带宽」算，横向扩起来便宜得多。

代价要写清：外层头吃掉 MTU（IPIP 20 字节、GRE 24 字节起），路径 MTU 发现一旦被中间设备掐断，症状就是「小请求好、大请求挂」这类最难查的故障；后端必须配好 VIP 且不能应答它的 ARP；LB 看不到响应，观测得另建一套。

关键权衡与选型

表 1 · 三层分派手段：各自能做什么、代价是什么

表 2 · 一条流怎么钉在一台后端上：连接表 vs 一致性哈希

表 3 · 包怎么递给后端：NAT vs 封装 + DSR

一句话：三层不是替代关系，是叠加关系——每往下一层，粒度更细、反应更快，但看见的范围更小。只允许留一层就留 VIP 层：它是唯一真正知道后端还活着没有的一层。

为什么重要 / 落到真实系统

这一章的价值，在于它把「负载均衡」这一个词拆成了三个问题：用户引到哪个大区（DNS）、包送进哪个站点（路由）、连接钉在哪台机器（VIP 层）。三者由完全不同的组件回答，混着谈就会得出「把 TTL 调小就能做负载均衡」这类错结论。面试里最常追问的也正是这三点：DNS 为什么做不了负载均衡、一致性哈希凭什么比取模好、DSR 为什么能把 LB 的容量单位从带宽换成包速率。

易错点与争议

• 把 DNS 当负载均衡器用。压低 TTL 不等于拿到控制权，缓存不在你手里；真要撤流量，撤 BGP 宣告或改后端集合才是可靠旋钮。
• 以为任播天然就近。BGP 的「近」是跳数与策略意义上的近，被绕到另一个大洲并不罕见，任播也需要按真实延迟校正。
• 以为一致性哈希顺带解决了均衡。它解决「一致」，不解决「均匀」；不配虚拟节点或查找表，后端负载偏斜十几个百分点是常态。
• 忘了 MTU。封装类方案最经典的事故形态是「握手成功、传大包卡死」——上线前必须验证路径 MTU 发现是通的。
• 时代局限。本章成书于 2016 年，讲的是四层这一段。此后主流做法把更多智能上移到七层全球代理，eBPF / XDP 又把这套转发平面从专用设备搬进了普通服务器内核（Katran、Cilium）。但「DNS 粗、路由中、VIP 细」这个分层结论没被推翻。
• 一个诚实的反方。对不是全球规模的服务，这一整套是过度设计——一对现成的四层 LB 加一条按地域的 DNS 记录就能顶到相当大的规模；把任播和自研转发面搬进来，先到账的往往是复杂度。

要点