域名解析原理与网络接入
12.7 服务区域选择
Tip
光速虽然快，但绕地球一圈也要 133ms。对于网络游戏或高频交易，几毫秒的延迟决定胜负。对于网页，延迟越低，用户体验越好。Region (区域) 选择就是物理选址。
1. 为什么要学这个?
你做了一个给德国用户用的商城。 你手滑选了 us-east-1 (美国弗吉尼亚)。 德国用户每次点击都要跨越大西洋，一来一回。 只有 200ms 的延迟，但给用户的感觉就是“卡顿”、“不跟手”。 物理距离是无法用代码优化的，只能靠选址解决。
2. 核心概念：Latency (延迟)
延迟通常由三部分组成：
- 物理距离 (无法改变)：光缆长度。
- 网络拥塞 (可优化)：高峰期排队。
- 服务器处理 (可优化)：代码效率。
我们选 Region，主要解决的是第一点。
常见 Region 代码
us-east-1: 美东 (全球互联网中心，最便宜)。ap-northeast-1: 东京 (覆盖日韩)。ap-southeast-1: 新加坡 (覆盖东南亚，有时包括中国大陆)。eu-central-1: 法兰克福 (覆盖中欧)。
3. 解决方案 (HOW)
3.1 决策逻辑
你的 80% 用户在哪里？
- 中国大陆: 选香港 (
ap-east-1) 或 东京。 - 北美: 选美东 (
us-east-1)。 - 全球: 选美东 (折中方案，或者上多区域部署)。
- 欧洲: 选法兰克福 (必须考虑 GDPR 数据合规)。
3.2 区域延迟示意图
graph TD
User["中国用户"] -->|"Step 1: 30ms"| HK["香港节点 (HK)"]
User -->|"Step 2: 150ms"| US["美东节点 (US)"]
User -->|"Step 3: 300ms"| EU["欧洲节点 (EU)"]
style HK fill:#c8e6c9,stroke:#2e7d32
style US fill:#fff9c4,stroke:#fbc02d
style EU fill:#ffcdd2,stroke:#c62828
4. 避坑指南
| ❌ 不要这样做 | ✅ 应该这样做 | 为什么 |
|---|---|---|
| App 与 DB 异地 | 同区部署 | App 在东京，DB 在纽约。这是灾难。你是希望你的每一个 SQL 查询都去太平洋里游个泳吗？ |
| 忽视价格 | 比价 | 圣保罗 (南美) 或首尔的流量费、实例费通常比美东贵 50% 以上。除非必要，别去贵的区。 |
| 忽视合规 | 数据驻留 (Data Residency) | 欧盟的 GDPR 规定欧洲用户数据不得出境。如果你选了美东存欧洲数据，可能会面临巨额罚款。 |
5. 真实案例
Story
2006年，被震断的光缆
2006年，台湾恒春地震震断了多条海底光缆。 中国大陆访问美国网站全部中断。MSN 登不上，GitHub 连不上，哪怕你的服务器没挂，但路断了。
Vibe 心法：距离即延迟，延迟即流失。计算可以部署在全球任何地方，但核心数据必须紧贴你的用户重心。地缘政治与海底光缆的物理路径，有时比复杂的负载均衡策略更直接地决定了成败。
6. 本章小结
- 就近：服务部署在离用户最近的地方。
- 同区：计算 (App) 和存储 (DB) 必须在同一个机房，这是铁律。
- 合规：数据主权（数据不能出境）越来越严格。