高可用架構,是近年來構建大中型網站很時髦的詞,是大數據,大并發,高負載后出現的產品。但是根據實際情況真正能做到,可伸縮,可擴展,可維護,確是不容易的事。
高可用架構的話題擴展開來,可以寫一本書,21CTO平臺也會持續登載相關文章,這些文章會匯聚和總結為這本書的主要內容。
從Livedoor,再從趕集網,從一兩臺機器到十幾臺。再到后來的YY平臺,后來的今日頭條的特賣架構,再到云架構,隨著技術的演進,有些異同,但也有共通之處。根據產品特性,成本,團隊技術等的綜合體現,并沒有固定的標準。
什么是高可用
高可用(High Availability)實際上是構建分布式系統的一個標準,特別是互聯網的分布式系統架構要達到高性能,高擴展,以及高可用可伸縮等特征,高可用是分布式系統架構中首重考慮的因素。
高可用指通過系統架構來減少和避免系統不能提供可用服務的時間。馬上快過年了,我們都要用12306網站來訂票,這個最牛網站還是每天晚上10點到第二天7點關機不營業,這屬于另一種不提供服務,另當別論。
假設系統一直能夠提供服務,我們說系統的可用性是100%。如果系統每運行100個時間單位,會有1小時間單位無法提供服務,我們說系統的可用性是99%。很多公司的高可用目標是4個9,也就是99.99%,這就意味著,系統的年停機時間為8.8個小時。
使用公式 x = (n - y) * 100/n 來計算可用性百分比。
x代表百分比
n代表給定歷月(30 天)中的總分鐘數
y代表系統或服務不可用時的總分鐘數
可以在下表(該表使可用性百分比與日歷時間等價值相關聯)中看到,很難實現五個九的可用性。
請見下表:
說明
通俗叫法
可用性級別
年/停機時間
基本可用性
2個9
99%
87.6小時
較高可用性
3個9
99.9%
8.8小時
具有故障自動恢復能力的可用性
4個9
99.99%
53分鐘
最高可用性
5個9
99.999%
5分鐘
網站或后端系統可用性標準
關于可用性服務標準,在一些正規的數據中心IDC或提供CDN的公司,它們IT 服務級別協議 (SLA)能夠達到4個9標準的。
當然,可用性是有一個平衡點,達到4個9就是不錯的公司,還有一些關鍵特性,比如容錯,容災,備份和恢復等。
舉個栗子,一些網站在人們心目中是一直不宕機的。比如百度,它在若干年的頁面只有十幾K。不管是不是互聯網公司,人們會通過ping baidu.com來檢測網絡的連通性。它的高可用服務,達到了常說的『簡單,可依賴』,『如果百度都打不開,應該網絡斷了』,人們會常這樣確定。
另外還有163.com等都成為業內公認高可用保障非常出色的系統,這是對這些技術團隊的至高榮譽。
如何保障系統高可用
我們都知道,單點故障是系統高可用的大敵,即一臺機器出現問題,導至整個系統的不可用。因此在架構設計上應該盡量避免單點。在理論方法上,保證高可用的方法就是『負載均衡』,即『分布式』『集群化』式設計。假如說只有一臺服務器,如果它掛掉了,整體服務都受到了影響。
現實中,一臺機器來支撐應用的場景也有,需要我們做到可用性也可以達成,但思想也有多臺機器思維,以及異常的處理,后面我會持續大家談討。
很顯而易見的是,當有了多臺服務器后,流量負載會分攤到這些機器上,即使有一臺掛了還有其它機器能夠頂得上。
保證系統高可用,架構設計的核心準則就是:系統冗余。加了冗余后,還不夠,當每次出現故障后,如果需要人工來介入以恢復服務,這樣也會增加系統的不可服務實踐。
所以,我們是通過『故障自動轉移』來實現系統的高可用。接下來,我們一起看典型的互聯網架構中,如果通過冗余+自動故障轉移來保證系統的高可用特性。
圖1 互聯網基礎架構概覽
我們常見的互聯網分布式基本架構就是上面的圖示。
這些分層簡介如下:
1、客戶端層:也稱前端,調用方為瀏覽器或手機APP
2、CDN為內容分發網絡,相當于內容的分布式緩存
3、站點應用層:實現核心應用邏輯,返回HTML/Java或JSON數據
4、服務層:如果架構已經實現了SOA,RPC或Web Service
5、數據-緩存層:緩存加速訪問存儲,包括NoSQL等相關
6、數據庫層:數據持久化
整個系統的高可用,是通過第一層的均衡+冗余與自動故障轉移來綜合實現的。