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

這次宕機事件，再一次凸顯了高可用架構(gòu)的重要性，畢竟任何一個飛速發(fā)展的應(yīng)用在兩天內(nèi)宕機五次，所帶來的損失都是難以接受的。

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

2021年8月31日，美國在線辦公軟件 Notion 在全球范圍內(nèi)出現(xiàn)宕機。

2021年6月17日，美國在線協(xié)作工具 Figma 在全球范圍內(nèi)出現(xiàn)宕機。

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

它們事后都在推特上披露了事故原因，都是因為數(shù)據(jù)庫/數(shù)據(jù)中心發(fā)生不穩(wěn)定而導致的宕機事件，應(yīng)用服務(wù)的基礎(chǔ)設(shè)施穩(wěn)定性、可用性再一次成為大型宕機事故的高發(fā)原因。

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

所以現(xiàn)在的公司都在做應(yīng)用的時候也都會非常關(guān)注應(yīng)用架構(gòu)，稍微大一點的公司或者是有長遠發(fā)展的規(guī)劃的公司，都會上云做一套高可用架構(gòu)以保證突發(fā)情況能夠順利度過。

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

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

那么，云廠商的高可用架構(gòu)到底有什么優(yōu)勢能如此強大呢？

什么是高可用架構(gòu)

在回答云上高可用架構(gòu)之前，我們先來說說高可用架構(gòu)。

高可用架構(gòu)是指設(shè)計具有高度可靠性、穩(wěn)定性、可擴展性和容錯性的軟件系統(tǒng)，以確保系統(tǒng)在面對大量請求和異常情況時能夠保持穩(wěn)定的性能和可用性。

下圖是一個簡化版的軟件架構(gòu)發(fā)展歷程圖：

img

這張圖大致將軟件架構(gòu)分為三個階段：

單實例階段：這個階段用戶量較少，數(shù)據(jù)庫與應(yīng)用都部署在同一臺服務(wù)器上，數(shù)據(jù)庫或者服務(wù)器網(wǎng)絡(luò)分區(qū)出現(xiàn)問題，都會導致應(yīng)用不可用。

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

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

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

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

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

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

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

一般來說，傳統(tǒng)的高可用的架構(gòu)主要從以下四個方面來保證服務(wù)的高可用：

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

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

服務(wù)降級：通過使用熔斷器、限流器、降級器等技術(shù)，可以實現(xiàn)服務(wù)的降級處理，以保證核心功能的正常運行，避免雪崩效應(yīng)。

監(jiān)控報警：通過使用監(jiān)控系統(tǒng)（如Prometheus）和報警系統(tǒng)（如Alertmanager）對系統(tǒng)的各個指標進行實時監(jiān)控和異常報警，可以及時發(fā)現(xiàn)和解決問題，提高系統(tǒng)的穩(wěn)定性。

以上只是傳統(tǒng)高可用架構(gòu)的優(yōu)勢，但是現(xiàn)在的高可用架構(gòu)基本都會上云，云上高可用架構(gòu)比之傳統(tǒng)高可用就又多了幾個優(yōu)勢。

云上高可用架構(gòu)

動態(tài)擴容

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

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

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

img

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

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

數(shù)據(jù)安全

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

img

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

便利性

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

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

img

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

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

穩(wěn)定性

說到底，穩(wěn)定性才是云廠商的最大優(yōu)勢，云廠商一般提供存儲、數(shù)據(jù)庫、計算和網(wǎng)絡(luò)這些基礎(chǔ)設(shè)施，由于云廠商具有大量的用戶，大量的應(yīng)用部署在云上， 所以他們對于這些基礎(chǔ)設(shè)施本身就有一套高可用的架構(gòu)在支撐，而且這些基礎(chǔ)設(shè)施在大量用戶的考驗之下也逐漸堅如磐石。

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

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

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

在設(shè)計高可用架構(gòu)時，需要遵循以下原則：

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

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

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

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

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

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

如果你已經(jīng)做好了云上高可用架構(gòu)，依然發(fā)生了應(yīng)用崩潰情況，那么你和云服務(wù)廠商之間，究竟應(yīng)該誰來負責呢？

我的應(yīng)用宕機了，云服務(wù)廠商應(yīng)不應(yīng)該負責？

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

img

從上圖可以看到，云服務(wù)廠商主要負責的部分是硬件設(shè)施，如果硬件出現(xiàn)了問題導致了客戶的應(yīng)用出現(xiàn)問題，那么云服務(wù)廠商是應(yīng)該承擔責任的。

比如在 2022年1月，谷歌云在美國東部地區(qū)出現(xiàn)了大規(guī)模的網(wǎng)絡(luò)故障，導致谷歌云上的數(shù)千個網(wǎng)站和應(yīng)用程序無法正常訪問。該網(wǎng)絡(luò)故障是由于谷歌云的網(wǎng)絡(luò)設(shè)備出現(xiàn)了故障所致，導致一些客戶的數(shù)據(jù)流無法正常傳輸。

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

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

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

2019年11月19日，GitHub 因為一名員工在執(zhí)行一個數(shù)據(jù)庫清理腳本時不小心刪除了一個生產(chǎn)數(shù)據(jù)庫集群的主節(jié)點，導致該集群不可用，持續(xù)了43分鐘。

2019年7月2日，F(xiàn)acebook、Instagram和WhatsApp因為一名員工在配置數(shù)據(jù)庫時誤刪了一些關(guān)鍵數(shù)據(jù)，導致這三個平臺的服務(wù)不可用，持續(xù)了約8小時。

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

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

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

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

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

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

總結(jié)

今天主要給大家?guī)砹嗽粕细呖捎眉軜?gòu)的內(nèi)容，主要帶大家詳細了解了云上高可用架構(gòu)的優(yōu)勢以及上云的必要性。

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

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

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

審核編輯 ：李倩