故障，是每個技術人都不願遇到，但卻總會遇到的事件。程式Bug、安全漏洞、駭客攻擊、伺服器當機、網路中斷等諸多因素都有可能引發系統故障，使我們的業務面臨癱瘓的窘境。這樣的例子，國內外都在不斷的發生，比如：
2020年，由於嚴重的全澳性IT故障，Coles的收銀機全部不能聯網，down機癱瘓。收銀員掃不了貨品顧客也不能結賬，澳洲每家Coles超市都被迫暫時關閉。
2018年，上海的醫療保險資訊系統就突發故障，波及上海各大醫院的結算系統，致使大量市民在就醫時無法正常使用醫保卡，眾多醫院的排隊視窗前紛紛大排長龍，場面混亂。事發之後就有不少網友質疑，涉及面如此之廣的醫保資訊系統，“難道沒有應急措施？”
這些活生生的真實案例都在提醒我們，技術賦能業務產生更高效率、獲取更多價值的同時，保障系統穩定執行也至關重要。一旦系統出現大範圍、長時間故障，致使業務中斷的後果可能直接磨滅技術賦能帶來的收益，甚至還可能帶來經濟損失、品牌受損等嚴重後果。
所以，有必要給我們的系統上一份“保險”——構建高可用的系統架構，這是每個技術團隊都在努力的核心目標。
什麼是高可用
那麼怎麼樣的系統是否具備高可用能力的呢？我認為主要考量兩個方面：容錯與容災。
容錯能力指的是當故障來臨時，業務系統是否可以不中斷，繼續服務的能力。常規措施就是叢集化部署，同樣業務的應用部署多臺伺服器，即時有個別服務壞了，其他服務依然可以提供業務支援。這就像飛機配置多臺引擎一樣，即時有一臺壞了，剩下的依然可以支撐它飛行到指定地點安全著陸。
容災能力指的是當重大災難來臨時，容錯能力已經全部失效了，但我們依然有能力透過一些手段讓業務重新恢復。常規措施就是備份，當某個機房發生了嚴重的故障，所有伺服器都無法正常工作了，但資料備份還在，那我們就可以重新載入它們並讓系統重新執行起來。這就好比飛機上的引擎全部壞了，但為了保證飛行任務以後還能執行，必須提供保護飛行員逃生的裝置，比如透過彈射跳傘的方式令其可以倖存下來，之後又繼續再其他飛機上繼續執行任務。
高可用系統的構建準備
首先，在構建高可用系統之前，我們要對故障有幾個基本的認識：沒有任何一個設施是100%安全可靠的。所以，一個系統在設計高可用架構的時候，複雜度隨涉及的設施的數量增多而變高。
其次，我們需要儘可能的精簡運維體系。簡單的說，上雲是大部分企業的最佳選擇。除非自身團隊在同預算的情況下，能夠在基建維護上達到相同乃至更高的可用性。不然你機房建設、伺服器、網路等基礎設施的維護可能都將要你半條命。
再者，必須平常心對待可用性保障，這個道理就不多說了。意外總是在發生，翻翻過去的那些故障，是不是都還歷歷在目：
2022年6月，Cloudflare的意外中斷導致大量熱門網站訪問出現問題
2021年12月，AWS大面積故障導致大量網站無法服務，亞馬遜電商也遭受重創2021年5月，IBM Cloud在短短5天裡連續發生兩次嚴重的中斷事故
2020年3月，Google Cloud多個地區的雲服務癱瘓，時間長達14小時
2019年2月，Google Cloud因光纖受損出現網路問題，時間長達10小時
2018年4月，Azure因受雷雨天氣影響導致電壓激增而中斷服務，時間長達28小時
但是。正因為沒有100%的無故障，我們才要用高可用，因為這是唯一挽救你造成巨大財產損失的機會。
最後，我們不得不正視一個雲服務使用者的常見誤區。當我們選擇雲服務商的時候，需要明確雲廠商到底給我們提供了哪些高可用能力，而剩下的高可用能力覆蓋是需要我們自己設計和實現的。我們要知道，一個高可用系統的構建是貫穿基礎設施、中介軟體、服務端、客戶端等多方面的。對穩定性高度敏感的企業一定要平常心看待故障 ，用好高可用。
（下圖展示了雲服務廠商和使用者的高可用上的責任模型：雲服務商提供的主要是基礎硬體服務的高可用能力。而我們之前所提到的業務容錯（負載架構）、容災（保障資料備份）能力都是在使用者側的。供參考）
所以，如果在上雲的時候，對自身業務系統不做額外的高可用保障，那就很可能出現文章開始我們提到的那些業務窘境。
總結
今天跟大家聊了聊系統上雲時，容易被忽略的高可用問題，以及如何做好雲上高可用架構的方法。對此你有什麼想法呢？留言區一起聊一聊。
歡迎關注我的公眾號：程式猿DD。第一時間瞭解前沿行業訊息、分享深度技術乾貨、獲取優質學習資源