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

---

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

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

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

**场景还原:**

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

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

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

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

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

::: tip ✨ 改进后的效果

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

### 1.2 负载均衡的生活化比喻

**奶茶店收银台**

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

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

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

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

<LoadBalancerTypesDemo />

---

## 2. 什么是负载均衡?

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

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

**特点:**

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

::: details 工作原理

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

:::

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

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

**特点:**

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

::: details 工作原理

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

:::

### 2.3 L4 vs L7 对比一览

| 维度           | 四层负载均衡(L4)     | 七层负载均衡(L7)          |
| :------------- | :------------------- | :------------------------ |
| **工作层级**   | 传输层(TCP/UDP)      | 应用层(HTTP/HTTPS)        |
| **决策依据**   | IP地址 + 端口号      | URL、Header、Cookie、Body |
| **处理速度**   | 极快(内核态处理)     | 较快(用户态解析)          |
| **功能丰富度** | 基础转发             | SSL卸载、缓存、压缩、WAF  |
| **典型场景**   | 数据库、游戏、长连接 | Web应用、API网关、微服务  |
| **代表产品**   | LVS、AWS NLB         | Nginx、HAProxy、AWS ALB   |

---

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

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

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

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

<!-- <HealthCheckDemo /> -->

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

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

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

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

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

::: details 阈值设定表
| 指标 | 健康阈值 | 不健康阈值 | 说明 |
|:---|:---|:---|:---|
| **HTTP状态码** | 200-399 | 400+或超时 | 4xx/5xx都认为失败 |
| **TCP连接** | 成功建立 | 连接超时 | 检查端口是否可达 |
| **响应时间** | < 500ms | > 2000ms | 超时时间通常设为2-5秒 |
| **连续失败次数** | - | 3次 | 避免单次抖动误判 |
| **检查间隔** | - | 5s | 太频繁会增加负载 |

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

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

---

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

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

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

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

<SessionPersistenceDemo />

### 4.2 三种会话保持机制对比

| 机制           | 实现原理                                  | 优点                            | 缺点                          | 适用场景                |
| :------------- | :---------------------------------------- | :------------------------------ | :---------------------------- | :---------------------- |
| **Cookie插入** | LB在响应中插入Cookie,后续请求携带此Cookie | 不受IP变化影响,首次请求即可保持 | 客户端需支持Cookie,可能被禁用 | 电商购物车、登录态保持  |
| **IP哈希**     | 对客户端IP做哈希计算,映射到特定服务器     | 无需客户端支持,无状态           | IP变化会丢失会话,难以均匀分布 | 无Cookie环境、WebSocket |
| **粘性会话表** | LB维护会话到服务器的映射表                | 支持会话复制和故障转移          | 占用LB内存,需要额外同步       | 高可用要求严格的场景    |

::: tip 💡 使用建议

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

---

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

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

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

<BlueGreenDeploymentDemo />

**工作流程:**

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

::: tip ✨ 优缺点分析
| 优点 | 缺点 |
|:---|:---|
| ✅ 零停机时间,切换在毫秒级完成 | ❌ 资源成本高,需要同时维护两套环境 |
| ✅ 快速回滚,发现问题立即切回原环境 | ❌ 数据库Schema变更时需要特别处理兼容性 |
| ✅ 新环境可完整测试后再接管流量 | ❌ 不适用于有状态服务(如WebSocket长连接) |

:::

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

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

<CanaryReleaseDemo />

**核心思想:**

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

::: tip 💡 金丝雀发布的优势
| 优势 | 说明 |
|:---|:---|
| 🎯 **风险可控** | 即使新版本有严重Bug,也只影响少量用户 |
| 📊 **真实验证** | 在真实生产环境验证,比测试环境更可靠 |
| 🚀 **快速迭代** | 团队可以更自信地频繁发布新功能 |
| 💰 **资源友好** | 不需要像蓝绿部署那样准备两套完整环境 |

:::

---

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

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

想象你开了一家餐厅:

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

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

<AutoScalingDemo />

### 6.2 扩容指标的选择

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

常见的决策指标:

