负载均衡与流量分发

原始素材：7-基础设施与运维/7.06-load-balancing-gateway.md

当单台服务器扛不住时,如何把流量"聪明地"分配到多个服务器实例? 负载均衡是现代分布式系统的"分发员"。本文通过真实案例(奶茶店收银、快递分拣、交通指挥)深入理解负载均衡的设计哲学和工程实践。

1. 为什么要"负载均衡"?

1.1 从一个真实案例说起:某网站的架构演进

某创业公司在用户量快速增长时遇到了严重的性能问题:

场景还原:

 阶段一:单台服务器
用户 → 服务器(1核2G)
       ↓
  日活1000 → 活跃时间:1000人同时访问
       ↓
问题:CPU 100%,响应慢,经常宕机

⚠️ 单台服务器的致命问题

• 性能瓶颈 : CPU 100%,响应时间> 5秒
• 单点故障 : 服务器挂了,整个网站不可用
• 扩展困难 : 只能垂直升级(加CPU、内存),贵且有限

改进后的架构(引入负载均衡):

 阶段二:多台服务器 + 负载均衡
用户 → 负载均衡器(Nginx)
       ↓
     ├→ 服务器1 (1核2G)
     ├→ 服务器2 (1核2G)
     └→ 服务器3 (1核2G)

✨ 改进后的效果

• 性能提升 : 3台服务器并行处理,响应时间< 1秒
• 高可用 : 1台服务器挂了,其他服务器继续服务
• 水平扩展 : 需要更多性能?加服务器就行

1.2 负载均衡的生活化比喻

奶茶店收银台

想象你开了一家网红奶茶店:

• 1个收银台 : 顾客排队,后面的人等不及,差评
• 3个收银台 : 员工分配顾客到不同收银台,效率提升3倍

负载均衡就是"收银台分配员" :

• 用户(顾客) → 请求服务
• 负载均衡器(分配员) → 把请求分配到不同服务器
• 服务器(收银台) → 处理请求

从四层到七层，从硬件到软件的演进：

传统（单点）                          负载均衡（分布式）
┌──────────────┐                   ┌──────────────┐
│  Web Server  │  ──→   ⚖️ L4 LB  →  S1 / S2 / S3
│  负载: 95% 🔥│                   │  负载分散      │
└──────────────┘                   └──────────────┘

以「四层负载均衡（L4 LB）」为例：

工作原理：基于传输层信息（IP 地址 + 端口）进行流量分发。不关心应用层内容，只做"快递分拣"，因此性能极高。

四种 LB 类型性能对比：

2. 什么是负载均衡?

2.1 四层负载均衡(L4):只看门牌号

工作在传输层(TCP/UDP) ,就像快递小哥只看你家的门牌号(IP地址+端口号) ,不关心你家是做什么。

特点:

• 速度超快 : 只做简单的地址转发,不解析数据包内容
• 适用场景 : 数据库连接、Redis缓存、长连接游戏服务器
• 代表产品 : LVS(Linux Virtual Server)、AWS NLB、Azure Load Balancer

工作原理

客户端请求 → L4负载均衡器 → 后端服务器
              ↓
         只看IP + Port
              ↓
         快速转发(不解包内容)

2.2 七层负载均衡(L7):检查包裹内容

工作在应用层(HTTP/HTTPS) ,就像快递小哥不仅看门牌号,还会打开包裹检查内容 ,根据内容决定怎么送。

特点:

• 智能路由 : 可以根据URL路径、HTTP头、Cookie等做精细化路由
• 高级功能 : SSL卸载、内容缓存、压缩、安全WAF
• 适用场景 : Web应用、API网关、微服务架构
• 代表产品 : Nginx、HAProxy、AWS ALB、Envoy

工作原理

客户端请求 → L7负载均衡器 → 解析HTTP内容
              ↓
         检查URL、Header、Cookie
              ↓
         智能路由到特定服务器

2.3 L4 vs L7 对比一览

3. 核心问题一:如何避免"坏掉"的服务器继续接客?

3.1 健康检查:别让"生病"的服务器拖累系统

想象一下,你的某个收银台突然坏了,但分配员不知道,还在源源不断地把顾客分过去。结果队伍越来越长,顾客怨声载道。

健康检查(Health Check)就是防止这种情况发生的"哨兵" 。它定期"体检"每台服务器,发现"生病"的立即从队列中移除,等"康复"了再请回来。

3.2 主动健康检查 vs 被动健康检查

主动健康检查(Active Health Check) : 负载均衡器主动"敲门"问服务器"你还在吗?"

