高可用與容災
前言
系統掛了 1 分鐘，可能意味著幾十萬的損失。 高可用（High Availability）是指系統在面對硬體故障、軟體 Bug、網路問題等異常情況時，仍能持續提供服務的能力。容災（Disaster Recovery）則是在更大範圍的災難發生時，系統能夠恢復服務的能力。
這篇文章會帶你學什麼？
學完這章後，你將獲得：
- 可用性度量：理解「幾個 9」的含義和對應的停機時間
- 故障轉移：掌握主備、主主、多活等高可用架構
- 容災策略：了解 RPO 和 RTO 的概念及設計方法
- 故障檢測：理解心跳、探針、熔斷等故障發現機制
- 混沌工程：了解如何主動注入故障來驗證系統韌性
| 章節 | 內容 | 核心概念 |
|---|---|---|
| 第 1 章 | 可用性度量 | SLA、幾個 9、停機時間 |
| 第 2 章 | 故障轉移架構 | 主備、主主、多可用區、異地多活 |
| 第 3 章 | 容災設計 | RPO、RTO、備份策略 |
| 第 4 章 | 故障檢測與恢復 | 心跳、熔斷、自動擴縮容 |
| 第 5 章 | 混沌工程 | 故障注入、韌性驗證 |
1. 可用性度量：幾個 9 意味著什麼？
可用性通常用「幾個 9」來衡量，計算公式為：
可用性 = 正常運行時間 / 總時間 × 100%
例如一個月（30 天 = 43200 分鐘）內停機了 43 分鐘，可用性就是 (43200 - 43) / 43200 ≈ 99.9%。每多一個 9，允許的停機時間就少一個數量級，實現難度和成本也指數級增長。
| 可用性等級 | 百分比 | 每月允許停機 | 每年允許停機 | 典型要求 |
|---|---|---|---|---|
| 2 個 9 | 99% | 7.3 小時 | 3.65 天 | 內部工具 |
| 3 個 9 | 99.9% | 43 分鐘 | 8.76 小時 | 普通業務系統 |
| 4 個 9 | 99.99% | 4.3 分鐘 | 52.6 分鐘 | 電商、SaaS |
| 5 個 9 | 99.999% | 26 秒 | 5.26 分鐘 | 金融、支付 |
SLA 是什麼？
SLA（Service Level Agreement，服務等級協議） 是服務提供方與客戶之間的正式承諾。比如 AWS S3 承諾 99.99% 的可用性，如果沒達到，會按比例退款。SLA 不只是技術指標，更是商業合約——違反 SLA 意味著賠錢。
從 3 個 9 到 4 個 9 的鴻溝
3 個 9（99.9%）意味著每月可以停機 43 分鐘——一次部署出問題，回滾一下就用完了。 4 個 9（99.99%）意味著每月只能停機 4 分鐘——這要求你必須有自動故障轉移、滾動部署、健康檢查等完整的高可用體系。
2. 故障轉移架構
故障轉移（Failover）是高可用的核心機制：當主節點故障時，自動切換到備用節點繼續提供服務。
主備模式（Active-Standby）
最常見的高可用架構。主節點處理所有請求，備節點即時同步資料但不處理請求。主節點故障時，備節點自動接管。
正常狀態：
客戶端 → 主節點（處理請求）
備節點（同步資料，待命）
故障轉移：
客戶端 → 備節點（接管為新主節點）
原主節點（故障，等待修復）關鍵問題是腦裂（Split Brain）：網路分區時，主備節點都認為對方掛了，同時對外提供服務，導致資料不一致。解決方案是引入仲裁節點（Quorum）——至少 3 個節點投票決定誰是主節點。
多可用區（Multi-AZ）
將服務部署在同一地域的多個資料中心（可用區）。單個資料中心斷電、斷網不影響整體服務。雲端廠商的可用區之間通常有低延遲專線連接（< 2ms）。
異地多活（Multi-Region Active-Active）
在不同城市甚至不同國家部署完整的服務副本，每個站點都能獨立處理請求。這是最高級別的高可用架構，但也最複雜——核心挑戰是跨地域資料同步的延遲和一致性問題。
| 架構 | 可用性級別 | 成本 | 複雜度 | 適用場景 |
|---|---|---|---|---|
| 單機 | 99%~99.9% | 低 | 低 | 開發測試、內部工具 |
| 主備 | 99.9%~99.99% | 中 | 中 | 中小型業務系統 |
| 多可用區 | 99.99% | 高 | 高 | 電商、SaaS 平台 |
| 異地多活 | 99.999% | 極高 | 極高 | 金融、大型網際網路 |
3. 容災設計：RPO 與 RTO
容災設計圍繞兩個核心指標展開：
| 指標 | 全稱 | 含義 | 舉例 |
|---|---|---|---|
| RPO | Recovery Point Objective | 能容忍遺失多少資料 | RPO=0 表示不能丟任何資料 |
| RTO | Recovery Time Objective | 能容忍停機多長時間 | RTO=5min 表示 5 分鐘內恢復 |
備份策略與 RPO 的關係
| 備份方式 | RPO | 成本 | 說明 |
|---|---|---|---|
| 每日全量備份 | 24 小時 | 低 | 最多丟一天資料 |
| 即時增量備份 | 分鐘級 | 中 | binlog/WAL 持續同步 |
| 同步複製 | 0 | 高 | 寫入必須等副本確認 |
不是所有資料都需要 RPO=0
使用者頭像丟了可以重新上傳（RPO=24h 夠了），但支付記錄一條都不能丟（RPO=0）。根據資料的業務價值來決定備份策略，而不是一刀切。
4. 故障檢測與恢復
4.1 故障檢測機制
| 機制 | 原理 | 檢測速度 | 適用場景 |
|---|---|---|---|
| 心跳檢測 | 定期發送心跳封包，逾時判定故障 | 秒級 | 節點存活檢測 |
| 健康檢查 | HTTP/TCP 探針檢查服務狀態 | 秒級 | 負載均衡器後端檢測 |
| 業務探針 | 模擬真實請求檢查業務邏輯 | 秒~分鐘級 | 端到端可用性監控 |
心跳檢測的工作原理：節點 A 每隔固定時間（如 5 秒）向監控方發送一個「我還活著」的訊號。如果連續 N 次（如 3 次）沒收到心跳，就判定節點 A 故障。關鍵參數是心跳間隔和逾時閾值——間隔太短會增加網路開銷，太長會延遲故障發現。
健康檢查的三種級別：
- 存活探針（Liveness）：進程還在運行嗎？不在就重啟
- 就緒探針（Readiness）：服務能接受請求嗎？不能就從負載均衡中摘除
- 啟動探針（Startup）：服務啟動完成了嗎？沒完成就等待，不要誤判為故障
4.2 自動恢復機制
| 機制 | 描述 | 典型工具 |
|---|---|---|
| 自動重啟 | 進程崩潰後自動拉起 | systemd、PM2、K8s |
| 自動擴縮容 | 負載升高時自動增加實例 | K8s HPA、雲端廠商 Auto Scaling |
| 熔斷降級 | 下游故障時快速失敗，防止級聯故障 | Hystrix、Sentinel、Resilience4j |
| 限流 | 超過容量的請求直接拒絕 | Nginx limit_req、閘道限流 |
熔斷器模式（Circuit Breaker）詳解：
熔斷器的靈感來自電路中的保險絲——當電流過大時自動斷開，保護整個電路不被燒毀。在微服務中，當下游服務故障時，熔斷器會「斷開」，讓請求快速失敗，而不是傻等逾時。
熔斷器三種狀態：
關閉（正常）──→ 失敗率超過閾值 ──→ 打開（熔斷）
↑ │
│ 等待冷卻時間
│ ↓
└── 探測請求成功 ←── 半開（試探）- 關閉狀態：正常轉發請求，同時統計失敗率
- 打開狀態：所有請求直接回傳錯誤（快速失敗），不再呼叫下游
- 半開狀態：冷卻時間到後，放行少量探測請求。如果成功，恢復關閉；如果失敗，繼續打開
降級（Fallback） 是熔斷的配套策略：熔斷觸發後，不是直接報錯，而是回傳一個「兜底」結果。比如推薦服務掛了，就回傳熱門商品列表；使用者頭像載入失敗，就顯示預設頭像。
5. 混沌工程：主動找問題
混沌工程的核心理念是：與其等故障發生，不如主動製造故障，在可控環境中驗證系統的韌性。
| 工具 | 提出者 | 核心能力 |
|---|---|---|
| Chaos Monkey | Netflix | 隨機終止生產環境的實例 |
| Chaos Mesh | PingCAP | K8s 環境下的故障注入 |
| Litmus | CNCF | 雲原生混沌工程框架 |
| ChaosBlade | 阿里巴巴 | 多場景故障注入工具 |
混沌工程的實施步驟
- 定義穩態：明確系統正常運行的指標（如 P99 延遲 < 200ms）
- 提出假設：如果某個節點掛了，系統應該在 30 秒內自動恢復
- 注入故障：在可控範圍內製造故障（先在測試環境，再到生產）
- 觀察結果：系統是否如預期恢復？有沒有級聯故障？
- 修復弱點：發現問題後改進架構和流程
總結
高可用不是一個功能，而是一種架構能力。它需要從設計、開發、部署、維運的每個環節去保障。
回顧本章的關鍵要點：
- 幾個 9：每多一個 9，停機時間少一個數量級，成本和複雜度指數增長
- 故障轉移：從主備到異地多活，根據業務需求選擇合適的架構
- RPO 與 RTO：根據資料價值和業務容忍度設計備份和恢復策略
- 自動化：故障檢測、自動重啟、熔斷降級是高可用的基礎設施
- 混沌工程：主動製造故障，在可控環境中驗證系統韌性
延伸閱讀
- Site Reliability Engineering - Google SRE 經典
- Chaos Monkey - Netflix 混沌工程工具
- Release It! - 生產環境設計模式
- Chaos Mesh - K8s 混沌工程平台