7.0 KiB
第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 部署
- 你的架构要能容忍底层服务的故障
今天的小测验
- 如果你的用户主要在日本，应该选哪个 Region？
- 为什么一个 Region 要有多个可用区？用你自己的话解释。
- 边缘节点和 Region 有什么区别？它们各自解决什么问题？
- 如果你只把应用部署在一个可用区，会有什么风险？
延伸阅读
明天预告
明天我们动手了！注册 AWS 账户、设置安全保护、配置账单告警。正式踏入 AWS 的大门。我会一步步带你操作，确保你不会踩坑（尤其是不会被意外扣费）。