# 第10天：Auto Scaling 与负载均衡——自动应对流量洪峰

## 今天你将学到什么

今天学两个配合使用的服务：负载均衡器（ELB）和自动伸缩（Auto Scaling）。它们解决的问题是：**流量来了自动加机器，流量走了自动减机器，全程不需要人工干预。**

---

## 为什么需要这两个东西

### 场景一：单台服务器的困境

你开了一个网站，只有一台服务器。

- 平时 100 人访问：没问题，服务器轻松应对
- 突然上了热搜，10000 人同时涌入：服务器扛不住，网站崩了
- 你手忙脚乱地加服务器，等你加好了，热度已经过了

### 场景二：多台服务器的困境

你学聪明了，一开始就部署了 10 台服务器。

- 平时 100 人访问：9 台服务器在空转，白白烧钱
- 突然 10000 人来了：可能还是不够
- 你不知道该准备多少台才"刚好"

**Auto Scaling + 负载均衡 = 完美解决方案**：
- 负载均衡器：把用户请求均匀分配给多台服务器
- Auto Scaling：根据流量自动增减服务器数量

---

## 负载均衡器（ELB）——流量的"交通警察"

### 什么是负载均衡

想象一个银行大厅有 5 个柜台窗口。门口有一个引导员（负载均衡器），他的工作是：
- 看哪个窗口人少，就把新来的客户引导到那个窗口
- 如果某个窗口的柜员去上厕所了（服务器故障），就不再往那个窗口引导人
- 客户不需要自己选窗口，引导员帮你选最快的

**负载均衡器做的就是这件事**：把用户的请求分发到多台健康的服务器上。

### AWS 的三种负载均衡器

| 类型 | 工作层级 | 适合场景 | 生活类比 |
|------|----------|----------|----------|
| ALB（应用负载均衡器） | HTTP/HTTPS 层 | 网站、API、微服务 | 餐厅领位员（根据你要吃什么引导到不同区域） |
| NLB（网络负载均衡器） | TCP/UDP 层 | 游戏、IoT、超高性能 | 高速公路收费站（只管放行，不看车里装什么） |
| GWLB（网关负载均衡器） | 网络层 | 防火墙、安全设备 | 安检通道 |

**90% 的场景用 ALB 就够了。**

### ALB 的智能路由

ALB 不只是简单地"轮流分配"，它还能根据请求内容做智能路由：

- 访问 `www.example.com/api/*` → 发到 API 服务器组
- 访问 `www.example.com/images/*` → 发到图片服务器组
- 访问 `admin.example.com` → 发到管理后台服务器

### 健康检查

ALB 会定期"问候"每台服务器："你还活着吗？"

- 每隔 30 秒发一个请求到服务器的 `/health` 路径
- 如果服务器连续几次没回应 → 标记为"不健康"
- 不健康的服务器不再接收新的用户请求
- 服务器恢复后，自动重新加入

**用户完全感知不到某台服务器挂了**——因为 ALB 已经悄悄把流量切走了。

---

## Auto Scaling——自动增减服务器

### 核心概念

**启动模板**：新服务器的"配置清单"——用什么操作系统、什么实例类型、装什么软件。相当于"造机器的图纸"。

**Auto Scaling 组（ASG）**：管理一群服务器，定义三个数字：
- **最小值**（min）：保底数量，永远不会少于这个数。比如 2 台。
- **期望值**（desired）：正常情况下的数量。比如 4 台。
- **最大值**（max）：上限，防止无限扩展（防止账单爆炸）。比如 20 台。

### 伸缩策略——什么时候加机器、什么时候减机器

**策略一：目标跟踪（最简单，推荐新手用）**

你只需要说："我希望所有服务器的平均 CPU 使用率保持在 50%。"

然后 Auto Scaling 自动帮你：
- CPU 超过 50% → 加机器
- CPU 低于 50% → 减机器

就像空调的恒温模式——你设定 25 度，空调自动调节制冷/制热。

**策略二：计划伸缩（适合有规律的流量）**

如果你知道流量的规律：
- 每天早上 9 点流量开始上升 → 8:50 提前扩到 8 台
- 每天晚上 10 点流量下降 → 22:00 缩回 3 台
- 每周五下午流量特别大 → 周五 14:00 扩到 12 台

就像定时开关灯——你知道什么时候需要，提前安排好。

**策略三：步进伸缩（更精细的控制）**

设置多个阈值：
- CPU > 60% → 加 1 台
- CPU > 80% → 加 3 台
- CPU > 95% → 加 5 台（紧急！）
- CPU < 30% → 减 1 台

---

## 两者配合的完整架构

```
用户访问你的网站
        ↓
    负载均衡器（ALB）
    ┌───┼───┐
    ↓   ↓   ↓
  服务器A 服务器B 服务器C  ← Auto Scaling 管理
  (AZ-a)  (AZ-b)  (AZ-c)     最小2台，最大10台
```

**工作流程**：
1. 用户请求到达 ALB
2. ALB 把请求分发给健康的服务器
3. 如果流量增大，服务器 CPU 升高
4. Auto Scaling 检测到 CPU 超标，自动启动新服务器
5. 新服务器启动后，ALB 自动把它加入分发列表
6. 流量下降后，Auto Scaling 自动关闭多余的服务器

**全程无需人工干预。**

---

## 一个真实的例子

某在线教育平台：
- 工作日白天：5000 并发用户 → 需要 5 台服务器
- 周末晚上直播课：50000 并发用户 → 需要 50 台服务器
- 凌晨 3 点：100 并发用户 → 需要 2 台服务器

如果固定 50 台服务器：每月费用约 $3,600
用 Auto Scaling：每月费用约 $800（省了 78%）

---

## 今天的小测验

1. 负载均衡器的作用是什么？用你自己的话解释。
2. Auto Scaling 的"最小值、期望值、最大值"分别是什么意思？
3. 如果你的网站流量每天早上 9 点开始增长，应该用什么伸缩策略？
4. 为什么要设置"最大值"？不设会怎样？

---

## 延伸阅读

- [ELB 产品介绍](https://aws.amazon.com/elasticloadbalancing/)
- [Auto Scaling 用户指南](https://docs.aws.amazon.com/autoscaling/ec2/userguide/)

---

## 明天预告

明天进入无服务器计算：AWS Lambda。不用管服务器，只写一个函数，AWS 帮你运行。按调用次数付费，不调用不花钱。