十幾年前，我參加阿里巴巴面試的時候，覺得阿里巴巴這樣的網站Web應用開發簡直小菜，因為我之前是做類似Tomcat這樣的Web容器開發的，所以面試的時候信心滿滿。

確實，面試官前面的問題都是關于數據結構、操作系統、設計模式的，也就是我們這個專欄模塊一和模塊二的內容。我感覺自己回答得還不錯，所以更加信心滿滿。這時候，面試官忽然提了一個問題：

我們的Web程序每個星期都會發布一個新版本，但是程序要求7*24小時可用，也就是說，啟動新版本程序替換老程序，進行程序升級的時候，程序還在對外提供服務，用戶沒有感覺到停機，我們是怎么做到的呢？

應用程序升級必須要用新版本的程序包替代老版本的程序包，并重新啟動程序，這段時間程序是不能對外提供服務的，用戶請求一定會失敗。但是阿里巴巴讓這段時間的用戶請求依然是成功的。打個比方，就是要在飛機飛行過程中更換發動機，還不能讓乘客感覺到。這個問題當時完全不在我的知識范圍之內，但是我知道這個需求場景是真實存在的，而且確實應該是可以做到的，可是我完全不知道是怎么做到的。

面試官看我瞠目結舌，笑著問我，想不想知道答案。我立刻回答說想知道，結果面試官跟我說，加入我們團隊你就知道了。

這其實是一個關于互聯網應用可用性的問題。我們知道，Web應用在各種情況下都有可能不可訪問，也就是不可用。各種硬件故障，比如應用服務器及數據庫宕機、網絡交換機宕機、磁盤損壞、網卡松掉等等。還有各種軟件故障，程序Bug什么的。即使沒有Bug，程序要升級，必須要關閉進程重新啟動，這段時間應用也是不可用的；此外，還有外部環境引發的不可用，比如促銷引來大量用戶訪問，導致系統并發壓力太大而崩潰，以及，黑客攻擊、機房火災、挖掘機挖斷光纜，各種情況導致的應用不可用。

而互聯網的高可用是說，在上面各種情況下，應用都要是可用的，用戶都能夠正常訪問系統，完成業務處理。

這似乎是不可能的任務。

高可用的度量

首先我們看下，什么叫做應用的高可用，以及可用性如何度量。業界通常用多少個9來說明互聯網應用的可用性。比如說淘寶的可用性是4個9，就是說淘寶的服務99.99%可用。這句話的意思是，淘寶的服務要保證在所有的運行時間里只有0.01%不可用，也就是說一年大概有53分鐘不可用。這個99.99%就叫做系統的可用性指標，這個值的計算公式是：

一般說來，兩個9表示系統基本可用，年度不可用時間小于88小時；3個9是較高可用，年度不可用時間小于9個小時；4個9是具有自動恢復能力的高可用，年度不可用時間小于53分鐘；5個9指極高的可用性，年度不可用時間小于5分鐘。我們熟悉的互聯網產品的可用性大多是4個9。淘寶、百度、微信，差不多都是這樣。

下面我會討論各種高可用技術方案。但不管是哪種方案，實現高可用需要投入的技術和設備成本都非常高。因此可用性并不是越高越好，而是要根據產品策略尋找高可用投入產出的最佳平衡點，像支付寶這樣的金融產品就需要更高的可用性，而微博的可用性要求就會相對低一些。

可用性指標是對系統整體可用性的一個度量。在互聯網企業中，為了更好地管理系統的可用性，界定好系統故障以后的責任，通常會用故障分進行管理。一般過程是，根據系統可用性指標換算成一個故障分，這個故障分是整個系統的故障分，比如10萬分，然后根據各自團隊各個產品各個職能角色承擔的責任的不同，把故障分下發給每個團隊，直到每個人，也就是說每個工程師在年初的時候就會收到一個預計的故障分。然后每一次系統出現可用性故障的時候，都會進行故障考核，劃定到具體的團隊和責任人以后，會扣除他的故障分。如果到了年底的時候，如果一個工程師的故障分為負分，那么很有可能會影響他的績效考核。

圖片

高可用的架構

系統的高可用架構就是要在上述各種故障情況下，保證系統依然可以提供服務，具體包含以下幾種架構方案。我們已經在前面幾篇架構專欄中提到過這些架構方案，這里我們從高可用的視角重新審視以下這些架構是如何實現高可用的。

冗余備份

既然各種服務器故障是不可避免的，那么架構設計上就要保證，當服務器故障的時候，系統依然可以訪問。具體上就是要實現服務器的冗余備份。

冗余備份是說，提供同一服務的服務器要存在冗余，即任何服務都不能只有一臺服務器，服務器之間要互相進行備份，任何一臺服務器出現故障的時候，請求可以發送到備份的服務器去處理。這樣，即使某臺服務器失效，在用戶看來，系統依然是可用的。

我在負載均衡架構這篇文章中講了通過負載均衡服務器，將多臺應用服務器構成一個集群共同對外提供服務，這樣可以利用多臺應用服務器的計算資源，滿足高并發的用戶訪問請求。事實上，負載均衡還可以實現系統的高可用。

圖片

負載均衡服務器通過心跳檢測發現集群中某臺應用服務器失效，然后負載均衡服務器就不將請求分發給這臺服務器，對用戶而言，也就感覺不到有服務器失效，系統依然可用。

