172 lines
6.0 KiB
Markdown
172 lines
6.0 KiB
Markdown
# 第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 帮你运行。按调用次数付费，不调用不花钱。
|