负载均衡与CDN：核心区别与实战优化

1. 流量分发的两大支柱：负载均衡与CDN的本质区别

第一次接触这两个概念时，我也曾困惑：为什么公司既用了阿里云的SLB又上了CDN服务？直到有次大促活动，亲眼看到SLB把服务器流量从80%降到30%，而CDN节点缓存命中率飙升到92%，才真正理解它们的协作关系。

负载均衡（Load Balancer）本质上是"交通警察"，工作在传输层（L4）或应用层（L7），核心任务是将客户端请求智能分配到后端服务器集群。就像高峰期交警在十字路口分流车辆，SLB通过轮询、最小连接数等算法，确保没有单台服务器过载。而CDN（Content Delivery Network）更像是"快递分仓"，通过全球分布的边缘节点缓存静态资源，使用户就近获取内容。当北京用户访问杭州站点的图片时，CDN会从北京的POP节点直接返回缓存，不再跨越半个中国去源站拉取。

关键认知：负载均衡解决的是"请求往哪台服务器去"的问题，CDN解决的是"内容从哪里来"的问题。两者经常配合使用——CDN处理静态资源，回源时通过负载均衡访问服务器集群。

2. 负载均衡的算法江湖与实战配置

2.1 常见算法场景选择

去年优化电商系统时，我们对比测试了三种算法：

• 轮询（Round Robin）：像发牌一样轮流分配，适合服务器配置均匀的场景。但实际测试发现，当某台服务器处理耗时较长时，请求会堆积形成"雪球效应"。
• 加权轮询：给性能强的服务器更高权重。我们给32核服务器权重设为16核的2倍，吞吐量提升了37%。但要注意动态调整——有次某台机器CPU风扇故障导致性能下降，却还在接收大量请求，反而拖累整体。
• 最小连接数：当前最忙的服务器优先处理新请求。实测在高并发下最稳定，但需要负载均衡器实时监控各服务器状态，对性能有损耗。

2.2 Nginx配置中的深坑实录

在阿里云SLB后端挂载Nginx时，遇到过经典的X-Forwarded-For丢失问题。现象是：所有访问日志显示的客户端IP都是SLB的内网IP。解决方案是在Nginx配置中添加：

nginx复制set_real_ip_from 100.104.0.0/16; # 阿里云SLB网段
real_ip_header X-Forwarded-For;
real_ip_recursive on;

这个案例教会我们：当流量经过多层代理时，原始客户端IP会像洋葱一样被层层包裹。X-Forwarded-For头可能包含"IP1, IP2, IP3"这样的链式记录，而real_ip_recursive on会让Nginx从右向左找到第一个非信任IP。

3. CDN的缓存魔法与动态加速

3.1 静态资源缓存策略

给官网配置CDN时，我们通过Cache-Control头实现精细控制：

json复制{
  "缓存策略": {
    "图片/css/js": "max-age=2592000", // 30天
    "HTML文档": "max-age=300", // 5分钟
    "API响应": "no-cache" 
  }
}

但有一次更新logo后，发现部分地区仍然显示旧版。这是因为CDN边缘节点存在"缓存漂移"——不同节点的缓存过期时间存在微小差异。最终我们通过"版本号后缀"解决：logo-v2.png强制客户端获取新资源。

3.2 动态内容加速的误区

早期我们错误地将所有/api/路径排除在CDN加速之外，导致美洲用户访问延迟高达800ms。后来采用"动态加速"方案：

1. 建立专用回源通道
2. 启用TCP优化
3. 开启Brotli压缩

这使API平均响应时间降至200ms以下。关键认知：CDN不只是缓存工具，其智能路由能力同样能加速动态内容。

4. 混合架构下的排错指南

4.1 问题定位流程图

当用户报告"访问慢"时，我们的排查路径如下：

mermaid复制graph TD
    A[用户访问慢] --> B{资源类型?}
    B -->|静态| C[检查CDN缓存命中率]
    B -->|动态| D[检查SLB后端服务器负载]
    C --> E[命中率<90%?]
    E -->|是| F[检查Cache-Control头]
    E -->|否| G[检查边缘节点位置]
    D --> H[是否有服务器过载?]
    H -->|是| I[调整负载均衡算法]

4.2 典型故障案例

案例1：某次促销活动期间，监控显示SLB将70%流量分到服务器A。检查发现：

1. 服务器B的health check接口返回延迟从200ms升至2s
2. SLB的健康检查超时设置是1s
3. 结果SLB认为服务器B不健康，停止分发流量

解决方案：调整健康检查超时为3s，并优化服务器B的检查接口性能。

案例2：用户反映部分地区无法加载CSS文件。排查过程：

1. 通过CDN厂商的调试头X-Cache: MISS确认未命中缓存
2. 检查回源日志，发现源站返回500错误
3. 最终发现是源站Nginx的client_max_body_size限制导致

5. 成本优化与性能平衡术

5.1 负载均衡的成本陷阱

使用云服务商的SLB时，这些隐藏成本容易忽视：

• 按流量计费时，跨可用区传输会产生额外费用
• HTTPS请求的计算成本是HTTP的3-5倍
• 长连接保持时间设置过长会导致连接数虚高

我们的优化方案：

• 同地域部署尽量选择单可用区
• 对内部系统使用自签名证书+HTTP
• 将keepalive_timeout从65s调整为30s

5.2 CDN的高级玩法

通过边缘计算实现AB测试：

javascript复制// 在CDN边缘节点运行
addEventListener('fetch', event => {
  const cookie = event.request.headers.get('cookie')
  const variant = cookie.includes('experiment=blue') ? 'blue' : 'red'
  event.respondWith(fetch(`/assets/${variant}/theme.css`))
})

这种方案比传统服务器端分流的延迟降低80%，同时节省了源站计算资源。