本文長度為2042字，建議閱讀6分鍾。所有「」包裹的文字，只對第一次出現進行高亮顯示。
閱讀目錄
咳咳，從這篇開始，正式拉開分布式系統關注點中，我認為第二重要的內容 —— 「高可用」。
本篇的要點主要是明確「高可用」的定義，以及了解在分布式系統下哪些環節要做「高可用」，為后續要講的策略、方式方案打下基礎。如有1年以上的分布式系統實戰經驗可酌情選擇跳過本篇。
Tips：「高XX」中的“高”其實是相對的，越滿足期望值，就越是“高”的。
一、「高可用」的作用？
首先，統一下對「高可用」的認知。
做個通俗一點的類比：獨生子女時代的子女就是“單體應用”，如果出意外了，父母就「失獨」了，整個家族的傳承就斷了，“不可用”了。然而，二胎政策就是通過分布式（冗余）來降低出現這個問題的概率，從而提高“可用性”。
對於「高可用」，專業的解釋是：
「高可用」指的是通過盡量縮短因日常維護操作（計划）和突發的系統崩潰（非計划）所導致的停機時間，以提高系統和應用的可用性。
—— 百度百科
簡而言之，不管發生了什么（哪怕是地震、洪水了），能夠讓用戶盡可能的無感知，依舊能正常使用系統，也就是越「高可用」的。
為什么在「數據一致性」后面就聊「高可用」呢？我的理解是，分布式系統的關鍵是做冗余，但是冗余的最大敵人卻是「數據一致性」。我們通過冗余打破了原先的瓶頸，打開了一些新的通道。如，可以去爭取更高的可用性、更高的性能等等。但是這其中，屬「高可用」最重要。從上面引用中的解釋也可以看到，要想盡可能的降低停機時間，單體應用的天花板總會更快的到來。就好比讓一台電腦永遠保持運行是困難的，期間總得更新幾次操作系統、突然出現幾次硬件故障，甚至機房的光纖被挖斷了！那么這個時候就處於“不可用”狀態。
也因此，我認為「高可用」的價值或者說意義，必定是在我們做分布式系統獲得的其它好處之上的，比如「高性能」之類。因為，在一定范圍內，所謂的「高性能」其實通過優化單體應用也有可能達到某個期望值，但是「高可用」則必然需要依賴分布式系統才能達到。
二、如何來衡量「高可用」
一般我們講到最多的是用Service Level Agrement來衡量高可用指標，簡稱SLA。不過，其原意表示的是關於網絡服務供應商和客戶間的一份合同，其中定義了服務類型、服務質量和客戶付款等術語，其中還包含除了「有效工作時間」之外的其它概念，如帶寬、服務就緒時間（RFSD）、平均故障間隔時間（MTBF）、服務平均恢復時間（MTRS）、平均修理時間（MTTR）等。最初，SLA多用於電信運營商之類的基礎設施所提供的服務中，商定用戶可以享受什么樣的等級什么樣的帶寬服務等等。
SLA完整的定義會復雜的多，在軟件系統中主要是取了其中的「有效工作時間」部分。只要系統一直能夠提供服務，我們就可以說系統的可用性是100%，但這只停留在理想中。如果系統每運行100個時間單位，會有1個時間單位無法提供服務，我們說系統的可用性是99%。貼一張常見的表格圖：
▲圖片來源於網絡，版權歸原作者所有
如今，我們的生活越來越依賴於移動互聯網的一些應用，假設支付寶掛了幾個小時，這下好了，刷不了卡了、轉不了帳了、信用卡也還不了了，慌不慌？
不過，相對的，還可以投機的理解為，只要我能保證系統在你使用它的時候是可用的，那么對外宣傳也可以是「高可用」的。這也是在互聯網普及之前，很多企業的內部C/S架構的信息系統得以正常使用的原因，比如銀行會在非營業時間更新他們的系統，所以對於服務窗口的營業員來說，系統並沒有不可用，因為那個時候我不需要用它。
三、做「高可用」的本質
做「高可用」用一句話來概括就是：
更快的發現故障，更快的隔離故障。
任何對這2點有幫助的工作就是我們要做的事情。
做任何事情都有主次之分，做高可用的“主”就是「負載均衡」。
之前的文章中提到過多次，分布式系統的關鍵是做冗余，那么讓這些冗余能發揮「高可用」作用的就是「負載均衡」。所以，這是最基本的，也是邁向「高可用」的第一步，其它的措施都是建立在「負載均衡」之上的。
「負載均衡」的作用是一個“連接者”，讓上下游之間以我期望的方式“連接”起來。所以，有必要先了解一下這些上下游的全貌，並且從中找到我們要做「負載均衡」的地方。
分布式系統有各式各樣的架構方式，不過本質上都是上圖這樣的一個分層架構。圖中紅點標記出的地方就是我們需要做「負載均衡」的地方，可以看到，就是每兩層之間的連接處。
這些連接處在實際做「負載均衡」的時候，需要結合所處的網絡層次。因為在不同的網絡層次有不同的做法。如下圖。
一般主流的四層負載均衡和七層負載均衡，前者指的就是傳輸層，主要涉及的協議是TCP、UDP等，后者指的應用層，主要涉及的協議是Http、Https和FTP等。
用來實現「負載均衡」的解決方案有很多，分為基於硬件或者基於軟件的，比較成熟的諸如：F5（支持四層、七層）、LVS（支持四層）、Nginx（支持七層）等等。
近些年，隨着Service Mesh的興起，隨着涌現了一大批新一代的「負載均衡」解決方案，如Envoy、Istio、Linkerd、Ribbon等，有興趣的小伙伴們可以自行研究下。
四、結語
這篇先起個步，下篇聊聊有哪些做「負載均衡」的策略，用圖說話。
作者：Zachary
出處：https://zacharyfan.com/archives/416.html
▶關於作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎掃描右側的二維碼~。
定期發表原創內容：架構設計丨分布式系統丨產品丨運營丨一些思考。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「跨界架構師」，回復「技術」，送你一份我長期收集和整理的思維導圖。
如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公眾號「跨界架構師」，回復「運營」，送你一份我長期收集和整理的思維導圖。