大多數團隊會設計範例和區域故障，但將區域級別的停機視為別人的問題。區域級別的故障很少見——但它們不是理論上的。AWS us-east-1 已經經歷過多次重大事件。Azure AD 在 2023 年遭受了全球身份驗證停機。Google Cloud 的 europe-west9 因數據中心火災而離線。
當一個區域失敗時，爆炸半徑並非單一服務。它包含每一個工作負載、每一個資料庫、每一個佇列，以及每一個範圍於該區域的控制平面操作。
跨區域並不保護免受區域性失敗
跨區域保護免受資料中心失敗。它不保護免受：
- 區域性控制平面失敗 — 管理您資源的 API 是區域性的。如果它變得低效，您就無法擴展或部署。
- 區域性服務中斷 — SQS、Lambda、DynamoDB、Cosmos DB 都是區域性的。
- 共享命運依賴 — IAM、Secrets Manager、Key Vault 是區域性的。如果您的應用程式無法取出密鑰，那麼即使計算在三個 AZ 中都正常，也沒有關係。
2021年12月亞馬遜網絡服務公司的us-east-1事件就證明了這一點。未受影響的區域內的服務出現了降解，因為它們的依賴項不是區域獨立的。
多區域架構模式
引導燈 — 次要區域具有最小的基礎設施（數據庫副本、網絡）。計算在故障轉移時提供。恢復時間目標：15-60分鐘。成本：約為主要區域的10-15%。
熱備用 — 副本運行一個縮小但完全功能的副本。在故障轉移時，縮放並提升DB。RTO：5-15分鐘。成本：約25-40%的 主副本。
主-主 — 兩個區域同時服務流量。不需要故障轉移。需要跨區域寫入（DynamoDB Global Tables, Cosmos DB）和衝突解決。RTO：接近零。成本：約80-100%+的 主副本。
數據複製：最難的問題
- 同步 — 零數據損失，但寫入每次增加 50-150ms。對大多數工作負載來說不實際。
- 非同步 — 沒有寫入延遲影響，但會產生複製延遲窗口，如果主機故障，數據可能會丟失。
對於主備同步複製，您需要一個衝突解決策略。最後寫入者優先適用於配置檔案和偏好設定。它會靜默地丟棄計數器和餘額的寫入 — 在這裡使用應用層級合併或CRDTs.
實用規則：如果您無法為數據實體定義一個衝突解決策略，請將其寫入路由到單個主要區域.
故障轉移自動化
手動切換並非真正切換。在區域級別的災難下，手動步驟會失敗或耗時遠超預期。
- 基於DNS的切換（Route 53, Traffic Manager）應根據實際區域功能進行健康檢查，而不僅僅是流程活性
- 透過API自動化數據庫提升（Aurora Global：不到1分鐘，RDS跨區域：5-10分鐘）
- 每季進行測試 — 不是桌面演練，是實際的切換。測量實際的RTO。修復差距.
常見錯誤
- 未測試的切換 — 是一個假設，不是一個計劃
- 隱藏的地區性依賴 — 身份提供者或密鑰管理器釘定在一個地區
- 兩個地區使用相同的部署管道 — 一個壞的部署同時帶下兩者
- 沒有容量規劃 — 副區域在擴展時觸及服務配額
閱讀全文
這是我對多區域韌性的深入探討總結。全文涵蓋了所有模式，包含AWS和Azure架構草圖、成本分析，以及決策框架：
完整文章包含：
- 多個區域（Multi-AZ）對比多個地區 — 每個實際保護的內容（以及它不保護的內容）
- 三種模式具有 RTO/RPO/成本配置文件（Pilot Light, Warm Standby, Active-Active）
- AWS 和 Azure 的主動-主動架構草圖
- 數據複製深入探討（同步對非同步、管理式資料庫選項、衝突解決）
- 使用Route 53設定和健康檢查設計的故障轉移自動化
- 成本對韌性決策框架與工作負載分級
- 六個會破壞多區域架構的常見錯誤