| 指标                | 扩容阈值   | 缩容阈值   | 适用场景         |
| :------------------ | :--------- | :--------- | :--------------- |
| **CPU使用率**       | > 70%      | < 30%      | 计算密集型应用   |
| **内存使用率**      | > 75%      | < 40%      | 内存密集型应用   |
| **QPS(每秒请求数)** | > 1000/s   | < 400/s    | API网关、Web服务 |
| **连接数**          | > 5000     | < 1000     | 数据库、消息队列 |
| **自定义业务指标**  | 视业务而定 | 视业务而定 | 特定业务场景     |

::: tip 💡 扩容策略的"坑"与"解"

**坑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 主流负载均衡器对比

| 特性           | Nginx                           | HAProxy               | Envoy          | 云厂商负载均衡 |
| -------------- | ------------------------------- | --------------------- | -------------- | -------------- |
| **定位**       | 高性能反向代理/负载均衡         | 开源负载均衡          | 云原生代理     | 托管负载均衡   |
| **性能**       | 极高(C语言,事件驱动)            | 高(事件驱动)          | 高(C++/Rust)   | 极高           |
| **功能丰富度** | 基础负载均衡、静态文件、缓存    | 丰富的负载均衡算法    | 高级路由、观测 | 功能全面       |
| **配置**       | 配置文件(nginx.conf)            | 配置文件(haproxy.cfg) | API/配置文件   | UI控制台       |
| **扩展**       | C模块/Lua脚本                   | Lua脚本               | WASM/Filter    | 插件           |
| **适用场景**   | 静态资源、七层负载均衡、SSL终结 | 七层负载均衡、高可用  | 服务网格、多云 | 快速上手       |

::: tip 💡 选型建议
**决策树:**

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

:::

---

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

### 8.1 核心原则回顾

| 原则     | 含义                       | 实践要点                              |
| -------- | -------------------------- | ------------------------------------- |
| **分层** | L4处理"快递分拣"(快但简单) | L4处理数据库、游戏;L7处理Web、API     |
| **冗余** | 单点故障是架构的敌人       | 通过多实例、多区域部署提升可用性      |
| **渐进** | 发布新版本不要"一刀切"     | 蓝绿部署实现零停机;金丝雀实现风险可控 |
| **弹性** | 系统应该像生命体一样"呼吸" | 忙时自动扩容,闲时自动缩容             |

### 8.2 设计检查清单

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

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

---

## 9. 名词速查表

| 名词             | 英文                                      | 解释                                                                 |
| ---------------- | ----------------------------------------- | -------------------------------------------------------------------- |
| **负载均衡器**   | Load Balancer                             | 将流量分发到多个后端服务器的设备或软件                               |
| **四层负载均衡** | L4 Load Balancing                         | 基于传输层(TCP/UDP)的负载均衡                                        |
| **七层负载均衡** | L7 Load Balancing                         | 基于应用层(HTTP/HTTPS)的负载均衡                                     |
| **健康检查**     | Health Check                              | 定期检查后端服务器的健康状态的机制                                   |
| **会话保持**     | Session Persistence                       | 确保同一用户的请求始终路由到同一台服务器                             |
| **粘性会话**     | Sticky Session                            | 另一种称呼，同Session Persistence                                    |
| **蓝绿部署**     | Blue-Green Deployment                     | 两套环境切换的零停机发布策略                                         |
| **金丝雀发布**   | Canary Release                            | 小流量先行验证的灰度发布策略                                         |
| **自动扩缩容**   | Auto Scaling                              | 根据负载自动增加或减少服务器数量                                     |
| **水平扩展**     | Horizontal Scaling                        | 增加服务器数量来提升处理能力                                         |
| **垂直扩展**     | Vertical Scaling                          | 提升单机配置(CPU、内存)来提升处理能力                                |
| **多区域**       | Multi-Region                              | 在多个地理区域部署服务                                               |
| **多活**         | Active-Active                             | 多个区域同时对外提供服务                                             |
| **主备**         | Active-Standby                            | 只有一个区域提供服务，其他待命                                       |
| **数据同步**     | Data Replication                          | 跨区域的数据复制机制                                                 |
| **RTO**          | Recovery Time Objective (RTO)             | 恢复时间目标，系统故障后需要在多长时间内恢复                         |
| **RPO**          | Recovery Point Objective (RPO)            | 恢复点目标，系统故障后可以接受的数据丢失量                           |