• 定期发送探测请求(如 HTTP /health、TCP ping)
• 响应超时或返回错误码则认为不健康
• 优点 : 检测结果准确可靠
• 缺点 : 产生额外的探测流量

被动健康检查(Passive Health Check) : 负载均衡器"观察"真实业务流量的响应情况

• 统计实际请求的响应时间、错误率
• 连续多次失败则认为不健康
• 优点 : 不产生额外流量
• 缺点 : 需要足够的流量样本才能判定

某团队将健康检查的响应时间阈值设为100ms,而他们的应用平均响应时间在80-120ms之间波动。结果是服务器频繁被标记为"不健康",导致流量在健康和不健康之间反复横跳,系统整体可用率反而下降。

正确的做法 : 阈值应该设置为P99响应时间的2-3倍 ,给正常波动留出足够的缓冲空间。

4. 核心问题二:如何保证"老顾客"一直找同一个"收银员"?

4.1 会话保持:让"老顾客"一直找同一个"收银员"

想象你是奶茶店的常客,每次来都由同一个店员接待。她知道你的口味偏好(半糖、去冰),服务起来又快又贴心。但如果每次来都换一个新人,你得一遍遍重复同样的要求,效率大打折扣。

会话保持(Session Persistence/Sticky Session) 就是解决这个问题的方法:确保同一个用户的请求,始终被路由到同一台后端服务器。

会话保持机制

应用场景：购物车 登录状态 实时通信

以「🍪 Cookie 插入」为例的请求流程：

用户 A/B/C → ⚖️ 负载均衡器 → 会话映射表 → 后端服务器
                  │                │
                  │   Cookie 插入   │ sess_abc123 → Server 1 (10.0.1.10) ✓
                  │                │ sess_def456 → Server 2 (10.0.1.11) ✓
                  │                │ sess_ghi789 → Server 1 (10.0.1.10) ✓
                  │                │
                  ↑ SERVERID=srv001; Path=/; HttpOnly

三种会话保持机制对比：

4.2 三种会话保持机制对比

• Cookie插入 : 优先推荐,兼容性好
• IP哈希 : 只用于WebSocket等特殊场景
• 粘性会话表 : 配合Cookie,提供故障转移能力

5. 核心问题三:如何实现零停机部署?

5.1 蓝绿部署:"一键切换"的零停机发布

核心思想 : 同时维护两套完全相同的生产环境(蓝环境和绿环境),但只有一个环境对外提供服务。

零停机发布的经典策略，两套环境瞬间切换：

🔵 蓝环境（v1.0.0，100% 流量）  ──切换到绿环境──→  🟢 绿环境（v1.1.0，0% 流量）

用户流量 → ⚖️ 负载均衡器（当前指向 🔵 蓝环境）
              ├─ 蓝环境：100% 流量（生产）
              └─ 绿环境：0% 流量（待命）

蓝绿部署流程：

蓝绿部署优缺点

✅优点

• 零停机时间：流量切换在毫秒级完成，用户无感知
• 快速回滚：发现问题可立即切回原环境，风险可控
• 完整的预发布测试：新环境可完整测试后再接管流量
• 数据一致性：无需处理新旧版本同时运行时的兼容问题

❌缺点

• 资源成本高：需要同时维护两套完整环境，服务器成本翻倍
• 数据库兼容性挑战：如果涉及数据库Schema变更，需要特别处理兼容性
• 预热问题：新环境启动后可能需要时间预热缓存、连接池等
• 不适合有状态服务：对于长连接、会话保持要求高的场景处理复杂

工作流程:

1. 初始状态 : 蓝环境运行v1.0(生产),绿环境待命。
2. 部署新版本 : 在绿环境部署v1.1,进行内部冒烟测试。
3. 切换流量 : 将负载均衡器指向绿环境,流量瞬间切换到v1.1。
4. 监控观察 : 观察绿环境运行状态,确认无异常。
5. 保留旧版本 : 蓝环境保持v1.0一段时间(如24小时),作为快速回滚的保险。

✨ 优缺点分析

5.2 金丝雀发布:"小步快跑"的灰度策略

金丝雀发布得名于历史上的"煤矿金丝雀"——矿工带着金丝雀下井,如果金丝雀出现异常,说明有毒气体泄漏,矿工立即撤离。在软件发布中,金丝雀发布就是先让一小部分用户试用新版本,观察没有问题后再逐步扩大范围。

灰度发布策略，小流量先行验证新版本：

