最近一段時間以來，ChatGPT 火遍全球，然而在飛速的用戶增長下，ChatGPT 卻有點不堪重負，兩天內宕機了五次。

這次宕機事件，再一次凸顯了高可用架構的重要性，畢竟任何一個飛速發展的應用在兩天內宕機五次，所帶來的損失都是難以接受的。

如果說 ChatGPT 還是由于請求量激增導致的服務不穩定，那么以下幾個案例就是純粹的基礎設施沒做好而導致的服務宕機了：

2021年8月31日，美國在線辦公軟件 Notion 在全球范圍內出現宕機。

2021年6月17日，美國在線協作工具 Figma 在全球范圍內出現宕機。

2021年3月9日，全球最大的代碼托管平臺 GitHub 在全球范圍內出現宕機。

它們事后都在推特上披露了事故原因，都是因為數據庫/數據中心發生不穩定而導致的宕機事件，應用服務的基礎設施穩定性、可用性再一次成為大型宕機事故的高發原因。

尤其是在 2023 年的現在，互聯網已經成為了無處不在的基礎設施，和電力一樣成為了現代人生活中不可或缺的一部分，任何一個公司的應用如果發生了宕機事件都有可能失去在互聯網發展的契機，因為對于用戶來說，幾乎每個賽道都有替代品，你的應用在我需要使用的時候出問題了，或許我轉頭就卸載下載競品了。

所以現在的公司都在做應用的時候也都會非常關注應用架構，稍微大一點的公司或者是有長遠發展的規劃的公司，都會上云做一套高可用架構以保證突發情況能夠順利度過。

這就像你開車出門沒買交強險，不小心追尾奔馳了，本來提前買保險2000塊錢就能解決的事，這下子可能得花兩萬塊錢才能解決，如果你再不幸一點，追尾了法拉利那可能得花二十萬才能解決了。

無論哪種情況都遠超你當初的提前投入。

那么，云廠商的高可用架構到底有什么優勢能如此強大呢？

什么是高可用架構

在回答云上高可用架構之前，我們先來說說高可用架構。

高可用架構是指設計具有高度可靠性、穩定性、可擴展性和容錯性的軟件系統，以確保系統在面對大量請求和異常情況時能夠保持穩定的性能和可用性。

下圖是一個簡化版的軟件架構發展歷程圖：

img

這張圖大致將軟件架構分為三個階段：

單實例階段：這個階段用戶量較少，數據庫與應用都部署在同一臺服務器上，數據庫或者服務器網絡分區出現問題，都會導致應用不可用。

單區高可用階段：這個階段服務器和數據庫都已經集群化，集群中的機器分布在一個大區的不同機房中，集群中的任何一個機器發生問題，都不會影響整體的應用可用性，但是它們整體還是處在同一個區域的數據中心，所以這種方案也可以被稱之為同城雙活。

多區高可用階段：多區高可用是在單區高可用的基礎上將機房擴大到多個大區中，比如華東大區和華南大區，每個大區都要一整套完整的服務集群，大區與大區之間通過專線進行數據同步，這種設計可以在某個大區故障時立即切換流量到另一個大區，這個方案也是大家俗稱異地多活。

越高級的架構抵御風險的能力越強，就像你家的房子（單實例）只能抗5級地震，但是別人家的房子（多區高可用）是為抗震單獨設計過的，真到地震來了別人家的房子可以在八級地震下依然完好無損，這就是高可用的優勢。

說到這，好像很多人會把高可用和高可靠傻傻分不清，那我就舉一個例子來說明他倆的區別：

如果一個系統在每小時奔潰1ms，那么它的可用性超過99.9999%，但它是高度不可靠的。

如果一個系統從來不崩潰，但是每年要停機兩星期保養，那它是高度可靠的，但是可用性只有96%。

在現代應用系統中，造成高可靠下降的因素多是不可抗力，所以都著力保障高可用優先，對于真正的 C 端客戶來說，其實高可用和高可靠就是一回事，就是無論什么時候、出現什么情況，服務都能照常使用。

一般來說，傳統的高可用的架構主要從以下四個方面來保證服務的高可用：

負載均衡：通過使用負載均衡器（如SLB，一般是 NGINX 集群）對多臺服務器進行流量分發，可以提高系統的性能、擴展性和容錯性。

冗余備份：通過使用多可用區、多機房、多地域等方式，可以實現數據和服務的冗余備份，以防止單點故障或災難恢復，這在遇到不可抗因素時（區域網絡斷網、地震）極其重要。

服務降級：通過使用熔斷器、限流器、降級器等技術，可以實現服務的降級處理，以保證核心功能的正常運行，避免雪崩效應。

