在《這多年來我一直在鑽研的技術》這篇文章中，我講述了一下，我這麼多年來一直在關注的技術領域，其中我多次提到了工業級的軟件，我還以爲有很多人會問我怎麼定義工業級？以及一個高可用性的軟件系統應該要怎麼幹出來？這樣我也可以順理成章的寫下這篇文章，但是沒有人問，那麼，我只好厚顏無恥的自己寫下這篇文章了。哈哈。
另外，我在一些討論高可用系統的地方看到大家只討論各個公司的技術方案，其實，高可用的系統並不簡單的是技術方案，一個高可用的系統其實還包括很多別的東西，所以，我覺得大家對高可用的系統瞭解的還不全面，爲了讓大家的認識更全面，所以，我寫下這篇文章。
理解高可用系統
首先，我們需要理解什麼是高可用，英文叫High Availability（Wikipedia詞條），基本上來說，就是要讓我們的計算環境（包括軟硬件）做到full-time的可用性。在設計上一般來說，需要做好如下的設計：
- 對軟硬件的冗餘，以消除單點故障。任何系統都會有一個或多個冗餘系統做standby
- 對故障的檢測和恢復。檢測故障以及用備份的結點接管故障點。這也就是failover
- 需要很可靠的交匯點（CrossOver）。這是一些不容易冗餘的結點，比如域名解析，負載均衡器等。
聽起似乎很簡單吧，然而不是，細節之處全是魔鬼，冗餘結點最大的難題就是對於有狀態的結點的數據複製和數據一致性的保證（無狀態結點的冗餘相對比較簡單）。冗餘數據所帶來的一致性問題是魔鬼中的魔鬼：
- 如果系統的數據鏡像到冗餘結點是異步的，那麼在failover的時候就會出現數據差異的情況。
- 如果系統在數據鏡像到冗餘結點是同步的，那麼就會導致冗餘結點越多性能越慢。
所以，很多高可用系統都是在做各種取捨，這需要比對着業務的特點來的，比如銀行賬號的餘額是一個狀態型的數據，那麼，冗餘時就必需做到強一致性，再比如說，訂單記錄屬於追加性的數據，那麼在failover的時候，就可以到備機上進行追加，這樣就比較簡單了（阿里目前所謂的異地雙活其實根本做不到狀態型數據的雙活）。
下面，總結一下高可用的設計原理：
- 要做到數據不丟，就必需要持久化
- 要做到服務高可用，就必需要有備用（複本），無論是應用結點還是數據結點
- 要做到複製，就會有數據一致性的問題。
- 我們不可能做到100%的高可用，也就是說，我們能做到幾個9個的SLA。
高可用系統的技術解決方案
我在《分佈式系統的事務處理》中引用過下面這個圖：這個圖來自來自：Google App Engine的co-founder Ryan Barrett在2009年的Google I/O上的演講《Transaction Across DataCenter》（視頻： http://www.youtube.com/watch?v=srOgpXECblk）
這個圖基本上來說是目前高可用系統中能看得到的所有的解決方案的基礎了。M/S、MM實現起來不難，但是會有很多問題，2PC的問題就是性能不行，而Paxos的問題就是太複雜，實現難度太大。
總結一下各個高可用方案的的問題：
- 對於最終一致性來說，在宕機的情況下，會出現數據沒有完全同步完成，會出現數據差異性。
- 對於強一致性來說，要麼使用性能比較慢的XA系的兩階段提交的方案，要麼使用性能比較好，但是實現比較複雜的Paxos協議。
注：這是軟件方面的方案。當然，也可以使用造價比較高的硬件解決方案，不過本文不涉及硬件解決方案。
另外，現今開源軟件中，很多緩存，消息中間件或數據庫都有持久化和Replication的設計，從而也都有高可用解決方案，但是開源軟件一般都沒有比較高的SLA，所以，如果我們使用開源軟件的話，需要注意這一點。
高可用技術方案的示例
下面，我們來看一下MySQL的高可用的方案的SLA（下圖下面紅色的標識表示了這個方案有幾個9）：
圖片來源：MySQL High Availability Solutions
簡單解釋一下MySQL的這幾個方案（主要是想表達一個越多的9就越複雜）
- MySQL Repleaction就是傳統的異步數據同步或是半同步Semi-Sync（只要有一個slave收到更新就返回成功）這個方式本質上不到2個9。
- MySQL Fabric簡單來說就是數據分片下的M/S的讀寫分離模式。這個方案的的可用性可以達到99%
- DRBD通過底層的磁盤同步技術來解決數據同步的問題，就是RAID 1——把兩臺以上的主機的硬盤鏡像成一個。這個方案不到3個9
- Solaris Clustering/Oracle VM ，這個機制監控了包括硬件、操作系統、網絡和數據庫。這個方案一般會伴隨着節點間的“心跳機制”，而且還會動用到SAN（Storage Area Network）或是本地的分佈式存儲系統，還會動用虛擬化技術來做虛擬機的遷移以降低宕機時間的概率。這個解決方案完全就是一個“全棧式的解決方案”。這個方案接近4個9。
- MySQL Cluster是官方的一個開源方案，其把MySQL的集羣分成SQL Node 和Data Node，Data Node是一個自動化sharing和複製的集羣NDB，爲了更高的可用性，MySQL Cluster採用了“完全同步”的數據複製的機制來冗餘數據結點。這個方案接近5個9。
那麼，這些2個9，3個9，4個9，5個9是什麼意思呢？又是怎麼來的呢？請往下看。
高可用性的SLA的定義
上面那些都不是本文的重點，本文的重點現在開始，如何測量系統的高可用性。當然是SLA，全稱Service Level Agrement，也就是有幾個9的高可用性。
工業界有兩種方法來測量SLA，
- 一個是故障發生到恢復的時間
- 另一個是兩次故障間的時間
但大多數都採用第一種方法，也就是故障發生到恢復的時間，也就是服務不可用的時間，如下表所示：
| 系統可用性% | 宕機時間/年 | 宕機時間/月 | 宕機時間/周 | 宕機時間/天 |
|---|---|---|---|---|
| 90% (1個9) | 36.5 天 | 72 小時 | 16.8 小時 | 2.4 小時 |
| 99% (2個9) | 3.65 天 | 7.20 小時 | 1.68 小時 | 14.4 分 |
| 99.9% (3個9) | 8.76 小時 | 43.8 分 | 10.1 分鐘 | 1.44 分 |
| 99.99% (4個9) | 52.56 分 | 4.38 分 | 1.01 分鐘 | 8.66 秒 |
| 99.999% (5個9) | 5.26 分 | 25.9 秒 | 6.05 秒 | 0.87 秒 |
比如，99.999%的可用性，一年只能有5分半鐘的服務不可用。感覺很難做到吧。
就算是3個9的可用性，一個月的宕機時間也只有40多分鐘，看看那些設計和編碼不認真的團隊，把所有的期望寄託在人肉處理故障的運維團隊， 一個故障就能處理1個多小時甚至2-3個小時，連個自動化的工具都沒有，還好意思在官網上聲明自己的SLA是3個9或是5個9，這不是欺騙大衆嗎？。
影響高可用的因素
老實說，我們很難計算我們設計的系統有多少的可用性，因爲影響一個系統的因素實在是太多了，除了軟件設計，還有硬件，還有每三方的服務（如電信聯通的寬帶SLA），當然包括“建築施工隊的挖掘機”。所以，正如SLA的定義，這不僅僅只是一個技術指標，而是一種服務提供商和用戶之間的contract或契約。這種工業級的玩法，就像飛機一樣，並不是把飛機造出來就好了，還有大量的無比專業的配套設施、工具、流程、管理和運營。
簡而言之，SLA的幾個9就是能持續提供可用服務的級別，不過，工業界中，會把服務不可用的因素分成兩種：一種是有計劃的，一種是無計劃的。
無計劃的宕機原因
下圖來自Oracle的 《High Availability Concepts and Best Practices》
有計劃的宕機原因
下圖來自Oracle的 《High Availability Concepts and Best Practices》
我們可以看到，上面的宕機原因包括如下：
無計劃的
- 系統級的故障 – 包括主機、操作系統、中間件、數據庫、網絡、電源以及外圍設備
- 數據和中介的故障 – 包括人員誤操作、硬盤故障、數據亂了
- 還有：自然災害、人爲破壞、以及供電問題。
有計劃的
- 日常任務：備份，容量規劃，用戶和安全管理，後臺批處理應用
- 運維相關：數據庫維護、應用維護、中間件維護、操作系統維護、網絡維護
- 升級相關：數據庫、應用、中間件、操作系統、網絡、包括硬件升級
真正決定高可用系統的本質原因
從上面這些會影響高可用的SLA的因素，你看到了什麼？如果你還是只看到了技術方面或是軟件設計的東西，那麼你只看到了冰山一角。我們再仔細想一想，那個5個9的SLA在一年內只能是5分鐘的不可用時間，5分鐘啊，如果按一年只出1次故障，你也得在五分鐘內恢復故障，讓我們想想，這意味着什麼？
如果你沒有一套科學的牛逼的軟件工程的管理，沒有牛逼先進的自動化的運維工具，沒有技術能力很牛逼的工程師團隊，怎麼可能出現高可用的系統啊。
是的，要幹出高可用的系統，這TMD就是一套嚴謹科學的工程管理，其中包括但不限於了：
- 軟件的設計、編碼、測試、上線和軟件配置管理的水平
- 工程師的人員技能水平
- 運維的管理和技術水平
- 數據中心的運營管理水平
- 依賴於第三方服務的管理水平
深層交的東西則是——對工程這門科學的尊重：
- 對待技術的態度
- 一個公司的工程文化
- 領導者對工程的尊重
所以，以後有人在你面前提高可用，你要看的不是他的技術設計，而還要看看他們的工程能力，看看他們公司是否真正的尊重工程這門科學。
其它
有好些非技術甚至技術人員和我說過，做個APP做個網站，不就是找幾個碼農過來寫寫代碼嘛。等系統不可用的時候，他們纔會明白，要找技術能力比較強的人，但是，就算你和他們講一萬遍道理，他們也很難會明白寫代碼怎麼就是一種工程了，而工程怎麼就成了一門科學了。其實，很多做技術的人都不明白這個道理。
包括很多技術人員也永遠不會理解，爲什麼要做好多像Code Review、自動化運維、自動化測試、持續集成之類這樣很無聊的東西。就像我在《從Code Review 談如何做技術》中提到的，阿里很多的工程師，架構師/專家，甚至資深架構師都沒有這個意識，當然，這不怪他們，因爲經歷決定思維方式，他們的經歷的是民用級的系統，做的都是堆功能的工作，的確不需要。
看完這些，最後讓我們都捫心自問一下，你還敢說你的系統是高可用的了麼？ ;-)
（全文完）