摘要：高可用性對於我們來說應該屬於經常提到的名詞，本文我們將介紹在分布式系統中保證高可用性的一些常用經驗。
系統可用性指標
系統可用性指標簡單來將就是系統可用時間與總運行時間之比
Availability=MTTF/(MTTF+MTTRMTTF)
MTTF 是 Mean Time To Failure，指平均故障前的時間，即系統平均能夠正常運行多長時間才發生一次故障。系統的可靠性越高，MTTF 越長(簡單理解MTTF 就是指系統正常運行的時間)。MTTR 是 Mean Time To Recovery， 平均修復時間，即從故障出現到故障修復的這段時間，也就是系統不可用的時間，這段時間越短越好。系統可用性指標可以用通過下表的999標准衡量，現在普遍要求至少2個9，最好4個9以上：
故障不可避免
高可用性是指系統提供的服務要始終可用，然而故障不可避免，特別是在分布式系統，面對不可控的用戶流量和機房環境，系統故障將會顯得更加復雜和不可預測。在大規模的分布式系統中，各個模塊之間存在錯綜復雜的依賴，任一一個環節出現問題，都有可能導致雪崩式、多米諾骨牌式的故障，甚者可以斷言出現故障成了常態。
如上圖的分布式系統中，用戶請求系統中的某個服務接口，請求需要經過長長的調用鏈才能處理返回。我們起碼要保證網絡連接正常，服務網關正常、前端服務正常、后台服務正常、數據庫正常，請求才能被正常處理，如果調用鏈中的任一環節出現問題，都會直接反饋到用戶體驗上。
系統出現故障的原因多種多樣，主要有以下這些：
- 網絡問題，網絡連接故障，網絡帶寬出現超時擁塞等；
- 性能問題，數據庫慢查詢、Java Full GC、硬盤 IO 過大、CPU 過高、內存不足等
- 安全問題，被網絡攻擊，如 DDoS 等、異常客戶端請求，如爬蟲等。
- 運維問題，需求變更頻繁不可控，架構也在不斷地被調整，監控問題等；
- 管理問題，沒有梳理出關鍵服務以及服務的依賴關系，運行信息沒有和控制系統同步；
- 硬件問題，硬盤損壞、網卡出問題、交換機出問題、機房掉電、挖掘機問題(前一陣子機房電纜就經常被挖斷)等
面對如此多的天災人禍，可控和不可控的故障因素，似乎系統的高可用性變成不可能完成的任務，但是在日常開發運維中，我們可以采用一些有效的設計、實現和運維手段來提高系統的高可用性，盡量交付一個在任何時候都基本可用的系統。
冗余設計
分布式系統中單點故障不可取的，而降低單點故障的不二法門就是冗余設計，通過多點部署的方式，並且最好是部署在不同的物理位置，避免單機房中多點同時失敗。冗余設計不僅可以提高服務的吞吐量，還可以在出現災難時快速恢復。目前常見的冗余設計有主從設計和對等治理設計，主從設計又可以細分為一主多從、多主多從。
冗余設計中一個不可避免的問題是考慮分布式系統中數據的一致性，多個節點中冗余的數據追求強一致性還是最終一致性。即使節點提供無狀態服務，也需要借助外部服務，比如數據庫、分布式緩存等維護數據狀態。根據分布式系統下節點數據同步的基本原理CAP(Consistency (一致性)、Availablity (可用性)、Partition tolerance (分區容忍性)三個指標不可同時滿足)，數據強一致性的系統無法保證高可用性，最典型的例子就是 Zookeeper。
Zookeeper 采用主從設計，服務集群由 Leader、Follower 和 Observer 三種角色組成，它們的職責如下：
- Leader: Zookeeper 集群使用 ZAB 協議通過 Leader 選舉從集群中選定一個節點作為 Leader。Leader 響應客戶端的讀寫請求；
- Follower：只提供數據的讀服務，會將來自客戶端的寫請求轉發到 Leader 中。在 Leader 選舉的過程中參與投票，並與 Leader 維持數據同步；
- Observer：與 Folllower 的功能相同，但不參與 Leader 選舉和寫過程的"過半寫成功"策略，單純為了提高集群的讀能力。
在 Zookeeper 集群中，由於只有 Leader 角色的節點具備寫數據的能力，當 Leader 節點宕機時，在新的 Leader 節點沒有被選舉出來之前，集群的寫能力都是不可用的。雖然 Zookeeper 保證了集群數據的強一致性，但是放棄了集群的高可用性。
對等治理設計中比較優秀的業內體現為 Netiflx 開源的 Eureka 服務注冊和發現組件。Eureka 集群由 Eureka Client 和 Eureka Server 兩種角色組成，其中 Eureka Client 是指服務實例使用的服務注冊和發現的客戶端，用於注冊和查詢服務實例信息；Eureka Server 作為服務注冊中心，存儲有各服務的實例信息列表，采用多實例的方式部署保證高可用性。每一個 Eureka Server 都是對等的數據節點，Eureka Client 可以向任意的 Eureka Server 發起服務注冊請求和服務發現請求。Eureka Server 之間的數據通過異步 HTTP 的方式同步，由於網絡的不可靠性，不同 Eureka Server 中的服務實例數據不能保證在任意時間節點都相等，只能保證在 SLA 承諾時間內達到數據的最終一致性。Eureka 點對點對等的設計保證了服務注冊與發現中心的高可用性，但是犧牲了數據的強一致性，降級為數據的最終一致性。
熔斷設計
在分布式系統中，一次完整的請求可能需要經過多個服務模塊的通力合作，請求在多個服務中傳遞，服務對服務的調用會產生新的請求，這些請求共同組成了這次請求的調用鏈。當調用鏈中的某個環節，特別是下游服務不可用時，將會導致上游服務調用方不可用，最終將這種不可用的影響擴大到整個系統，導致整個分布式系統的不可用，引發服務雪崩現象。
為了避免這種情況，在下游服務不可用時，保護上游服務的可用性顯得極其重要。對此，我們可以參考電路系統的斷路器機制，在必要的時候壯士斷腕，當下游服務因為過載或者故障不能用時，及時“熔斷”服務調用方和服務提供方的調用鏈，保護服務調用方資源，防止服務雪崩現象的出現。
斷路器的基本設計圖如下，由關閉、打開、半開三種狀態組成：
- 關閉(Closed)狀態：此時服務調用方可以調用服務提供方。斷路器中使用失敗計數器周期性統計請求失敗次數和請求總次數的比例，如果最近失敗頻率超過了周期時間內允許失敗的閾值，則切換到打開(Open)狀態。在關閉狀態下，失敗計數器基於時間周期運作，會在每個統計周期開始前自動重置，防止某次偶然錯誤導致斷路器進入打開狀態。
- 打開(Open)狀態：在該狀態下，對應用程序的請求會立即返回錯誤響應或者執行預設的失敗降級邏輯，而不調用服務提供方。斷路器進入打開狀態后會啟動超時計時器，在計時器到達后，斷路器進入半開狀態。
- 半開(Half-Open)狀態：允許應用程序一定數量的請求去調用服務。如果這些請求對服務的調用成功，那么可以認為之前導致調用失敗的錯誤已經修正，此時斷路器切換到關閉狀態，同時將失敗計數器重置。如果這一定數量的請求存在調用失敗的情況，則認為導致之前調用失敗的問題仍然存在，斷路器切回到打開狀態，並重置超時計時器來給系統一定的時間來修正錯誤。半開狀態能夠有效防止正在恢復中的服務被突然而來的大量請求再次打垮。
使用斷路器設計模式，能夠有效地保護服務調用方的穩定性，它能夠避免服務調用者頻繁調用可能失敗的服務提供者，防止服務調用者浪費 CPU 周期、線程和 IO 資源等，提高服務整體的可用性。
小結
本文主要介紹了幾種高可用的設計，除了上面介紹的方式之外，還有限流設計和一些其他設計與方案，如降級設計、無狀態設計、冪等性設計、重試設計、接口緩存、實時監控和度量以及常規划化維護。
本文分享自華為雲社區《分布式系統如何保證高可用性？(上)》，原文作者：aoho 。