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

本文長度爲2042字,建議閱讀6分鐘。所有「」包裹的文字,只對第一次出現進行高亮顯示。


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


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


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




 一、「高可用」的作用?



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

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


        對於「高可用」,專業的解釋是:


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

        —— 百度百科


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



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


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




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



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


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


99.9999.jpeg

▲圖片來源於網絡,版權歸原作者所有


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

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




 三、做「高可用」的本質



        做「高可用」用一句話來概括就是:


更快的發現故障,更快的隔離故障。


        任何對這2點有幫助的工作就是我們要做的事情。



        做任何事情都有主次之分,做高可用的“主”就是「負載均衡」。

        之前的文章中提到過多次,分佈式系統的關鍵是做冗餘,那麼讓這些冗餘能發揮「高可用」作用的就是「負載均衡」。所以,這是最基本的,也是邁向「高可用」的第一步,其它的措施都是建立在「負載均衡」之上的。


        「負載均衡」的作用是一個“連接者”,讓上下游之間以我期望的方式“連接”起來。所以,有必要先了解一下這些上下游的全貌,並且從中找到我們要做「負載均衡」的地方。


分佈式系統分層.png


        分佈式系統有各式各樣的架構方式,不過本質上都是上圖這樣的一個分層架構。圖中紅點標記出的地方就是我們需要做「負載均衡」的地方,可以看到,就是每兩層之間的連接處。

        

        這些連接處在實際做「負載均衡」的時候,需要結合所處的網絡層次。因爲在不同的網絡層次有不同的做法。如下圖。


OSI七層模型.png


        一般主流的四層負載均衡和七層負載均衡,前者指的就是傳輸層,主要涉及的協議是TCP、UDP等,後者指的應用層,主要涉及的協議是Http、Https和FTP等。

        用來實現「負載均衡」的解決方案有很多,分爲基於硬件或者基於軟件的,比較成熟的諸如:F5(支持四層、七層)、LVS(支持四層)、Nginx(支持七層)等等。


        近些年,隨着Service Mesh的興起,隨着涌現了一大批新一代的「負載均衡」解決方案,如Envoy、Istio、Linkerd、Ribbon等,有興趣的小夥伴們可以自行研究下。




 四、結語



        這篇先起個步,下篇聊聊有哪些做「負載均衡」的策略,用圖說話。





作者:Zachary(個人×××號:Zachary-ZF

×××公衆號(首發):跨界架構師。<-- 點擊查閱近期熱門文章

定期發表原創內容:架構設計丨分佈式系統丨產品丨運營丨一些深度思考

掃碼加入小圈子 ↓



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章