地理路由與多區域部署

地理路由把用戶請求導向最近的服務器，減少延遲，提供更快的體驗。

地理路由使用場景

沒有地理路由：
台灣用戶 ────────────────────→ 美國服務器（200ms 延遲）
歐洲用戶 ────────────────────→ 美國服務器（150ms 延遲）
有地理路由：
台灣用戶 → 亞洲服務器（20ms）
歐洲用戶 → 歐洲服務器（15ms）
美洲用戶 → 美國服務器（10ms）

Cloudflare 地理路由

Cloudflare Load Balancing 支持地理路由（付費功能）：

路徑： Traffic → Load Balancing → Create Load Balancer → Geo Steering

設置：

亞太地區（APAC）→ Origin Pool Asia（亞洲服務器）
歐洲（EEA）→ Origin Pool Europe（歐洲服務器）
北美（WNAM / ENAM）→ Origin Pool US（美國服務器）
默認（其他地區）→ Origin Pool US（或最近的）

AWS Route 53 Geolocation Routing

Geolocation 記錄設置：
台灣（TW）→ 192.0.2.1（亞洲服務器）
日本（JP）→ 192.0.2.1（亞洲服務器）
德國（DE）→ 192.0.2.2（歐洲服務器）
美國（US）→ 192.0.2.3（美國服務器）
默認       → 192.0.2.3（全球默認）

注意： 必須設置「默認」記錄，否則不在任何指定地區的用戶無法解析。

Latency-Based Routing（延遲路由）

比地理位置路由更精確——Route 53 根據實際測量的網絡延遲路由，而非 IP 地理位置推斷：

用戶在台灣，但網絡延遲：
亞洲節點：25ms
美國節點：200ms
Route 53 → 選擇亞洲節點（延遲更低）

何時使用延遲路由 vs 地理路由： - 用戶明確需要訪問特定地區的數據（GDPR 合規）→ 地理路由 - 純粹追求最快速度 → 延遲路由

多區域部署架構設計

主動-主動架構（Active-Active）

所有區域都可以接受並處理請求：

全球 DNS（Cloudflare / Route 53）
├── 亞洲數據中心（可讀+可寫）
├── 歐洲數據中心（可讀+可寫）
└── 美洲數據中心（可讀+可寫）
數據同步：數據庫跨區域同步（複雜）

優點： 最低延遲，最高可用性 缺點： 數據一致性複雜，實現成本高

主動-被動架構（Active-Passive）

一個主要區域，其他區域只在故障時啟用：

正常：
所有流量 → 美國主數據中心
故障切換：
DNS TTL 300 秒後 → 流量切到亞洲備用數據中心

優點： 實現簡單，數據一致性容易保證 缺點： 非主數據中心的用戶延遲高

DNS 分區視圖（Split-Horizon DNS）

同一個域名，在不同網絡（內網/外網）返回不同的 IP：

外網用戶查詢 api.example.com → 返回 203.0.113.10（公網 IP）
內網用戶查詢 api.example.com → 返回 192.168.1.10（內網 IP）

實現方式： - 企業內部 DNS 服務器：對內網域名返回私有 IP - 外部 DNS：返回公網 IP - 適用於有內部系統的企業，內部訪問不必繞道外部

下一章：實戰項目——把所有知識整合成一個實際部署案例。