回到我們開頭的問題，阿里巴巴就是用這種方法實現的。應用程序升級的時候，停止應用進程，但是不影響用戶訪問。因為應用程序部署在多臺服務器上，應用程序升級的時候，每次只STOP一臺或者一部分服務器，在這些機器上進行程序升級，這個時候，集群中還有其他服務器在提供服務器，因此用戶感覺不到服務器已經停機了。

此外我在數據存儲架構這篇文章中提到的數據庫主主復制，也是一種冗余備份。這個時候，不只是數據庫系統RDBMS互相進行冗余備份，數據庫里的數據也要進行冗余備份，一份數據存儲在多臺服務器里，保證當任何一臺服務器失效，數據庫服務依然可以使用。

失敗隔離

保證系統高可用的另一個策略是失敗隔離，將失敗限制在一個較小的范圍之內，使故障影響范圍不擴大。具體實現失敗隔離的主要架構技術是消息隊列。

一方面，消息的生產者和消費者通過消息隊列進行隔離。如果消費者出現故障的時候，生產者可以繼續向消息隊列發送消息，而不會感知到消費者的故障，等消費者恢復正常以后再去從消息隊列中消費消息，所以從用戶處理的視角看，系統一直是可用的。

發送郵件消費者出現故障，不會影響生產者應用的運行，也不會影響發送短信等其他消費者正常的運行。

圖片

另一方面，由于分布式消息隊列具有削峰填谷的作用，所以在高并發的時候，消息的生產者可以將消息緩沖在分布式消息隊列中，消費者可以慢慢地從消息隊列中去處理，而不會將瞬時的高并發負載壓力直接施加到整個系統上，導致系統崩潰。也就是將壓力隔離開來，使消息生產者的訪問壓力不會直接傳遞到消息的消費者，這樣可以提高數據庫等對壓力比較敏感的服務的可用性。

同時，消息隊列還使得程序解耦，將程序的調用和依賴隔離開來，我們知道，低耦合的程序更加易于維護，也可以減少程序出現Bug的幾率。

限流降級

限流和降級也是保護系統高可用的一種手段。在高并發場景下，如果系統的訪問量超過了系統的承受能力，可以通過限流對系統進行保護。限流是指對進入系統的用戶請求進行流量限制，如果訪問量超過了系統的最大處理能力，就會丟棄一部分的用戶請求，保證整個系統可用，保證大部分用戶是可以訪問系統的。這樣雖然有一部分用戶的請求被丟棄，產生了部分不可用，但還是好過整個系統崩潰，所有的用戶都不可用要好。

降級是保護系統的另一種手段。有一些系統功能是非核心的，但是它也給系統產生了非常大的壓力，比如說在電商系統中有確認收貨這個功能，即便我們不去確認收貨，系統也會超時自動確認收貨。

但實際上確認收貨這個操作是一個非常重的操作，因為它會對數據庫產生很大的壓力：它要進行更改訂單狀態，完成支付確認，并進行評價等一系列操作。如果在系統高并發的時候去完成這些操作，那么會對系統雪上加霜，使系統的處理能力更加惡化。

解決辦法就是在系統高并發的時候，比如說像淘寶雙11的時候，當天可能整天系統都處于一種極限的高并發訪問壓力之下，這時候就可以將確認收貨、評價這些非核心的功能關閉，將寶貴的系統資源留下來，給正在購物的人，讓他們去完成交易。

異地多活

我們前面提到的各種高可用策略，都還是針對一個數據中心內的系統架構，針對服務器級別的軟硬件故障而言的。但如果整個數據中心都不可用，比如說數據中心所在城市遭遇了地震，機房遭遇了火災或者停電，這樣的話，不管我們前面的設計和系統多么的高可用，系統依然是不可用的。

為了解決這個問題，同時也為了提高系統的處理能力和改善用戶體驗，很多大型互聯網應用都采用了異地多活的多機房架構策略，也就是說將數據中心分布在多個不同地點的機房里，這些機房都可以對外提供服務，用戶可以連接任何一個機房進行訪問，這樣每個機房都可以提供完整的系統服務，即使某一個機房不可使用，系統也不會宕機，依然保持可用。

異地多活的架構考慮的重點就是，用戶請求如何分發到不同的機房去。這個主要可以在域名解析的時候完成，也就是用戶進行域名解析的時候，會根據就近原則或者其他一些策略，完成用戶請求的分發。另一個至關重要的技術點是，因為是多個機房都可以獨立對外提供服務，所以也就意味著每個機房都要有完整的數據記錄。用戶在任何一個機房完成的數據操作，都必須同步傳輸給其他的機房，進行數據實時同步。

數據庫實時同步最需要關注的就是數據沖突問題。同一條數據，同時在兩個數據中心被修改了，該如何解決？為了解決這種數據沖突的問題，某些容易引起數據沖突的服務采用類似MySQL的主主模式，也就是說多個機房在某個時刻是有一個主機房的，某些請求只能到達主機房才能被處理，其他的機房不處理這一類請求，以此來避免關鍵數據的沖突。

小結

除了以上的高可用架構方案，還有一些高可用的運維方案：通過自動化測試減少系統的Bug；通過自動化監控盡早發現系統的故障；通過預發布驗證發現測試環境無法發現的Bug；灰度發布降低軟件錯誤帶來的影響以及評估軟件版本升級帶來的業務影響等等。