CDN负载均衡：从全局调度到边缘节点的完整技术解析
你可能从来没有想过这个问题：当你在手机上点开一个视频、刷出一张商品图，或者只是刷新了一下新闻页面，你的请求其实并没有跑到某个遥远的数据中心去排队，而是在离你几十公里、甚至几公里的地方就被“截住”并处理掉了。做出这个判断的，就是CDN负载均衡。它不像缓存命中率那样容易被拿出来炫耀，却决定了整个加速网络能不能在流量洪峰里稳住阵脚——同一时刻可能有上百万个请求涌进来，而系统必须在一瞬间决定每个请求该交给哪台机器。
如果把CDN比作一张覆盖全国的物流网络，缓存策略解决的是“货放在哪”，而负载均衡解决的是“由谁来送、走哪条路”。这两件事缺一不可，但后者往往更考验工程能力，因为它是实时发生的、动态变化的，而且一旦判断失误，用户感知到的就是卡顿、超时甚至白屏。
CDN负载均衡究竟在调度什么
先厘清一个容易混淆的点：CDN负载均衡和普通机房里的负载均衡，虽然名字一样，但处理的问题差别很大。
机房内部的负载均衡，面对的是几台到几百台配置相近的服务器，它们通常在同一个网段、同一个机房，网络延迟差异可以忽略。调度器要做的只是把连接数、请求量均摊出去，别让某台机器过载就行。
而CDN负载均衡面对的是一个跨地域、跨运营商、跨层级的分布式系统。它至少要在三个维度上做判断：
第一是空间维度。哪个节点离用户最近？这个“近”不只是地理距离，还要看运营商线路是否同网、骨干网是否拥堵、跨网结算成本有多高。一个物理距离五十公里的跨网节点，实际延迟可能比一百公里外的同网节点还高。
第二是时间维度。早上八点华东地区在上班，晚上八点全国都在看视频，流量分布本身就是一条剧烈波动的曲线。调度系统必须跟着这条曲线走，而不是按一张静态地图分配流量。
第三是状态维度。某个节点磁盘写满了、某条回源链路断了、某台机器正在做灰度发布，这些实时状态都必须被感知，并且立刻反映到调度决策里。一个健康的调度系统，应该能在节点出问题的几秒内把流量抽走，而不是等用户投诉电话打进来。
从 DNS 到边缘：负载均衡的四层结构
成熟的CDN架构里，负载均衡不是一个软件，而是一整套分层递进的决策链条。理解这个链条，比记住某个算法名字重要得多。
第一层：全局负载均衡
用户发起请求的第一步是域名解析。大多数CDN会在这里做文章：权威DNS服务器根据请求来源的IP地址，返回一个“最合适”的边缘节点IP，而不是所有用户都拿到同一个地址。这套机制通常被称为全局负载均衡或全局服务器负载均衡（GSLB）。
它的决策依据包括IP地理库、运营商归属、各节点的实时健康状态和容量水位。有些大型服务商还会结合探测数据——在全球部署一批探测点，持续测量到各节点的延迟和丢包，用真实的网络质量而不是纸面上的地图来做判断。
这一层的特点是粒度粗、生效慢。DNS有缓存，TTL没到期之前用户不会重新查询，所以调度策略的调整需要时间才能完全铺开。也正因为如此，全局层更适合处理“大方向”的问题，比如某整个区域需要切流。
第二层：区域与节点级调度
DNS只能把用户送到一个大致范围，接下来的精细分配就要靠节点侧的接入层了。常见做法是每个区域部署一组接入机（有人叫它四层调度器、有人叫它边缘LB），它们对外暴露统一的Anycast地址或VIP，对内则把连接转发给真正干活的缓存服务器。
Anycast是这里值得一提的技术：同一个IP地址在全球多个位置被宣告，网络路由协议会自动把用户导向拓扑上最近的那一个。它的好处是无需依赖DNS、收敛速度快；代价是路由路径不完全可控，偶尔会出现“绕远路”的情况，因此很多服务商采用Anycast与DNS调度混用的策略，用前者兜底、用后者优化。像 Cloudflare 这类以Anycast为核心的服务商，把这个思路做到了很大的规模。
第三层：节点内部的请求分发
到了缓存服务器这一层，才真正进入传统意义的负载均衡范畴。这里要区分四层和七层：
四层（传输层）负载均衡工作在TCP/UDP层面，只看源IP、目的IP和端口，转发效率极高，常用方案有LVS、DPDK加速的转发程序等。它的优势是吞吐大、延迟低，缺点是无法根据URL、Header、Cookie来分流。
七层（应用层）负载均衡能看懂HTTP语义，可以按路径、Host、查询参数、设备类型甚至Cookie里的用户标识来决定把请求给谁。Nginx、HAProxy、Envoy 都是这一层的常见选择。七层的灵活性更高，但解析HTTP本身就要消耗CPU，所以通常部署在四层之后，作为“二级分发”。
有意思的是，CDN节点内部的分发逻辑还多了一个约束：缓存一致性。如果同一个URL的请求被随机分散到十台机器上，那这十台机器都会各自回源一次，缓存利用率直接跌到十分之一。所以节点内部往往要用一致性哈希把同一资源的请求尽量收敛到同一台（或少数几台）机器上，同时再叠加一层负载保护，避免热点资源把某台机器打爆。
第四层：回源侧的负载均衡
很多人讨论CDN负载均衡时只想到“用户到边缘”，忽略了“边缘到源站”这一段。事实上，回源链路同样需要调度。当缓存未命中，边缘节点要从源站拉取内容，如果所有边缘节点都往同一台源站服务器上打，源站会在流量高峰被自己的CDN拖垮。
这一层的策略通常包括：多源站轮询或加权分配、按回源路径质量选路、失败自动切换、以及对回源请求做合并（多个边缘节点对同一资源的回源请求可以被中间层收敛成一次）。像 Akamai 这类老牌服务商，在源站保护和中层收敛上的积累比较深。
常见的调度算法与它们的适用场景
静态算法：简单可靠，但不够聪明
轮询与加权轮询是最基础的方案。加权轮询允许给配置更高、带宽更大的机器分配更多流量，实现成本低、行为可预测，至今仍是很多场景的默认选择。但它对实时负载毫无感知——如果某台机器因为磁盘故障变慢，加权轮询依然会把同样多的请求交给它。
IP哈希把同一来源的请求固定到同一台后端，天然实现了会话保持，适合有状态服务。问题是当节点增减时，大量映射关系会被打乱，引起缓存集体失效。
一致性哈希通过哈希环加虚拟节点的方式，把节点变动的影响控制在一小部分键上，是CDN缓存分片的标配。它的关键是虚拟节点数量要足够多，否则流量分布会出现明显倾斜。
动态算法：跟着真实负载走
最少连接数把新请求交给当前活跃连接最少的后端。它对长连接、下载类业务效果明显，因为这类请求的连接数与真实压力高度相关。
最短响应时间依据实时探测或滑动窗口统计的延迟来选机器。它更贴近用户体验，但需要防止“抖动放大”——某台机器偶尔快一点就涌入大量流量，反而把它压垮，所以通常要配合平滑和权重上限。
最少带宽占用适合视频、大文件分发这类带宽敏感的业务，因为对它们来说，连接数多并不一定等于压力大，出口带宽才是瓶颈。
混合与地理调度
真实生产环境几乎不会只用一种算法。更常见的做法是分层组合：全局层用地理与网络质量做主选，节点层用一致性哈希保证缓存效率，再用加权轮询在物理机之间做兜底分摊，同时叠加实时健康检查和容量水位进行动态修正。像 阿里云 CDN、腾讯云 CDN 这类商业服务，都会把多套策略封装成可配置的调度模板，让使用者按业务类型选择。
健康检查与故障转移：真正的分水岭
算法决定了系统在正常情况下表现如何，健康检查决定了它在异常情况下能不能活下来。这两件事的重要性常常被低估。
健康检查一般分两种。被动检查通过真实用户请求的失败率、超时率来判断后端状态，优点是零额外开销、能反映真实体验，缺点是要等到用户请求失败才知道出事了。主动检查由调度器定期向后端发探测请求，可以更早发现问题，但探测频率高了会增加负担，频率低了又会迟钝。
实践中普遍采用两者结合：主动探测负责快速发现，被动统计负责最终确认。关键参数包括判定失败的连续次数、恢复所需的连续成功次数、以及探测超时时间。这里最容易踩的坑是阈值设得太敏感——网络抖动几百毫秒就被判定为故障，流量被抽走又切回来，形成反复震荡，用户体验反而更差。另一个坑是恢复阈值太低，机器刚缓过来就被灌满流量，二次宕机。
故障转移还需要考虑“摘除”和“摘回”的节奏。一个稳妥的做法是摘除要快、恢复要慢，并给恢复中的节点设置渐进式加权的爬坡过程，让它有时间预热缓存、建立连接。对于缓存节点来说，这一点尤其重要：一台空缓存的机器突然接收大量请求，几乎会全部回源，很可能把源站连带打挂。
会话保持、缓存一致性与调度的相互制约
设计CDN负载均衡时，有个绕不开的矛盾：负载均衡追求的是把请求尽量摊平，而缓存和会话追求的是把同一类请求尽量集中。两者方向相反。
摊平的好处是充分利用所有机器的能力，坏处是缓存命中率下降、回源增加。集中的好处是缓存效率高，坏处是热点容易把单机压垮，而且节点故障时影响面更大。解决思路不是二选一，而是分层处理：对静态资源，用一致性哈希集中到固定分片，同时通过多级缓存和热点探测来缓解集中带来的压力；对动态内容，则更偏向实时负载感知的调度，因为它本身没什么缓存可复用。
会话保持也类似。如果业务依赖服务端会话，可以把会话数据外置到集中存储，让调度器可以自由选择后端；如果做不到，就退而求其次，用基于Cookie的粘性调度，但一定要为粘性设置过期时间和降级路径，避免某个后端下线后，绑定在它上面的用户彻底无法访问。
衡量调度效果的关键指标
只看平均值是危险的。CDN负载均衡的效果评估，至少要关注这几组数据：
一是分位延迟，特别是P95和P99。平均值好看但尾部很差，说明调度把一部分用户分到了不合适的节点上，而这部分用户恰恰是最容易流失的。
二是节点间的负载离散度。统计各节点的QPS、带宽、CPU使用率分布，如果离散度大，说明调度策略没有真正生效，可能存在哈希倾斜或探测失准。
三是回源率与回源集中度。前者反映缓存效率，后者反映源站压力分布。回源集中在少数几台源站，是很多线上事故的根源。
四是故障切换时长。从节点异常到流量完全转移，这个时间要能被测量、被报警、被优化。
五是调度决策的可解释性。当用户反馈某个地区访问慢时，你能不能快速回答“这个请求当时为什么被分到了那个节点”？做不到这一点，调优基本靠猜。
落地时的几个实用建议
如果正在设计或优化一套CDN负载均衡方案，下面几条经验值得参考。
别急着上复杂算法。先用加权轮询加健康检查把基础打牢，观察真实数据之后再决定要不要引入延迟感知。复杂度本身也是故障来源。
把调度和容量管理分开看。调度只能解决“流量怎么分”，解决不了“总量不够”的问题。容量水位长期偏高时，加节点比调算法更有效。
给小流量区域留足冗余。大城市节点多、调度灵活，偏远地区可能只有一两个节点，一旦其中一台出问题，没有备选可切。这类区域的容量规划要更保守。
认真对待缓存预热和灰度发布。新节点上线、新版本发布时，让调度器配合做渐进式加流，比事后救火划算得多。
建立压测和故障演练机制。用混沌工程的方式主动杀掉节点、切断链路、注入延迟，验证调度系统是否真的按预期工作。没演练过的故障转移，大概率在真出事时不生效。
最后，把调度日志和访问日志打通。很多疑难问题的答案就藏在“这个请求当时被谁接走了”这一条记录里。像 Nginx 这类基础组件本身提供了丰富的日志能力，关键是要把它和调度层的决策记录关联起来，形成完整的链路视角。
写在最后
CDN负载均衡的本质，是在不确定的网络环境里做持续的最优近似。它没有一劳永逸的配置，也没有放之四海皆准的算法，只有在真实流量中不断观察、修正、验证的过程。当用户点开页面的那一刻，背后是DNS、Anycast、四层转发、七层解析、一致性哈希、健康检查这一连串机制的默契配合——它们中的任何一个环节出问题，用户看到的都只是“这个网站好慢”。把这条链路的每一段都做扎实，才是CDN负载均衡真正的价值所在。
