高可用HA（High Availability）是分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。
單點往往是系統高可用最大的風險和敵人，應該盡量在系統設計的過程中避免單點。高可用保證的原則是“集群化”，或者叫“冗余”：只有一個單點，掛了服務會受影響。如果有冗余備份，掛了還有其他backup能夠頂上。
有了冗余之後，還不夠，每次出現故障需要人工介入恢復勢必會增加系統的不可服務實踐。所以，又往往是通過“自動故障轉移”來實現系統的高可用。
接下來我們看下典型互聯網架構中，如何通過”冗余+自動故障轉移”來保證系統的高可用特性。
常見的互聯網分層架構
先用一個圖簡單說明一下這個分層架構：
從上至下分別為：
- 客戶端層：典型調用方是瀏覽器browser或者手機應用APP
- 反向代理層：系統入口，反向代理
- 站點應用層：實現核心應用邏輯，返回html或者json
- 服務層：如果實現了服務化，就有這一層
- 數據-緩存層：緩存加速訪問存儲
- 數據-數據庫層：數據庫固化數據存儲
整個系統的高可用，又是通過每一層的”冗余+自動故障轉移”來綜合實現的。
下面從反向代理層開始，分別介紹每一層的高可用實現
反向代理層高可用
【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗余來實現的。以nginx為例：有兩臺nginx，一臺對線上提供服務，另一臺冗余以保證高可用，常見的實踐是keepalived存活探測，相同virtual IP提供服務。
自動故障轉移：當nginx掛了的時候，keepalived能夠探測到，會自動的進行故障轉移，將流量自動遷移到備份nginx，由於使用的是相同的virtual IP，這個切換過程對調用方是透明的。
站點層高可用
【反向代理層】到【站點層】的高可用，是通過站點層的冗余來實現的。假設反向代理層是nginx，
nginx.conf
裏能夠配置多個web後端，並且nginx能夠探測到多個後端的存活性。
自動故障轉移：當web-server掛了的時候，nginx能夠探測到，會自動的進行故障轉移，將流量自動遷移到其他的web-server，整個過程由nginx自動完成，對調用方是透明的。
服務層高可用
【站點層】到【服務層】的高可用，是通過服務層的冗余來實現的。“服務連接池”會建立與下遊服務多個連接，每次請求會“隨機”選取連接來訪問下遊服務。
自動故障轉移：當service掛了的時候，service-connection-pool能夠探測到，會自動的進行故障轉移，將流量自動遷移到其他的service，整個過程由連接池自動完成，對調用方是透明的（所以說RPC-client中的服務連接池是很重要的基礎組件）。
一般這個會使用到分布式服務框架。
緩存高可用
業務對緩存並不一定有“高可用”要求，更多的對緩存的使用場景，是用來“加速數據訪問”：把一部分數據放到緩存裏，如果緩存掛了或者緩存沒有命中，是可以去後端的數據庫中再取數據的。這類允許“cache miss”的業務場景，緩存架構的建議是：
緩存實例掛了屏蔽：當有水平切分的實例掛掉時，代理層直接返回cache miss，此時緩存掛掉對調用方也是透明的。key水平切分實例減少，不建議做re-hash，這樣容易引發緩存數據的不一致。
數據庫層的高可用
大部分互聯網技術，數據庫層都用了“主從同步，讀寫分離”架構，所以數據庫層的高可用，又分為“讀庫高可用”與“寫庫高可用”兩類。
數據庫讀高可用
【數據庫讀】的高可用，是通過讀庫的冗余來實現的。既然冗余了讀庫，一般來說就至少有2個從庫，“數據庫連接池”會建立與讀庫多個連接，每次請求會路由到這些讀庫。
自動故障轉移：當讀庫掛了的時候，db-connection-pool能夠探測到，會自動的進行故障轉移，將流量自動遷移到其他的讀庫，整個過程由連接池自動完成，對調用方是透明的（所以說DAO中的數據庫連接池是很重要的基礎組件）。
數據庫寫高可用
【數據庫寫】的高可用，是通過寫庫的冗余來實現的。以mysql為例，可以設置兩個mysql雙主同步，一臺對線上提供服務，另一臺冗余以保證高可用，常見的實踐是keepalived存活探測，相同virtual IP提供服務。
自動故障轉移：當寫庫掛了的時候，keepalived能夠探測到，會自動的進行故障轉移，將流量自動遷移到shadow-db-master，由於使用的是相同的virtual IP，這個切換過程對調用方是透明的。
總結
高可用HA（High Availability）是分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。方法論上，高可用是通過冗余+自動故障轉移來實現的。
整個互聯網分層系統架構的高可用，又是通過每一層的冗余+自動故障轉移來綜合實現的，具體的：
- 【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗余實現的，常見實踐是keepalived + virtual IP自動故障轉移
- 【反向代理層】到【站點層】的高可用，是通過站點層的冗余實現的，常見實踐是nginx與web-server之間的存活性探測與自動故障轉移
- 【站點層】到【服務層】的高可用，是通過服務層的冗余實現的，常見實踐是通過service-connection-pool來保證自動故障轉移
- 【服務層】到【緩存層】的高可用，是通過緩存數據的冗余實現的，常見實踐是緩存客戶端雙讀雙寫，或者利用緩存集群的主從數據同步與sentinel保活與自動故障轉移；更多的業務場景，對緩存沒有高可用要求，可以使用緩存服務化來對調用方屏蔽底層復雜性
- 【服務層】到【數據庫“讀”】的高可用，是通過讀庫的冗余實現的，常見實踐是通過db-connection-pool來保證自動故障轉移
- 【服務層】到【數據庫“寫”】的高可用，是通過寫庫的冗余實現的，常見實踐是keepalived + virtual IP自動故障轉移
高可用HA（High Availability）是分布式系統架構設計中必須考慮的因素之一， 它通常是指，通過設計減少系統不能提供服務的時間。
單點往往是系統高可用最大的風險和敵人，應該盡量在系統設計的過程中避免單點。 高可用保證的原則是“集群化”，或者叫“冗余”：只有一個單點，掛了服務會受影響。 如果有冗余備份，掛了還有其他backup能夠頂上。
有了冗余之後，還不夠，每次出現故障需要人工介入恢復勢必會增加系統的不可服務實踐。 所以，又往往是通過“自動故障轉移”來實現系統的高可用。
接下來我們看下典型互聯網架構中，如何通過”冗余+自動故障轉移”來保證系統的高可用特性。
Tags: 可用 冗余 反向 單點 系統 實現
文章來源：