關於高可用的系統

在《這多年來我一直在鑽研的技術》這篇文章中，我講述了一下，我這麼多年來一直在關注的技術領域，其中我屢次提到了工業級的軟件，我還覺得有不少人會問我怎麼定義工業級？以及一個高可用性的軟件系統應該要怎麼幹出來？這樣我也能夠瓜熟蒂落的寫下這篇文章，可是沒有人問，那麼，我只好厚顏無恥的本身寫下這篇文章了。哈哈。

另外，我在一些討論高可用系統的地方看到你們只討論各個公司的技術方案，其實，高可用的系統並不簡單的是技術方案，一個高可用的系統其實還包括不少別的東西，因此，我以爲你們對高可用的系統瞭解的還不全面，爲了讓你們的認識更全面，因此，我寫下這篇文章。

理解高可用系統

首先，咱們須要理解什麼是高可用，英文叫High Availability（Wikipedia詞條），基本上來講，就是要讓咱們的計算環境（包括軟硬件）作到full-time的可用性。在設計上通常來講，須要作好以下的設計：

 

1. 對軟硬件的冗餘，以消除單點故障。任何系統都會有一個或多個冗餘系統作standby
2. 對故障的檢測和恢復。檢測故障以及用備份的結點接管故障點。這也就是failover
3. 須要很可靠的交匯點（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 談如何作技術》中提到的，阿里不少的工程師，架構師/專家，甚至資深架構師都沒有這個意識，固然，這不怪他們，由於經歷決定思惟方式，他們的經歷的是民用級的系統，作的都是堆功能的工做，的確不須要。

看完這些，最後讓咱們都捫心自問一下，你還敢說你的系統是高可用的了麼？ ;-)

（全文完）