系統(tǒng)可用性指標(biāo)

系統(tǒng)可用性指標(biāo)簡(jiǎn)單來講就是系統(tǒng)可用時(shí)間與總運(yùn)行時(shí)間之比

Availability=MTTF/（MTTF+MTTRMTTF）

MTTF 是 Mean Time To Failure，指平均故障前的時(shí)間，即系統(tǒng)平均能夠正常運(yùn)行多長(zhǎng)時(shí)間才發(fā)生一次故障。系統(tǒng)的可靠性越高，MTTF 越長(zhǎng)（簡(jiǎn)單理解MTTF 就是指系統(tǒng)正常運(yùn)行的時(shí)間）。MTTR 是 Mean Time To Recovery， 平均修復(fù)時(shí)間，即從故障出現(xiàn)到故障修復(fù)的這段時(shí)間，也就是系統(tǒng)不可用的時(shí)間，這段時(shí)間越短越好。系統(tǒng)可用性指標(biāo)可以用通過下表的999標(biāo)準(zhǔn)衡量，現(xiàn)在普遍要求至少2個(gè)9，最好4個(gè)9以上：

故障不可避免

高可用性是指系統(tǒng)提供的服務(wù)要始終可用，然而故障不可避免，特別是在分布式系統(tǒng)，面對(duì)不可控的用戶流量和機(jī)房環(huán)境，系統(tǒng)故障將會(huì)顯得更加復(fù)雜和不可預(yù)測(cè)。在大規(guī)模的分布式系統(tǒng)中，各個(gè)模塊之間存在錯(cuò)綜復(fù)雜的依賴，任一一個(gè)環(huán)節(jié)出現(xiàn)問題，都有可能導(dǎo)致雪崩式、多米諾骨牌式的故障，甚者可以斷言出現(xiàn)故障成了常態(tài)。

如上圖的分布式系統(tǒng)中，用戶請(qǐng)求系統(tǒng)中的某個(gè)服務(wù)接口，請(qǐng)求需要經(jīng)過長(zhǎng)長(zhǎng)的調(diào)用鏈才能處理返回。我們起碼要保證網(wǎng)絡(luò)連接正常，服務(wù)網(wǎng)關(guān)正常、前端服務(wù)正常、后臺(tái)服務(wù)正常、數(shù)據(jù)庫(kù)正常，請(qǐng)求才能被正常處理，如果調(diào)用鏈中的任一環(huán)節(jié)出現(xiàn)問題，都會(huì)直接反饋到用戶體驗(yàn)上。

系統(tǒng)出現(xiàn)故障的原因多種多樣，主要有以下這些：

網(wǎng)絡(luò)問題，網(wǎng)絡(luò)連接故障，網(wǎng)絡(luò)帶寬出現(xiàn)超時(shí)擁塞等；

性能問題，數(shù)據(jù)庫(kù)慢查詢、Java Full GC、硬盤 IO 過大、CPU 過高、內(nèi)存不足等

安全問題，被網(wǎng)絡(luò)攻擊，如 DDoS 等、異常客戶端請(qǐng)求，如爬蟲等。

運(yùn)維問題，需求變更頻繁不可控，架構(gòu)也在不斷地被調(diào)整，監(jiān)控問題等；

管理問題，沒有梳理出關(guān)鍵服務(wù)以及服務(wù)的依賴關(guān)系，運(yùn)行信息沒有和控制系統(tǒng)同步；

硬件問題，硬盤損壞、網(wǎng)卡出問題、交換機(jī)出問題、機(jī)房掉電、挖掘機(jī)問題（前一陣子機(jī)房電纜就經(jīng)常被挖斷）等；

面對(duì)如此多的天災(zāi)人禍，可控和不可控的故障因素，似乎系統(tǒng)的高可用性變成不可能完成的任務(wù)，但是在日常開發(fā)運(yùn)維中，我們可以采用一些有效的設(shè)計(jì)、實(shí)現(xiàn)和運(yùn)維手段來提高系統(tǒng)的高可用性，盡量交付一個(gè)在任何時(shí)候都基本可用的系統(tǒng)。

冗余設(shè)計(jì)

分布式系統(tǒng)中單點(diǎn)故障不可取的，而降低單點(diǎn)故障的不二法門就是冗余設(shè)計(jì)，通過多點(diǎn)部署的方式，并且最好是部署在不同的物理位置，避免單機(jī)房中多點(diǎn)同時(shí)失敗。冗余設(shè)計(jì)不僅可以提高服務(wù)的吞吐量，還可以在出現(xiàn)災(zāi)難時(shí)快速恢復(fù)。目前常見的冗余設(shè)計(jì)有主從設(shè)計(jì)和對(duì)等治理設(shè)計(jì)，主從設(shè)計(jì)又可以細(xì)分為一主多從、多主多從。

