1. What
在聊如何構建高可用系統之前，我們需要對"可用"下一個定義。
業界常用SLA（Service Level Agreement）來描述一個系統的可用性, SLA包含很多信息（服務內容、故障恢復時間、可用性等）， 在這裏我們籠統的用“N個9”來指代，比如4個9指的是99.99%的可用性、 5個9指的是99.999%的可用性。
假如一個系統聲稱它的年可用性是4個9， 那它提供的可用性承諾就是一年之內， 不可用時間不超過52.56分鐘（60 * 24 * 365 * 0.0001）。
在此基礎之上，我們來看看， 系統需要做到什麼程度， 可以稱爲高可用：
- 低故障總時長： 一般認爲4個9以上纔有資格稱爲高可用
- 快速的故障恢復： 即使一個系統一年只掛一次但是需要52分鐘才能恢復（那麼這個系統的年可用性是4個9）， 那其實也是不能接受的。
2. Why
爲什麼要構建高可用系統？ 這個其實不必多說，大家都懂， 因此一筆帶過。 系統的高可用對於個人口碑、產品、公司的形象、營收、股價，甚至社會穩定， 都至關重要。
3. How
3.1 問題所在
在着手構建高可用系統之前，我們需要知道是哪些因素在阻礙我們提高系統的可用性：
- 一切單點都是不可靠的, 如果系統中某個地方可能會出問題（就算概率很低），那麼它遲早會出問題。 也就是我們常說的Murphy’s Law。
- 系統依賴的一切下游系統都是不可靠的， 它們隨時可能出問題
- "人"是不可靠的， 費勁心思設計的高可用系統，會因爲新引入一個低級錯誤而崩潰
- 高可用是有前提條件的，一個系統對當前的負載能提供高可用， 不代表負載上升之後仍然高可用
- 高可用需要指標來衡量， 我們不能靠嘴來構建高可用系統
3.2 逐個擊破
知道了問題所在， 那麼就有解決的方向了：
- 既然單點肯定會出問題，那麼我們就避免單點
- 既然下游肯定會出問題， 那麼我們得處理下游不可用的情況
- 既然“人”肯定會犯錯， 那麼我們就引入各種機制，來減少犯錯的概率， 以及減少犯錯的損失
- 既然系統只能在一定負載內提供高可用， 那麼我們就得爲系統構建一套過載保護機制
- 爲系統構建一套監控， 數據說話
接下來的幾篇文章， 我會對以上幾點展開來講，乾貨多多， 歡迎持續關注。