監控報警：通過使用監控系統（如Prometheus）和報警系統（如Alertmanager）對系統的各個指標進行實時監控和異常報警，可以及時發現和解決問題，提高系統的穩定性。

以上只是傳統高可用架構的優勢，但是現在的高可用架構基本都會上云，云上高可用架構比之傳統高可用就又多了幾個優勢。

云上高可用架構

動態擴容

動態擴容是云廠商的一個重磅功能，它可以讓你在極短的時間內快速部署大量應用以應對用戶的快速增長。

假如你是一個小鎮青年，花費三年心血推出一款產品，一經上市便被用戶自發傳播，用戶量呈指數級上升，或許再過不久你即將走上人生巔峰，但是因為用戶量的激增你的服務器資源與數據庫資源天天告警，因為資源的不足，用戶使用起來也越來越卡，競品公司看到你的產品這么火，馬上抄了一個，已經投入了市場開始推廣。

此時如果你的應用上云了，那么你可以：登錄你的云服務賬號，揮動鼠標點擊幾下擴容，將服務器和數據庫資源瞬間擴大 N 倍，保證用戶的體驗，避免用戶流失。

img

甚至你都不需要自己去處理擴容問題，如上圖所示，現在的云廠商都支持預設擴容規則，當服務器壓力達到你設置的一定條件后可以自行進行擴容，這樣你就不必在深夜被服務器報警吵醒。

此時如果你的應用沒上云，那么你可以：趕緊買一臺高性能服務器并且搭建環境，然后把應用在新的服務器上也部署一份，并且發布到測試環境開始調試，最后提心吊膽發布上線，這么一折騰可能半個月就過去了，用戶也被競品吸引走了，走上人生巔峰的夢想也破滅了。

數據安全

除了動態擴容之外，云服務廠商的數據安全也普遍更靠譜一些，云廠商不光采用最頂級的硬件，還采用一套復雜的軟件系統來為數據提供：快照、備份和加密的功能。

img

有了云服務廠商給的這套數據安全基礎之后，本來需要自己操心的數據安全性則完全可以放給云服務廠商來處理了，專注于業務。

便利性

便利性可以指很多方面，其中最大的便利性當屬空間方面的便利性，比如當我們要做異地多活的時候，往往需要多地、多機房進行部署應用。

如果你處在特殊行業，國家明確規定相關行業要每年至少進行一次容災演練，對于這種行業的容災架構來說，異地多活幾乎是或不可缺的。

img

如果你沒上云，那每次開辟一個新機房都要派一批人去另一個城市租用別人的機房，然后再重新搭建一套與現有的機房相兼容的生產環境，并且還要提心吊膽的進行大量測試才能投入使用。

而且現在出海是很多企業嘗試的一個方向，出海應用則不可能將服務器部署在國內，為了速度考量往往都是部署在當地的機房，這時候云廠商的便利性就又體現出來了，在全球的特大城市都有機房存在，無論你想在哪部署你的應用，只要在電腦上就能操作完成。

穩定性

說到底，穩定性才是云廠商的最大優勢，云廠商一般提供存儲、數據庫、計算和網絡這些基礎設施，由于云廠商具有大量的用戶，大量的應用部署在云上， 所以他們對于這些基礎設施本身就有一套高可用的架構在支撐，而且這些基礎設施在大量用戶的考驗之下也逐漸堅如磐石。

像做應用常用的兩個組件：存儲中心和數據庫，如果你自己搭建往往需要自己再給他們做一套高可用方案，畢竟這兩個部分可謂說是系統的基石存在，如果你直接使用云服務廠商的這些設施，不光實現了穩定性還節省了大量的成本。

云上高可用，就萬無一失了嗎

雖然云上高可用，已經對我們的應用做了很多的保護措施，但是作為使用者來說，你仍然需要在設計高可用架構的時候遵循一些原則，遵循以下這些原則可以讓你的應用更健壯，抗風險能力更加強。

在設計高可用架構時，需要遵循以下原則：

分布式：采用分布式系統架構可以將負載分散到多個服務器上，提高系統的容錯性和可用性，比如你有一個訂單服務集群，那么你可以把這個集群分布在不同的服務器上，而非同一臺服務器。分布式架構不單指將應用分開部署，還有使用的一些基礎設施比如數據庫、緩存中間件也盡量使用分布式組件，利于日后擴展。

多活：多活架構意味著系統中有多個獨立的節點，每個節點都可以處理請求。這種架構可以減少單點故障的影響，提高系統的可用性。比如你有一個訂單服務的集群，在部署的時候盡量在多地部署，比如北京、上海、成都各一臺，這樣可以在某個區域的所有服務器都出現問題的時候利用其他區域的服務器繼續提供服務。

