剛剛，一個身在迪拜的朋友在群里吐槽：說是某云的阿聯酋機房故障后，影響挺大，很多網銀不能用了。

于是，又是一番熱烈的討論。

這種“宕機”，大家也不是頭一次見識了（雖然這次的原因比較特別）。

無論是不可抗力還是人為因素，全球頭部的云大廠們，幾乎都輪番宕機上過熱搜……

每到此時，關于高可用啊、SLA啊、上云不如自建穩啊，這類爭論就會此起彼伏。

其實，每一次大規模宕機，都是偶然中的必然！

今天，我們就舊文重發，再次講講“明明上了「高可用」還會宕機？我們對IT「高可用」，都有哪些誤解？”

01 /到底什么是高可用

高可用，High Availability，有人也縮寫成HA。

其實就是通過各種可靠性的設計，把一個系統不能正常提供服務的幾率降到最低。

拿上面自貿區網站停擺來舉例，如果有個影子版的「網站鏡像」始終在旁邊其他可用區候著，發現“正主兒”宕機以后，它立馬無縫接管，訪問不受任何影響（換成網銀也一樣，但網銀設計會更復雜寫，對一致性要求更高）。

這，就是所謂「高可用」了。

但是，需要提醒大家一點，高可用≠100%無故障。

無論我們如何未雨綢繆，如何進行各種冗余設計，宕機的概率依然存在。

所以我們會看到任何系統、任何云服務，給出的SLA，都是多少個9（比如99.9999%），但從來沒人承諾100%。

02 /為什么需要高可用

高可用是一項系統性工程。

拿在線式的軟件服務為例：網絡、主機、存儲、系統、軟件，以及相關聯的數據庫、API、各種組件，甚至托管機房的風火水電，都是影響最終高可用結果的因素。

既然是系統性工程，涉及到這么多方方面面，每個環節都要考慮周全，也就意味著更高的成本。

所以，高可用送給你的每個9背后，都暗中標好了價格

既然這么費錢，那么追求高可用的道路上，就應該適可而止，夠用就好。

第一，從實際業務需求出發，來評估具體的可用性指標，業務連續性要求高的，就必須要“卷”起來。

第二，根據行業監管要求，達成相應的合規標準。

比如針對銀行，就會有類似于《銀行業信息系統災難恢復管理規范》（JR/T 0044—2008）的監管規定，要求必須達到對應的高可用級別。

所以，對高可用指標的追求，往往都是掂量著業務需求+監管需求，再加上自己口袋里的money，最終得到的一個平衡結果。

講真，今天群里小伙伴說自貿區官網打不開了還好理解，但許多網銀都不能用了，無論從業務還是監管，都有點太草率了。

03/如何進行高可用架構設計

如果已經明確了高可用的需求，那么接下來就要深入了解下，高可用設計，具體應該咋么整？

通常，高可用設計應該遵循6大原則↓

? 少依賴原則

顧名思義，就是在高可用系統設計的時候，應當盡可能減少不同組件之間的依賴關系。

彼此獨立，能不依賴的，盡可能不依賴，越少越好。否則，一個組件掛掉，整個系統就可能“兵敗如山倒”。

比如，一個多依賴系統，是這樣的↓

一個少依賴系統，是醬嬸兒的↓

? 弱依賴原則

一定要依賴的，盡可能弱依賴，越弱越好。

如果組件A強依賴組件B，一旦B掛了，A也會翻車，反過來也一樣。所以任何強依賴要盡可能轉化為弱依賴，從而降低“翻車”的概率。

? 分散原則

化整為零，打散成N份，從而分散風險，避免把雞蛋放在一個籃子里，一損俱損。

比如設計數據庫的時候，不要所有的交易數據都放在同一個庫的同一個表里，萬一庫掛了，就意味著所有交易都停擺。

另外，更典型的還有多AZ設計，多云架構，以及大家最經常聽到的異地容災架構，這些，都是在遵循分散原則。

? 均衡原則

在打散拆分成N份的前提下，還要盡可能保證每份都是均衡的，這樣風險也被均勻分擔，避免某份的權重過大，造成影響的范圍過大。

? 無單點原則

要有冗余設計，以免出現問題無路可退。

比如支持切換、擴容等策略，鏈路故障時可以切換到新鏈路上，主機故障時可以切換到新擴容的機器上。

再比如支持回滾機制，某個操作失敗后，可以回滾到上個版本，避免在錯誤的道路上越走越遠，無法收拾殘局。

? 自保護原則

一旦出現極端情況，要果斷「丟車保帥」，犧牲不重要的部分，保護重要的部分。

比如CPU過熱保護，也可以看做是類似這樣的機制，系統在檢測到CPU溫度過高后，自動降頻，雖然整體處理性能下降了，卻不至于完全宕機。

除了這些基礎的設計原則需要遵循，還有一個簡單粗暴的硬道理↓

公有云相比私有云、IDC托管、傳統IT架構等等，天然更具備高可用的“潛質”。

首先，云計算的基因就是分布式的，跟傳統集中式架構比拼RAS指標、用昂貴的硬件系統來提升高可用的思路完全不同。

云計算把硬件故障當做“常規事件”，通過分布式架構來降低依賴、分散和均衡風險、消除單點并提供保護機制。

第二，同樣都叫「云計算」，公有云相比私有云、本地虛擬化資源池，可以通過超大規模的資源優勢，不斷堆buff，堆出更好的伸縮性，遭遇極端場景時，具備更好的高可用潛質。

