究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高可用”

一、什么是高可用

---

高可用HA（High Availability）是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一，它通常是指，通過設(shè)計減少系統(tǒng)不能提供服務(wù)的時間。

假設(shè)系統(tǒng)一直能夠提供服務(wù)，我們說系統(tǒng)的可用性是100%。

如果系統(tǒng)每運(yùn)行100個時間單位，會有1個時間單位無法提供服務(wù)，我們說系統(tǒng)的可用性是99%。

很多公司的高可用目標(biāo)是4個9，也就是99.99%，這就意味著，系統(tǒng)的年停機(jī)時間為8.76個小時。

百度的搜索首頁，是業(yè)內(nèi)公認(rèn)高可用保障非常出色的系統(tǒng)，甚至人們會通過www.baidu.com 能不能訪問來判斷“網(wǎng)絡(luò)的連通性”，百度高可用的服務(wù)讓人留下啦“網(wǎng)絡(luò)通暢，百度就能訪問”，“百度打不開，應(yīng)該是網(wǎng)絡(luò)連不上”的印象，這其實是對百度HA最高的褒獎。

二、如何保障系統(tǒng)的高可用

---

我們都知道，單點是系統(tǒng)高可用的大敵，單點往往是系統(tǒng)高可用最大的風(fēng)險和敵人，應(yīng)該盡量在系統(tǒng)設(shè)計的過程中避免單點。方法論上，高可用保證的原則是“集群化”，或者叫“冗余”：只有一個單點，掛了服務(wù)會受影響；如果有冗余備份，掛了還有其他backup能夠頂上。

保證系統(tǒng)高可用，架構(gòu)設(shè)計的核心準(zhǔn)則是：冗余。

有了冗余之后，還不夠，每次出現(xiàn)故障需要人工介入恢復(fù)勢必會增加系統(tǒng)的不可服務(wù)實踐。所以，又往往是通過“自動故障轉(zhuǎn)移”來實現(xiàn)系統(tǒng)的高可用。

接下來我們看下典型互聯(lián)網(wǎng)架構(gòu)中，如何通過冗余+自動故障轉(zhuǎn)移來保證系統(tǒng)的高可用特性。

三、常見的互聯(lián)網(wǎng)分層架構(gòu)

---

常見互聯(lián)網(wǎng)分布式架構(gòu)如上，分為：

（1）客戶端層：典型調(diào)用方是瀏覽器browser或者手機(jī)應(yīng)用APP

（2）反向代理層：系統(tǒng)入口，反向代理

（3）站點應(yīng)用層：實現(xiàn)核心應(yīng)用邏輯，返回html或者json

（4）服務(wù)層：如果實現(xiàn)了服務(wù)化，就有這一層

（5）數(shù)據(jù)-緩存層：緩存加速訪問存儲

（6）數(shù)據(jù)-數(shù)據(jù)庫層：數(shù)據(jù)庫固化數(shù)據(jù)存儲

整個系統(tǒng)的高可用，又是通過每一層的冗余+自動故障轉(zhuǎn)移來綜合實現(xiàn)的。

四、分層高可用架構(gòu)實踐

---

【客戶端層->反向代理層】的高可用

【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗余來實現(xiàn)的。以nginx為例：有兩臺nginx，一臺對線上提供服務(wù)，另一臺冗余以保證高可用，常見的實踐是keepalived存活探測，相同virtual IP提供服務(wù)。

自動故障轉(zhuǎn)移：當(dāng)nginx掛了的時候，keepalived能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到shadow-nginx，由于使用的是相同的virtual IP，這個切換過程對調(diào)用方是透明的。

【反向代理層->站點層】的高可用

【反向代理層】到【站點層】的高可用，是通過站點層的冗余來實現(xiàn)的。假設(shè)反向代理層是nginx，nginx.conf里能夠配置多個web后端，并且nginx能夠探測到多個后端的存活性。

自動故障轉(zhuǎn)移：當(dāng)web-server掛了的時候，nginx能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到其他的web-server，整個過程由nginx自動完成，對調(diào)用方是透明的。

【站點層->服務(wù)層】的高可用

【站點層】到【服務(wù)層】的高可用，是通過服務(wù)層的冗余來實現(xiàn)的?！胺?wù)連接池”會建立與下游服務(wù)多個連接，每次請求會“隨機(jī)”選取連接來訪問下游服務(wù)。

自動故障轉(zhuǎn)移：當(dāng)service掛了的時候，service-connection-pool能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到其他的service，整個過程由連接池自動完成，對調(diào)用方是透明的（所以說RPC-client中的服務(wù)連接池是很重要的基礎(chǔ)組件）。

【服務(wù)層>緩存層】的高可用

【服務(wù)層】到【緩存層】的高可用，是通過緩存數(shù)據(jù)的冗余來實現(xiàn)的。

緩存層的數(shù)據(jù)冗余又有幾種方式：第一種是利用客戶端的封裝，service對cache進(jìn)行雙讀或者雙寫。

緩存層也可以通過支持主從同步的緩存集群來解決緩存層的高可用問題。

