185 lines
7.0 KiB
Markdown
185 lines
7.0 KiB
Markdown
|
# 第4天：AWS 全球基础设施——你的数据存在哪里
|
|||
|
|
|
|||
|
|
## 今天你将学到什么
|
|||
|
|
|
|||
|
|
今天我们来看 AWS 在全球的"地盘"是怎么布局的。这不是纯理论——它直接决定了：
|
|||
|
|
- 你的用户访问速度快不快
|
|||
|
|
- 你的系统能不能扛住灾难
|
|||
|
|
- 你的数据是否满足法律要求
|
|||
|
|
|
|||
|
|
学完今天，你会明白 Region、可用区、边缘节点这三个概念，以及怎么选择它们。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 先想一个问题
|
|||
|
|
|
|||
|
|
假设你在北京开了一家网店，服务器放在北京。那么：
|
|||
|
|
- 北京的用户访问你的网站：很快（几十毫秒）
|
|||
|
|
- 上海的用户访问：还行（稍微慢一点）
|
|||
|
|
- 美国的用户访问：很慢（数据要跨越太平洋，几百毫秒）
|
|||
|
|
|
|||
|
|
如果你想让全球用户都快，怎么办？**在全球多个地方都放服务器。**
|
|||
|
|
|
|||
|
|
这就是 AWS 全球基础设施要解决的问题。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三层结构：Region → 可用区 → 边缘节点
|
|||
|
|
|
|||
|
|
想象一个连锁酒店品牌：
|
|||
|
|
|
|||
|
|
- **Region（区域）** = 酒店在不同城市的分店（北京店、上海店、东京店）
|
|||
|
|
- **可用区（AZ）** = 同一城市内的多个酒店大楼（北京朝阳店、北京海淀店）
|
|||
|
|
- **边缘节点（Edge Location）** = 散布在各处的快递柜（方便就近取件）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Region（区域）
|
|||
|
|
|
|||
|
|
Region 是 AWS 在全球某个地理位置的一组数据中心集群。
|
|||
|
|
|
|||
|
|
截至 2024 年，AWS 在全球有 **33 个 Region**，分布在美洲、欧洲、亚太、中东、非洲。
|
|||
|
|
|
|||
|
|
**Region 的命名规则**：`地区-方位-编号`
|
|||
|
|
|
|||
|
|
举几个例子：
|
|||
|
|
| 代号 | 位置 | 常用场景 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| us-east-1 | 美国东部（弗吉尼亚） | AWS 最老最全的区域，新服务最先上线 |
|
|||
|
|
| ap-northeast-1 | 亚太（东京） | 服务日本和东亚用户 |
|
|||
|
|
| ap-southeast-1 | 亚太（新加坡） | 服务东南亚用户 |
|
|||
|
|
| eu-west-1 | 欧洲（爱尔兰） | 服务欧洲用户 |
|
|||
|
|
| cn-north-1 | 中国（北京） | 中国大陆用户（独立运营） |
|
|||
|
|
|
|||
|
|
**每个 Region 是完全独立的**：
|
|||
|
|
- 数据不会自动从一个 Region 跑到另一个 Region
|
|||
|
|
- 你在东京创建的服务器，在弗吉尼亚是看不到的
|
|||
|
|
- 这是为了数据主权——你的数据留在你选择的地方
|
|||
|
|
|
|||
|
|
### 选 Region 要考虑什么？
|
|||
|
|
|
|||
|
|
**举个例子**：你要做一个面向中国用户的电商网站。
|
|||
|
|
|
|||
|
|
| 考虑因素 | 分析 | 结论 |
|
|||
|
|
|----------|------|------|
|
|||
|
|
| 用户在哪 | 用户在中国 | 选中国区域或离中国近的（东京、新加坡） |
|
|||
|
|
| 法律要求 | 中国法律要求某些数据存储在境内 | 必须选 cn-north-1 或 cn-northwest-1 |
|
|||
|
|
| 服务可用性 | 某些新服务可能还没在中国区上线 | 需要确认你要用的服务是否可用 |
|
|||
|
|
| 价格 | 不同 Region 价格不同 | 弗吉尼亚最便宜，亚太和南美较贵 |
|
|||
|
|
|
|||
|
|
**小贴士**：如果没有特殊要求，学习阶段建议用 `us-east-1`（弗吉尼亚），因为它服务最全、价格最低、教程最多。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 可用区（Availability Zone，简称 AZ）
|
|||
|
|
|
|||
|
|
每个 Region 里面有 **3 个或更多可用区**。每个可用区是一个或多个独立的数据中心。
|
|||
|
|
|
|||
|
|
**为什么一个 Region 要有多个可用区？**
|
|||
|
|
|
|||
|
|
用一个故事来解释：
|
|||
|
|
|
|||
|
|
假设你开了一家面包店，所有的烤箱都在同一栋楼里。如果这栋楼停电了、着火了、或者被水淹了，你的整个生意就停了。
|
|||
|
|
|
|||
|
|
但如果你在同一个城市的不同地方开了 3 家分店，每家都能独立运营。即使一家店出了问题，另外两家还能继续卖面包。
|
|||
|
|
|
|||
|
|
**可用区就是这个道理**：
|
|||
|
|
|
|||
|
|
- 每个 AZ 有独立的电力供应（不同的变电站）
|
|||
|
|
- 每个 AZ 有独立的网络连接
|
|||
|
|
- 每个 AZ 有独立的制冷系统
|
|||
|
|
- AZ 之间物理距离足够远（通常几十公里），避免同一场自然灾害同时影响多个 AZ
|
|||
|
|
- 但 AZ 之间通过高速专用光纤连接，延迟极低（< 2 毫秒）
|
|||
|
|
|
|||
|
|
**这意味着什么？**
|
|||
|
|
|
|||
|
|
如果你把应用部署在同一个 Region 的 2-3 个 AZ 中，即使一个数据中心完全瘫痪（火灾、地震、断电），你的服务依然正常运行。用户甚至感觉不到。
|
|||
|
|
|
|||
|
|
**这就是 AWS 高可用架构的基石。**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 边缘节点（Edge Location）
|
|||
|
|
|
|||
|
|
AWS 在全球有 **600 多个边缘节点**，分布在各大城市。
|
|||
|
|
|
|||
|
|
**边缘节点是干什么的？**
|
|||
|
|
|
|||
|
|
还是用例子说明：
|
|||
|
|
|
|||
|
|
你在东京有一台服务器，上面放着你网站的图片和视频。一个巴西的用户要看你的网站，数据要从东京传到巴西，跨越半个地球，需要 200-300 毫秒。
|
|||
|
|
|
|||
|
|
但如果你把这些图片和视频提前"复制"一份到巴西的边缘节点，巴西用户直接从本地的边缘节点获取，只需要 10-20 毫秒。
|
|||
|
|
|
|||
|
|
**边缘节点主要服务于**：
|
|||
|
|
- **CloudFront（CDN）**：缓存网站的静态内容（图片、视频、CSS、JS），让全球用户就近获取
|
|||
|
|
- **Route 53（DNS）**：就近解析域名，加快网站打开速度
|
|||
|
|
- **AWS WAF**：在边缘拦截恶意攻击，坏流量根本到不了你的服务器
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三者的关系总结
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
全球
|
|||
|
|
├── Region: 美国东部 (us-east-1)
|
|||
|
|
│ ├── 可用区 A (us-east-1a) — 数据中心群 1
|
|||
|
|
│ ├── 可用区 B (us-east-1b) — 数据中心群 2
|
|||
|
|
│ ├── 可用区 C (us-east-1c) — 数据中心群 3
|
|||
|
|
│ └── ...更多 AZ
|
|||
|
|
├── Region: 亚太东京 (ap-northeast-1)
|
|||
|
|
│ ├── 可用区 A
|
|||
|
|
│ ├── 可用区 B
|
|||
|
|
│ └── 可用区 C
|
|||
|
|
├── ...更多 Region
|
|||
|
|
│
|
|||
|
|
└── 边缘节点（600+，遍布全球各大城市）
|
|||
|
|
├── 北京
|
|||
|
|
├── 上海
|
|||
|
|
├── 东京
|
|||
|
|
├── 纽约
|
|||
|
|
├── 伦敦
|
|||
|
|
└── ...
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**记住一个口诀**：
|
|||
|
|
- **用 AZ 实现高可用**（一个机房挂了，另一个顶上）
|
|||
|
|
- **用 Region 实现灾难恢复**（一个地区出大问题，切换到另一个地区）
|
|||
|
|
- **用边缘节点实现低延迟**（内容推到用户身边）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一个真实的故障案例
|
|||
|
|
|
|||
|
|
2017 年 2 月 28 日，AWS 美国东部（us-east-1）的 S3 存储服务发生了大规模故障，持续约 4 小时。
|
|||
|
|
|
|||
|
|
受影响的知名服务包括：Slack、Trello、Quora，甚至 AWS 自己的状态页面都挂了（因为状态页面也托管在 S3 上）。
|
|||
|
|
|
|||
|
|
**教训**：
|
|||
|
|
- 即使是 AWS 自己的服务也会出故障
|
|||
|
|
- 不要把所有东西都放在一个 Region
|
|||
|
|
- 关键业务要考虑多 Region 部署
|
|||
|
|
- 你的架构要能容忍底层服务的故障
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 今天的小测验
|
|||
|
|
|
|||
|
|
1. 如果你的用户主要在日本，应该选哪个 Region？
|
|||
|
|
2. 为什么一个 Region 要有多个可用区？用你自己的话解释。
|
|||
|
|
3. 边缘节点和 Region 有什么区别？它们各自解决什么问题？
|
|||
|
|
4. 如果你只把应用部署在一个可用区，会有什么风险？
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [AWS 全球基础设施地图（可交互）](https://aws.amazon.com/about-aws/global-infrastructure/)
|
|||
|
|
- [AWS 2017 年 S3 故障复盘报告](https://aws.amazon.com/message/41926/)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 明天预告
|
|||
|
|
|
|||
|
|
明天我们动手了！注册 AWS 账户、设置安全保护、配置账单告警。正式踏入 AWS 的大门。我会一步步带你操作，确保你不会踩坑（尤其是不会被意外扣费）。
|