冗余設(shè)計(jì)中一個(gè)不可避免的問題是考慮分布式系統(tǒng)中數(shù)據(jù)的一致性，多個(gè)節(jié)點(diǎn)中冗余的數(shù)據(jù)追求強(qiáng)一致性還是最終一致性。即使節(jié)點(diǎn)提供無狀態(tài)服務(wù)，也需要借助外部服務(wù)，比如數(shù)據(jù)庫(kù)、分布式緩存等維護(hù)數(shù)據(jù)狀態(tài)。根據(jù)分布式系統(tǒng)下節(jié)點(diǎn)數(shù)據(jù)同步的基本原理CAP（Consistency （一致性）、Availablity （可用性）、Partition tolerance （分區(qū)容忍性）三個(gè)指標(biāo)不可同時(shí)滿足），數(shù)據(jù)強(qiáng)一致性的系統(tǒng)無法保證高可用性，最典型的例子就是 Zookeeper。

Zookeeper 采用主從設(shè)計(jì)，服務(wù)集群由 Leader、Follower 和 Observer 三種角色組成，它們的職責(zé)如下：

Leader： Zookeeper 集群使用 ZAB 協(xié)議通過 Leader 選舉從集群中選定一個(gè)節(jié)點(diǎn)作為 Leader。Leader 響應(yīng)客戶端的讀寫請(qǐng)求；

Follower：只提供數(shù)據(jù)的讀服務(wù)，會(huì)將來自客戶端的寫請(qǐng)求轉(zhuǎn)發(fā)到 Leader 中。在 Leader 選舉的過程中參與投票，并與 Leader 維持?jǐn)?shù)據(jù)同步；

Observer：與 Folllower 的功能相同，但不參與 Leader 選舉和寫過程的“過半寫成功”策略，單純?yōu)榱颂岣呒旱淖x能力。

在 Zookeeper 集群中，由于只有 Leader 角色的節(jié)點(diǎn)具備寫數(shù)據(jù)的能力，當(dāng) Leader 節(jié)點(diǎn)宕機(jī)時(shí)，在新的 Leader 節(jié)點(diǎn)沒有被選舉出來之前，集群的寫能力都是不可用的。雖然 Zookeeper 保證了集群數(shù)據(jù)的強(qiáng)一致性，但是放棄了集群的高可用性。 對(duì)等治理設(shè)計(jì)中比較優(yōu)秀的業(yè)內(nèi)體現(xiàn)為 Netiflx 開源的 Eureka 服務(wù)注冊(cè)和發(fā)現(xiàn)組件。Eureka 集群由 Eureka Client 和 Eureka Server 兩種角色組成，其中 Eureka Client 是指服務(wù)實(shí)例使用的服務(wù)注冊(cè)和發(fā)現(xiàn)的客戶端，用于注冊(cè)和查詢服務(wù)實(shí)例信息；Eureka Server 作為服務(wù)注冊(cè)中心，存儲(chǔ)有各服務(wù)的實(shí)例信息列表，采用多實(shí)例的方式部署保證高可用性。 每一個(gè) Eureka Server 都是對(duì)等的數(shù)據(jù)節(jié)點(diǎn)，Eureka Client 可以向任意的 Eureka Server 發(fā)起服務(wù)注冊(cè)請(qǐng)求和服務(wù)發(fā)現(xiàn)請(qǐng)求。Eureka Server 之間的數(shù)據(jù)通過異步 HTTP 的方式同步，由于網(wǎng)絡(luò)的不可靠性，不同 Eureka Server 中的服務(wù)實(shí)例數(shù)據(jù)不能保證在任意時(shí)間節(jié)點(diǎn)都相等，只能保證在 SLA 承諾時(shí)間內(nèi)達(dá)到數(shù)據(jù)的最終一致性。Eureka 點(diǎn)對(duì)點(diǎn)對(duì)等的設(shè)計(jì)保證了服務(wù)注冊(cè)與發(fā)現(xiàn)中心的高可用性，但是犧牲了數(shù)據(jù)的強(qiáng)一致性，降級(jí)為數(shù)據(jù)的最終一致性。

熔斷設(shè)計(jì)

