什么是高可用

維穩(wěn)

「維穩(wěn)」，顧名思義就是維持穩(wěn)定，那什么叫穩(wěn)定。

回想一下，生活上一些可以找到穩(wěn)定的地方：

• 住的自己買的且不需要還貸房子，我們會覺得穩(wěn)定，因為不需要擔心被房東無故房租加價或趕出來、或者自己現(xiàn)金流出現(xiàn)問題導致斷供，不可控不能預期的情況較少。
• 看NBA比賽，湖人3節(jié)過后領先30分的時候，我覺得穩(wěn)了，因為被翻盤的幾率太小了。
• 某個軟件用起來，不會用著用著掛掉藍屏，內(nèi)存使用不會忽高忽低，那就叫穩(wěn)。
• 你看到一個陌生人走在大街上，他是在正常的往前走，不會無故搖搖晃晃，不會隨便跟別人搭話，不會突然撲過來打你，他的行為是符合常理的，所以感覺穩(wěn)定。

所以「穩(wěn)定」其實是一種心理的預期管理。一個東西穩(wěn)定，意思就是，他是什么樣子、有哪些狀態(tài)、出現(xiàn)什么結(jié)果可以怎么處理，是已經(jīng)事先預知的。

我們看一下IT系統(tǒng)，“不穩(wěn)”有以下癥狀：

1、變更之后就算通過了驗證，也會有可能被用戶報障某塊功能不可用，我明明沒動這一塊哇怎么會踩坑呢，原來代碼千絲萬縷太復雜，對影響范圍判斷錯誤導致漏測最終用戶報障才知曉不可用。

2、負責的某個被不少系統(tǒng)依賴的基礎服務，出了問題就容易亂了手腳，判斷影響范圍、找運維找研發(fā)、升級事件、同步故障、補償措施等，混亂操作會直接證明了你能力不行。

3、公共資源使用沒有規(guī)范，大家都在用，突然出現(xiàn)一個濫用、或者真的超過了使用的資源瓶頸，一大片關聯(lián)系統(tǒng)都會收到影響。

…………

所以，不管是我們“為或不為”，“不穩(wěn)”的感覺如影隨形。

你自己的問題、還是別的系統(tǒng)問題、還是網(wǎng)絡問題、還是云服務的問題，都有可能導致自己負責的系統(tǒng)不可用。故障也許會遲到但不會缺席，雖然我們陸陸續(xù)續(xù)提了一些優(yōu)化，但貌似并沒有增加太多安全感，總覺得離掛掉的不遠。

高可用定義

「維穩(wěn)」是大白話，對應軟件架構上叫高可用，High Availability，簡稱HA。維基百科是這么解釋，

高可用性（英語：high availability，縮寫為 HA），IT術語，指系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度。是進行系統(tǒng)設計時的準則之一。高可用性系統(tǒng)與構成該系統(tǒng)的各個組件相比可以更長時間運行。

整個概念里面重點就在「無中斷」，就是系統(tǒng)“不死”。

不穩(wěn)定就是系統(tǒng)時而輸出不了，高可用保持輸出的無中斷，所以高可用和穩(wěn)定，我認為可以劃等號。

可用性和可靠性

需要澄清一下，可用性和可靠性是兩個概念。比如對于一個API來講，

• 可靠性，系統(tǒng)是否具備無差錯地執(zhí)行預期操作的能力，專注的是輸出質(zhì)量；API返回的是否符合預期？是否是正確的？
• 可用性，為了執(zhí)行這些操作，系統(tǒng)當前可運行的能力，專注的是執(zhí)行能力；API有返回嗎？

可靠性更多地可以靠測試保證，但可用性比可靠性需要考慮的維度和復雜度都要高得多。

我們現(xiàn)在只討論可用性問題。

低可用原因

怎么才可以高可用呢，既然高可用難以達到，我們可以反過來用逆向思維考慮。

造成程序低可用的原因是什么？針對每個原因再優(yōu)化，那我們就可以一步步接近理想的高可用。

資源耗盡

資源指的是服務器、網(wǎng)路之類的有限資源，資源肯定都是有限的，有限體現(xiàn)在容積和期限。

• 服務器cpu、內(nèi)存等都有能力的上限，花光了就沒了，只能擴容。
• 服務器運行都有損耗，故障的一天總會到來。

資源是程序最底層的依賴，如果耗盡了那程序運行就會越來越慢直至無法響應。

舉個例子，就是前一陣子google大面積宕機就是硬盤用完的問題。

預期外壓力

程序設計也是有極限，架構、成本、壓力，沒有三者兼顧的最優(yōu)選擇。

所以一個程序最初的方案和架構可能是較為簡陋的，但可以適應當時的壓力；然而隨著應用程序被越來越多的人使用，就很可能需要對代碼和應用程序進行修改以支撐不斷增加的壓力。

比如某些系統(tǒng)突然搞一些定時搶獎品的活動，這種就容易人為造成壓力，如果沒有事先做好突增的壓力評估，特別是系統(tǒng)所依賴的某些環(huán)境容易疏漏，那在活動期間的壓力就很可能把服務壓死。

團隊協(xié)作

這是溝通管理的問題，項目復雜度高了，需要的團隊成員和角色就越來越多；人多溝通就會有損耗，人員流動也有損耗，最后實現(xiàn)的架構未必是原來設計的樣子，會打折扣。

每個人的編程方式風格也有可能各異，引入的組件也可能功能重疊、版本不一致等問題。

架構也會有破窗效應，架構慢慢被腐蝕，最終就會破壞原有架構可制成的可用性。

外部依賴

絕大部分程序不可能獨立運行，都需要外部saas服務、中間件等依賴，這些通用的服務雖然穩(wěn)定，但也會有不可用的風險。

由于這層依賴鏈的存在，基礎服務的不可用就會導致我們程序不可用。

技術債務

技術方案、時間、質(zhì)量、金錢，這些成本在實現(xiàn)一個功能的時候都需要取舍，有時候為保當前的業(yè)務快速上線，的確會把技術舍棄，選擇優(yōu)先發(fā)布的方式。

這樣就會造成技術債務，技術債務就是，原本應該考慮的、設計的技術環(huán)節(jié)，債務越多就越影響系統(tǒng)的可用性。

具體來說，技術債務包括：

• 缺乏設計，每個系統(tǒng)都需要設計，而且設計是有容量極限，隨著時間和用戶量增加，就容易超出容量極限造成不可用。
• 遺留bug，每個版本迭代為了按時發(fā)布，遺留一些bug，bug的堆積就有可能形成不可用的后患。
• 技術能力缺乏，開發(fā)人員技術能力不足，考慮不周，缺乏宏觀把握和預見性，對框架、技術細節(jié)了解不夠深入，沒考慮并發(fā)場景，這種債務層層疊加之下，也容易造成不可用。

參考：
1、《可伸縮架構（第2版）：云環(huán)境下的高可用與風險管理》https://book.douban.com/subject/35178755/