第三，公有云在底層基礎設施層面，通過選址、數據中心級別（風火水電）、多線網絡、多DC、多AZ、多區域，各種未雨綢繆，具備更耐折騰的高可用底盤。

所以，當遇到高可用的需求時，優先選擇上云，一般可以達到事半功倍的效果。

換句話說，如果想要同樣的SLA，對用戶來講，云下的成本要遠高于云上。

04 /為啥我上了云，還是掛了？

雖然我說公有云“天然高可用”，但吃瓜群眾說“你看你看，常有云宕機上熱搜！”

首先明確一點，相比云下IT系統成天此起彼伏故障，云宕機其實是小概率事件，只不過云宕機更具新聞性，所以幾大頭部云商但凡有點風吹草動，行業里就會草木皆兵。

第二，上了云，不等于宕機的鍋就可以完全甩給云服務商了，云用戶和云服務商需要權責明確，責任共擔。

前面我們說過，高可用是一個系統性工程，涉及到服務邊界的問題，云服務商沒法成為云保姆，大包大攬把所有的事情都兜底。

如果「成熟」的云服務商和云用戶，都能把各自的“門前雪”掃干凈，那么，云上高可用的效果，就可以發揮到極致。

既然話說到這個份上了，我們就要搞清楚，作為云用戶，云上有幾大雷區必須要規避，否則可能「上線一時爽，宕機火葬場」

? 如果業務需要高可用，一定要在采購之前就設計好高可用架構，無論是線下的IDC還是正經公有云產品，都需要提前設計，一旦部署了業務再回頭想要高可用，改造起來可就傷筋動骨了。

? 為了確保整體的可用性，每一個環節都得具備高可用，一個組件出了問題就可能前功盡棄。

? 在使用云廠商或托管服務之前，要提前調查好各項功能的兼容性和需求是不是匹配，比如權限管理等。

? 明確云廠商提供產品的可用區，很多云廠商提供了多可用區災備能力，但也有少數產品因為性能等原因只支持單AZ。

? 架構的設計和交付務必要對齊，效果圖和施工落地不一致的慘案太多太多了。

? 業務軟件盡量做到無狀態，這樣可以利用云服務的多AZ算力及支持多AZ的PaaS產品，在不大幅增加成本的情況下，支持業務跨可用區的容災能力。

? 單元化設計，確保一次用戶請求能夠在一個可用區完成閉環，不要跨可用區。

05 /典型云上高可用，長啥樣

我們來看個實際的例子吧，底層咱不說了，云服務商已經幫你把坑填完了，只看用戶側如何填坑↓

先看錯的，這是一個典型的「偽高可用」，各種組件看著都是冗余的，但是卻忽略了一個最重要的地方，那就是所有的雞蛋都在一個籃子里（單可用區架構）。

這種設計，看似做足了功夫，可一旦“可用區不可用”，高可用設計立馬失效。

所以，正確的云上高可用設計，一定要把云的優勢能用盡用，云的羊毛能薅盡薅…

比如，把上面的設計重來一遍，全部更改為多AZ模式，SLB主備設計，前端業務集群雙AZ，緩存、數據庫也選雙AZ版本，文檔存儲選3AZ高可用。

這樣的高可用設計，就是相對靠譜的，單個AZ故障，不會讓業務到任何影響。

當然，還要注意高可用設計和實際交付要對齊，比如設計的時候數據庫是跨區高可用，交付的時候卻買了單AZ版本，購買對象存儲的時候，思想開了個小差，本來該選3AZ版本，卻點了單AZ版本。

一個小環節的疏漏，就能讓“千里之堤潰于蟻穴”了。

再比如把計算資源和PaaS類服務（RDS等）整到了不同的可用區。

這樣，用戶的一次請求無法在一個AZ形成閉環，要跨可用區調用，既讓性能打折，還增加了故障概率（任何一個可用區停擺，業務就會掛掉。）

所以，有些云大廠雖然不做“云保姆”，但還是盡可能幫用戶“避坑”，比如提供一些專業的可視化設計部署平臺。

基于這樣的平臺，云用戶在規劃階段做好高可用設計，并在部署時進行一致性檢查，徹底解決設計與交付脫節的問題。

06 /如果必須專有云，該咋整

現在大家都知道了關鍵點：上云更容易實現高可用，建設更簡單，TCO更低。

遺憾的是，確實還有很多場景因為監管、合規等問題，暫時不能上云。

此時如果要建設高可用怎么辦？?根據業務屬性合理分級。?低等級就適當降低標準。?高等級就付出更多成本。

高可用級別與成本之間成正比，所以，根據業務屬性，合理設定可承受的風險范圍+對業務恢復時間的要求，是彈性/韌性受限的專有云場景建設高可用的關鍵。

本地冗余架構：可以接受機房級風險，在單一主機、網絡、系統、服務故障時，可以快速恢復業務。

同城容災架構：可以接受區域級風險，但是在機房級風險發生時，能快速恢復業務。

異地容災架構：除了能承受機房級風險，還要能承受區域級風險，但對快速恢復業務需求不強。

兩地三中心架構：除了能承受機房級風險，還要能承受區域級風險，同時對快速恢復業務也有強需求。

小結一下：

?高可用不等于100%可用，高可用級別跟付出的成本成正比；

?先評估業務卷到什么程度，再決定高可用卷到什么程度；

?上云仍是建設高可用的捷徑，云上高可用的TCO成本更低；

?但云上高可用和云上安全類似，要注意責任共擔模式，并要做到設計和交付對齊。

最后，祝大家永不宕機