高可用架構，是近年來構建大中型網站很時髦的詞，是大數據，大并發，高負載后出現的產品。但是根據實際情況真正能做到，可伸縮，可擴展，可維護，確是不容易的事。
高可用架構的話題擴展開來，可以寫一本書，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、數據庫層：數據持久化
整個系統的高可用，是通過第一層的均衡+冗余與自動故障轉移來綜合實現的。
微信掃一掃