稳定版 v1.0.0 (90%)  │  金丝雀 v1.1.0 (10%)
                     │
  用户请求 → ⚖️ 负载均衡器（Canary: 10%）→ 后端服务
                     │
  放量节奏：1% → 5% → 10% → 25% → 50% → 100%

金丝雀发布最佳实践：

核心思想:

1. 小流量先行 : 先将1%的流量导入新版本服务器。
2. 观察指标 : 持续监控错误率、延迟、业务关键指标。
3. 逐步放量 : 如果一切正常,逐步将比例提升到5%、10%、25%、50%、100%。
4. 快速回滚 : 一旦发现异常,立即将所有流量切回旧版本。

6. 核心问题四:如何让系统自己"呼吸"?

6.1 自动扩缩容:让系统像餐厅一样"灵活排班"

想象你开了一家餐厅:

• 午餐高峰期 : 需要10个服务员,但下午3点闲时只需要2个
• 如果一直维持10个**: 人工成本爆炸
• 如果一直只有2个: 高峰期顾客等不及,全跑了

自动扩缩容(Auto Scaling) 就是让系统像餐厅一样"灵活排班"——忙的时候自动加服务器,闲的时候自动减服务器。

基于 CPU、内存、QPS 的智能弹性伸缩：

当前监控（实时）：

扩缩容历史（最近 5 次）：

最佳实践：

6.2 扩容指标的选择

自动扩缩容的核心是回答一个问题:** 什么时候该加机器?什么时候该减机器?

常见的决策指标:

坑1:扩容反应太慢,流量洪峰已经把系统打挂了

某电商大促期间,设置CPU > 80%触发扩容,但监控采集有1分钟延迟,新实例启动需要3分钟。结果流量来得太快,扩容还没完成,服务器已经被打挂。

解决方案:

• 提前扩容 : 基于历史数据预测流量高峰,提前30分钟开始扩容
• 多级阈值 : 设置60%预警(开始预热新实例)、70%正式扩容、80%紧急扩容
• 快速扩容 : 使用容器化部署,新实例30秒内启动(相比虚拟机3-5分钟)

坑2:扩容太激进,成本爆炸

某创业公司设置了激进的自动扩容策略:CPU > 50%就扩容。结果一个正常的业务波动就触发了扩容,服务器数量从5台膨胀到30台,月底云账单吓哭了CTO。

解决方案:

• 设置扩容冷却时间 : 一次扩容后,至少等待5分钟才能再次扩容
• 设置最大实例数 : max = 当前实例数 × 2,防止无限膨胀
• 区分突刺和趋势 : 只有连续3个周期都超过阈值才扩容,避免单点突刺触发

坑3:缩容太快,刚扩容的机器马上就缩了

某团队设置了CPU < 30%缩容。扩容后流量还在消化,CPU短暂回落到25%,触发了缩容。刚缩完CPU又飙到80%,又触发扩容——系统在"扩容-缩容-扩容"中疯狂震荡。

解决方案:

• 缩容更保守 : 扩容阈值70%,缩容阈值25%,中间有足够的缓冲带
• 缩容冷却时间更长 : 扩容后至少等待10分钟才能缩容
• 渐进式缩容 : 一次只缩1台,观察后再决定要不要继续缩

7. 实战:如何选择负载均衡器?

7.1 主流负载均衡器对比

决策树:

 选择负载均衡器:
│
├─ 只需要基础的四层负载均衡?
│  ├─ 是 → LVS(开源免费)或 云厂商NLB
│  └─ 否 → 继续
│
├─ 需要服务网格、多云部署?
│  ├─ 是 → Envoy
│  └─ 否 → 继续
│
├─ 需要极其复杂的配置和插件?
│  ├─ 是 → HAProxy
│  └─ 否 → 继续
│
├─ 需要高性能+简单配置?
│  ├─ 是 → Nginx(首选)
│  └─ 继续
│
├─ 想要托管运维?
│  ├─ 是 → 云厂商负载均衡(AWS ALB、阿里SLB)
│  └─ Nginx自建

8. 总结:负载均衡的核心思维

8.1 核心原则回顾

8.2 设计检查清单

在引入负载均衡前,问自己以下问题:

• 是否真的需要负载均衡?(单机性能是否真的不够)
• 选择L4还是L7?(根据业务场景)
• 如何处理会话保持?(Cookie、IP哈希、会话表)
• 如何实现健康检查?(主动、被动、阈值设置)
• 如何实现零停机?(蓝绿部署、金丝雀)
• 如何实现弹性?(扩缩指标、冷却时间、最大实例数)

9. 名词速查表