分散式系統關注點——初識「高可用」

huorongbj發表於2018-09-26

分散式

本文長度為2042字，預計讀完需1.0MB流量，建議閱讀6分鐘。
所有「」包裹的文字，只對第一次出現進行紅色高亮顯示。

咳咳，從這篇開始，正式拉開分散式系統關注點中，我認為第二重要的內容 —— 「高可用」。

本篇的要點主要是明確「高可用」的定義，以及瞭解在分散式系統下哪些環節要做「高可用」，為後續要講的策略、方式方案打下基礎。如有1年以上的分散式系統實戰經驗可酌情選擇跳過本篇。

Tips：「高XX」中的“高”其實是相對的，越滿足期望值，就越是“高”的。

一、「高可用」的作用？

首先，統一下對「高可用」的認知。

做個通俗一點的類比：獨生子女時代的子女就是“單體應用”，如果出意外了，父母就「失獨」了，整個家族的傳承就斷了，“不可用”了。然而，二胎政策就是通過分散式（冗餘）來降低出現這個問題的概率，從而提高“可用性”。

對於「高可用」，專業的解釋是：

「高可用」指的是通過儘量縮短因日常維護操作（計劃）和突發的系統崩潰（非計劃）所導致的停機時間，以提高系統和應用的可用性。
—— 百度百科

簡而言之，不管發生了什麼（哪怕是地震、洪水了），能夠讓使用者儘可能的無感知，依舊能正常使用系統，也就是越「高可用」的。

為什麼在「資料一致性」後面就聊「高可用」呢？我的理解是，分散式系統的關鍵是做冗餘，但是冗餘的最大敵人卻是「資料一致性」。我們通過冗餘打破了原先的瓶頸，開啟了一些新的通道。如，可以去爭取更高的可用性、更高的效能等等。但是這其中，屬「高可用」最重要。從上面引用中的解釋也可以看到，要想盡可能的降低停機時間，單體應用的天花板總會更快的到來。就好比讓一臺電腦永遠保持執行是困難的，期間總得更新幾次作業系統、突然出現幾次硬體故障，甚至機房的光纖被挖斷了！那麼這個時候就處於“不可用”狀態。

也因此，我認為「高可用」的價值或者說意義，必定是在我們做分散式系統獲得的其它好處之上的，比如「高效能」之類。因為，在一定範圍內，所謂的「高效能」其實通過優化單體應用也有可能達到某個期望值，但是「高可用」則必然需要依賴分散式系統才能達到。

二、如何來衡量「高可用」

一般我們講到最多的是用Service Level Agrement來衡量高可用指標，簡稱SLA。不過，其原意表示的是關於網路服務供應商和客戶間的一份合同，其中定義了服務型別、服務質量和客戶付款等術語，其中還包含除了「有效工作時間」之外的其它概念，如頻寬、服務就緒時間（RFSD）、平均故障間隔時間（MTBF）、服務平均恢復時間（MTRS）、平均修理時間（MTTR）等。最初，SLA多用於電信運營商之類的基礎設施所提供的服務中，商定使用者可以享受什麼樣的等級什麼樣的頻寬服務等等。

SLA完整的定義會複雜的多，在軟體系統中主要是取了其中的「有效工作時間」部分。只要系統一直能夠提供服務，我們就可以說系統的可用性是100%，但這隻停留在理想中。如果系統每執行100個時間單位，會有1個時間單位無法提供服務，我們說系統的可用性是99%。貼一張常見的表格圖：

▲圖片來源於網路，版權歸原作者所有

如今，我們的生活越來越依賴於移動網際網路的一些應用，假設支付寶掛了幾個小時，這下好了，刷不了卡了、轉不了帳了、信用卡也還不了了，慌不慌？

不過，相對的，還可以投機的理解為，只要我能保證系統在你使用它的時候是可用的，那麼對外宣傳也可以是「高可用」的。這也是在網際網路普及之前，很多企業的內部C/S架構的資訊系統得以正常使用的原因，比如銀行會在非營業時間更新他們的系統，所以對於服務視窗的營業員來說，系統並沒有不可用，因為那個時候我不需要用它。