在分布式系統(tǒng)中，一次完整的請(qǐng)求可能需要經(jīng)過多個(gè)服務(wù)模塊的通力合作，請(qǐng)求在多個(gè)服務(wù)中傳遞，服務(wù)對(duì)服務(wù)的調(diào)用會(huì)產(chǎn)生新的請(qǐng)求，這些請(qǐng)求共同組成了這次請(qǐng)求的調(diào)用鏈。當(dāng)調(diào)用鏈中的某個(gè)環(huán)節(jié)，特別是下游服務(wù)不可用時(shí)，將會(huì)導(dǎo)致上游服務(wù)調(diào)用方不可用，最終將這種不可用的影響擴(kuò)大到整個(gè)系統(tǒng)，導(dǎo)致整個(gè)分布式系統(tǒng)的不可用，引發(fā)服務(wù)雪崩現(xiàn)象。

為了避免這種情況，在下游服務(wù)不可用時(shí)，保護(hù)上游服務(wù)的可用性顯得極其重要。對(duì)此，我們可以參考電路系統(tǒng)的斷路器機(jī)制，在必要的時(shí)候壯士斷腕，當(dāng)下游服務(wù)因?yàn)檫^載或者故障不能用時(shí)，及時(shí)“熔斷”服務(wù)調(diào)用方和服務(wù)提供方的調(diào)用鏈，保護(hù)服務(wù)調(diào)用方資源，防止服務(wù)雪崩現(xiàn)象的出現(xiàn)。

斷路器的基本設(shè)計(jì)圖如下，由關(guān)閉、打開、半開三種狀態(tài)組成：

關(guān)閉（Closed）狀態(tài)：

此時(shí)服務(wù)調(diào)用方可以調(diào)用服務(wù)提供方。斷路器中使用失敗計(jì)數(shù)器周期性統(tǒng)計(jì)請(qǐng)求失敗次數(shù)和請(qǐng)求總次數(shù)的比例，如果最近失敗頻率超過了周期時(shí)間內(nèi)允許失敗的閾值，則切換到打開（Open）狀態(tài)。在關(guān)閉狀態(tài)下，失敗計(jì)數(shù)器基于時(shí)間周期運(yùn)作，會(huì)在每個(gè)統(tǒng)計(jì)周期開始前自動(dòng)重置，防止某次偶然錯(cuò)誤導(dǎo)致斷路器進(jìn)入打開狀態(tài)。

打開（Open）狀態(tài)：

在該狀態(tài)下，對(duì)應(yīng)用程序的請(qǐng)求會(huì)立即返回錯(cuò)誤響應(yīng)或者執(zhí)行預(yù)設(shè)的失敗降級(jí)邏輯，而不調(diào)用服務(wù)提供方。斷路器進(jìn)入打開狀態(tài)后會(huì)啟動(dòng)超時(shí)計(jì)時(shí)器，在計(jì)時(shí)器到達(dá)后，斷路器進(jìn)入半開狀態(tài)。

半開（Half-Open）狀態(tài)：

允許應(yīng)用程序一定數(shù)量的請(qǐng)求去調(diào)用服務(wù)。如果這些請(qǐng)求對(duì)服務(wù)的調(diào)用成功，那么可以認(rèn)為之前導(dǎo)致調(diào)用失敗的錯(cuò)誤已經(jīng)修正，此時(shí)斷路器切換到關(guān)閉狀態(tài)，同時(shí)將失敗計(jì)數(shù)器重置。如果這一定數(shù)量的請(qǐng)求存在調(diào)用失敗的情況，則認(rèn)為導(dǎo)致之前調(diào)用失敗的問題仍然存在，斷路器切回到打開狀態(tài)，并重置超時(shí)計(jì)時(shí)器來給系統(tǒng)一定的時(shí)間來修正錯(cuò)誤。半開狀態(tài)能夠有效防止正在恢復(fù)中的服務(wù)被突然而來的大量請(qǐng)求再次打垮。

使用斷路器設(shè)計(jì)模式，能夠有效地保護(hù)服務(wù)調(diào)用方的穩(wěn)定性，它能夠避免服務(wù)調(diào)用者頻繁調(diào)用可能失敗的服務(wù)提供者，防止服務(wù)調(diào)用者浪費(fèi) CPU 周期、線程和 IO 資源等，提高服務(wù)整體的可用性。

小結(jié)

本文主要介紹了幾種高可用的設(shè)計(jì)，除了上面介紹的方式之外，還有限流設(shè)計(jì)和一些其他設(shè)計(jì)與方案，如降級(jí)設(shè)計(jì)、無狀態(tài)設(shè)計(jì)、冪等性設(shè)計(jì)、重試設(shè)計(jì)、接口緩存、實(shí)時(shí)監(jiān)控和度量以及常規(guī)劃化維護(hù)。

原文標(biāo)題：進(jìn)來抄作業(yè)吧！分布式系統(tǒng)中保證高可用性的常用經(jīng)驗(yàn)

文章出處：【微信公眾號(hào)：華為開發(fā)者社區(qū)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯：haq