故障，是每個技術人都不愿遇到，但卻總會遇到的事件，程式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，第一時間了解前沿行業訊息、分享深度技術干貨、獲取優質學習資源
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/547756.html
標籤：Java
上一篇：布隆過濾器