以redis為例，redis天然支持主從同步，redis官方也有sentinel哨兵機(jī)制，來做redis的存活性檢測。

自動故障轉(zhuǎn)移：當(dāng)redis主掛了的時候，sentinel能夠探測到，會通知調(diào)用方訪問新的redis，整個過程由sentinel和redis集群配合完成，對調(diào)用方是透明的。

說完緩存的高可用，這里要多說一句，業(yè)務(wù)對緩存并不一定有“高可用”要求，更多的對緩存的使用場景，是用來“加速數(shù)據(jù)訪問”：把一部分?jǐn)?shù)據(jù)放到緩存里，如果緩存掛了或者緩存沒有命中，是可以去后端的數(shù)據(jù)庫中再取數(shù)據(jù)的。

這類允許“cache miss”的業(yè)務(wù)場景，緩存架構(gòu)的建議是：

將kv緩存封裝成服務(wù)集群，上游設(shè)置一個代理（代理可以用集群冗余的方式保證高可用），代理的后端根據(jù)緩存訪問的key水平切分成若干個實例，每個實例的訪問并不做高可用。

緩存實例掛了屏蔽：當(dāng)有水平切分的實例掛掉時，代理層直接返回cache miss，此時緩存掛掉對調(diào)用方也是透明的。key水平切分實例減少，不建議做re-hash，這樣容易引發(fā)緩存數(shù)據(jù)的不一致。

【服務(wù)層>數(shù)據(jù)庫層】的高可用

大部分互聯(lián)網(wǎng)技術(shù)，數(shù)據(jù)庫層都用了“主從同步，讀寫分離”架構(gòu)，所以數(shù)據(jù)庫層的高可用，又分為“讀庫高可用”與“寫庫高可用”兩類。

【服務(wù)層>數(shù)據(jù)庫層“讀”】的高可用

【服務(wù)層】到【數(shù)據(jù)庫讀】的高可用，是通過讀庫的冗余來實現(xiàn)的。

既然冗余了讀庫，一般來說就至少有2個從庫，“數(shù)據(jù)庫連接池”會建立與讀庫多個連接，每次請求會路由到這些讀庫。

自動故障轉(zhuǎn)移：當(dāng)讀庫掛了的時候，db-connection-pool能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到其他的讀庫，整個過程由連接池自動完成，對調(diào)用方是透明的（所以說DAO中的數(shù)據(jù)庫連接池是很重要的基礎(chǔ)組件）。

【服務(wù)層>數(shù)據(jù)庫層“寫”】的高可用

【服務(wù)層】到【數(shù)據(jù)庫寫】的高可用，是通過寫庫的冗余來實現(xiàn)的。

以mysql為例，可以設(shè)置兩個mysql雙主同步，一臺對線上提供服務(wù)，另一臺冗余以保證高可用，常見的實踐是keepalived存活探測，相同virtual IP提供服務(wù)。

自動故障轉(zhuǎn)移：當(dāng)寫庫掛了的時候，keepalived能夠探測到，會自動的進(jìn)行故障轉(zhuǎn)移，將流量自動遷移到shadow-db-master，由于使用的是相同的virtual IP，這個切換過程對調(diào)用方是透明的。

五、總結(jié)

---

高可用HA（High Availability）是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一，它通常是指，通過設(shè)計減少系統(tǒng)不能提供服務(wù)的時間。

方法論上，高可用是通過冗余+自動故障轉(zhuǎn)移來實現(xiàn)的。

整個互聯(lián)網(wǎng)分層系統(tǒng)架構(gòu)的高可用，又是通過每一層的冗余+自動故障轉(zhuǎn)移來綜合實現(xiàn)的，具體的：

（1）【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗余實現(xiàn)的，常見實踐是keepalived + virtual IP自動故障轉(zhuǎn)移

（2）【反向代理層】到【站點層】的高可用，是通過站點層的冗余實現(xiàn)的，常見實踐是nginx與web-server之間的存活性探測與自動故障轉(zhuǎn)移

（3）【站點層】到【服務(wù)層】的高可用，是通過服務(wù)層的冗余實現(xiàn)的，常見實踐是通過service-connection-pool來保證自動故障轉(zhuǎn)移

（4）【服務(wù)層】到【緩存層】的高可用，是通過緩存數(shù)據(jù)的冗余實現(xiàn)的，常見實踐是緩存客戶端雙讀雙寫，或者利用緩存集群的主從數(shù)據(jù)同步與sentinel?；钆c自動故障轉(zhuǎn)移；更多的業(yè)務(wù)場景，對緩存沒有高可用要求，可以使用緩存服務(wù)化來對調(diào)用方屏蔽底層復(fù)雜性

（5）【服務(wù)層】到【數(shù)據(jù)庫“讀”】的高可用，是通過讀庫的冗余實現(xiàn)的，常見實踐是通過db-connection-pool來保證自動故障轉(zhuǎn)移

（6）【服務(wù)層】到【數(shù)據(jù)庫“寫”】的高可用，是通過寫庫的冗余實現(xiàn)的，常見實踐是keepalived + virtual IP自動故障轉(zhuǎn)移