自動化運維：采用自動化運維工具可以幫助系統自動檢測和恢復故障，降低故障處理時間，提高系統的可用性。比如發版時可以進行灰度發版，發版出現問題時可以通過版本管理快速回滾到上一個版本等。

弱依賴：弱依賴原則是指服務模塊之間應該盡可能地減少依賴關系，使得系統中的各個模塊能夠獨立地進行開發、測試、部署和維護。這樣可以提高系統的可維護性和可擴展性，降低模塊之間的耦合度，減少系統中出現的意外行為和故障。比如我們有購物車和訂單兩個模塊，只要不是強依賴，購物車模塊出現問題是不會影響到訂單服務的，繼而也不會影響用戶的下單操作。

自我保護：在軟件設計中，系統應該具備自我保護的能力，能夠自動檢測和修復錯誤，從而避免系統因錯誤而導致的崩潰或無響應情況。同時應用在極端情況下應該能自我降級，通過返回大量的降級響應而避免上層應用被拖垮。

以上五條，就是我在多年開發經驗中總結出的高可用設計中需要遵循的一些原則，大家可以將其實際應用到工作中去，相信一定會取得不錯的效果。

如果你已經做好了云上高可用架構，依然發生了應用崩潰情況，那么你和云服務廠商之間，究竟應該誰來負責呢？

我的應用宕機了，云服務廠商應不應該負責？

對于這個問題，其實業內云廠商有一個通行的安全責任劃定表，對用戶與云廠商做出了清晰的責任劃分：

img

從上圖可以看到，云服務廠商主要負責的部分是硬件設施，如果硬件出現了問題導致了客戶的應用出現問題，那么云服務廠商是應該承擔責任的。

比如在 2022年1月，谷歌云在美國東部地區出現了大規模的網絡故障，導致谷歌云上的數千個網站和應用程序無法正常訪問。該網絡故障是由于谷歌云的網絡設備出現了故障所致，導致一些客戶的數據流無法正常傳輸。

為此，谷歌云向受影響的客戶提供了一定的賠償方案，具體賠償方案包括：為使用受影響的谷歌云服務的客戶提供一定比例的服務費用折扣，并在必要時進行賠償。

所以，即使是云上高可用架構方案，也不可能保證 100% 的可靠性。

不過這種情況在現實生活中也是極少數案例，大部分的事故宕機還是由于網站管理員誤操作引起的問題，比如：

2019年11月19日，GitHub 因為一名員工在執行一個數據庫清理腳本時不小心刪除了一個生產數據庫集群的主節點，導致該集群不可用，持續了43分鐘。

2019年7月2日，Facebook、Instagram和WhatsApp因為一名員工在配置數據庫時誤刪了一些關鍵數據，導致這三個平臺的服務不可用，持續了約8小時。

2018年7月3日，GitLab 因為一名員工在執行一個數據庫遷移任務時誤刪了一個PostgreSQL數據庫中的重要表，導致 GitLab 服務不可用，持續了約30分鐘。

這些誤操作事故看起來都很好恢復，但是因為沒有備份機制，導致事故造成影響的時間比較長，如果它們使用的是云數據庫或者具有多活節點，其實都不會發生這么大的影響，最多幾分鐘服務就恢復了。

畢竟云服務提供商通常擁有完善的數據備份和容災機制，包括地理上的備份和異地多活架構等，可以有效地應對各種災害和數據安全風險。

而且云服務提供商通常會提供自動化、智能化的容災解決方案，能夠快速檢測和響應各種故障和安全事件，提供快速恢復的服務，保障企業的業務連續性和數據安全。

所以大家在架構設計階段時，就要時刻考慮我上面所提到的五個原則，一個合格的高級開發人員，應該在開發過程中就預想過各種各樣的場景，并對這些場景做出一定的準備工作，這樣才能最大程度上保證自己的應用不出問題。

良好的設計原則 + 強大的云上高可用架構與云上運維工具，可以讓我們在遇到事故問題時做到游刃有余。

總結

今天主要給大家帶來了云上高可用架構的內容，主要帶大家詳細了解了云上高可用架構的優勢以及上云的必要性。

同時上云雖然有諸多般好處，但是也不可能保證 100% 的可靠性，但是雖然上云不能保證 100% 的可靠性，還是有大量大廠、小廠趨之若鶩的進行上云。

他們用實際行動告訴了我們，上云的好處多于壞處，2023 年是中國提振中國經濟的一年，如果你心底也在考量要不要上云，我覺得可以先進行一部分業務的搬遷工作，體驗一下云計算便利性再說。

畢竟，未來，一定是云計算的時代。

審核編輯 ：李倩