當(dāng)我們在聊高可用時，我們其實在聊什么？

概念篇

什么是高可用性

什么是高可用性？可能要先定義什么是可用性。維基百科中的定義： 可用性是指一個系統(tǒng)處在可工作狀態(tài)的時間的比例。簡單講，在一個給定的時間間隔內(nèi)，對于一個功能個體來講，總的可用時間所占的比例。

那么，很明顯的，高可用性指系統(tǒng)通過高可用設(shè)計，趨近于100%的保證系統(tǒng)的高度可用。其中，無論用于描述和統(tǒng)計系統(tǒng)當(dāng)前的高可用程度，還是用于設(shè)計未來的理論狀況，高可用性的評價都需具備時間維度，否則沒有約束意義。

可用性設(shè)計的對象

那么可用性設(shè)計的對象是誰？有的同學(xué)認(rèn)為是服務(wù)，因為向用戶交付的永遠(yuǎn)是服務(wù)，服務(wù)高可用才具備價值；也有同學(xué)說是系統(tǒng)，因為最終要將高可用設(shè)計落地到整體系統(tǒng)中；還有同學(xué)認(rèn)為是架構(gòu)，因為合理的架構(gòu)是保障高可用的基礎(chǔ)，高可用設(shè)計本身也常以架構(gòu)的形式討論。此處仁者見仁，不過架構(gòu)師通常會通過整體架構(gòu)，提綱挈領(lǐng)的將應(yīng)用、組件、平臺等進(jìn)行高可用方面的組織和規(guī)劃。

高可用指標(biāo)

云廠商最常用的對服務(wù)高可用性進(jìn)行約束和描述的是SLA(Service-level Agreement)，它是服務(wù)供應(yīng)商將一系列約定的高可用指標(biāo)放入合同中，與客戶達(dá)成的正式（具有法律約束力）或非正式的協(xié)議。其中包含服務(wù)類型、性能水平、可靠性、響應(yīng)性，以及故障發(fā)生的解決方案和其它規(guī)定等。

常見的可用性評價指標(biāo)：

• MTBF：Mean Time Between Failure，平均故障間隔時間。
• MTTR：Mean Time To Repair，平均恢復(fù)前時間。

• MTTF：Mean Time To Failure，修復(fù)前平均時間。

• SA：Service Available，如下圖所示，列出了“N個9”各代表的故障時間。每多一個9，都代表著落地難度指數(shù)級增長，同時可用此公式計算：SA = MTBF/(MTBF + MTTR)。

• RPO：Recovery Point Objective，恢復(fù)點目標(biāo)。

• RTO：Recovery Time Objective，恢復(fù)時間目標(biāo)。

國家《信息安全技術(shù)-信息系統(tǒng)災(zāi)難恢復(fù)規(guī)范》也對信息系統(tǒng)的RPO和RTO做出要求：

高可用設(shè)計理論

CAP：Consistency、Availability、Partition tolerance，此理論人盡皆知，最終會在CP和AP中權(quán)衡，找到滿足BASE（Basically Available、Soft state、Eventually consistent）的平衡結(jié)果。

高可用設(shè)計要素

• 冗余：確保對系統(tǒng)操作至關(guān)重要的任何元素都有一個額外的冗余組件，這些組件可以在發(fā)生故障時接管。
• 監(jiān)控：從正在運(yùn)行的系統(tǒng)中收集數(shù)據(jù)，并檢測組件何時發(fā)生故障或停止響應(yīng)。

• 故障轉(zhuǎn)移：一種手動或自動機(jī)制。如果監(jiān)控顯示活動組件發(fā)生故障，該機(jī)制可以從當(dāng)前活動的組件切換到冗余組件。

上述三要素邏輯也很清晰：要實現(xiàn)高可用，不管是否存在狀態(tài)，要先有冗余或備份；當(dāng)真正出現(xiàn)故障的時候，要有監(jiān)控手段監(jiān)控到故障發(fā)生；故障發(fā)生后，可以通過故障轉(zhuǎn)移組件快速轉(zhuǎn)移到之前的冗余組件中，保證服務(wù)不中斷。

問答篇

以上簡單介紹了可用性相關(guān)概念，下面通過問答形式進(jìn)行探討，供大家發(fā)散思考。

Q: 高可用做起來成本大、難度高，到底值不值得？

A: 我們在做高可用建設(shè)時，其實就像在給系統(tǒng)買“保險”。買了不一定用的上，有時候可能還不希望用上，但是不買自己又不放心。對于大型系統(tǒng)，動輒上百、千萬的資產(chǎn)投入，其實為的只是保障那千分之一，甚至萬分之一的故障幾率。

但保險也有“貴賤”，就像社保和重疾險，除了價格不同，應(yīng)用場景和起到的作用也不同。在做高可用設(shè)計時也是同理，核心系統(tǒng)或組件往往需要更多的冗余、更全面的監(jiān)控、更自動化的故障切換做保障。如對訂單系統(tǒng)的用戶數(shù)據(jù)的保障就需要買“重疾險”，因為一旦出了問題可能丟掉身家性命。而對管理運(yùn)營端的系統(tǒng)日志，買“社保”更合適一些，即使數(shù)據(jù)丟失，影響也是可控的。

另外關(guān)注一點，高可用建設(shè)是系統(tǒng)性工程，整體高可用保障水平取決于功能單元鏈條中水平最低的那個，比如微服務(wù)網(wǎng)關(guān)如果欠缺彈性伸縮和限流能力，那未知流量洪峰到來后網(wǎng)關(guān)已經(jīng)掛掉了，之后的核心服務(wù)做再多的彈性和限流都無濟(jì)于事。

對于值得不值得，公司不僅花錢買到了一堆資產(chǎn)，還買到了安全感，更買到了用戶對公司無價的信任，只要規(guī)劃在合理范圍內(nèi)，這筆買賣的性價比就非常高。

Q: 可用性與分布式架構(gòu)其它四個要素（高性能、可擴(kuò)展、可伸縮、安全性）以及業(yè)務(wù)之間是什么關(guān)系？

A: 分布式架構(gòu)設(shè)計的五要素之間是互相關(guān)聯(lián)的，在整體架構(gòu)設(shè)計中，應(yīng)該且需要一起討論。以高可用為例，冗余不僅為架構(gòu)內(nèi)功能單元提供備份，輔以負(fù)載均衡也會提高功能單元的訪問性能，同時也滿足了AKF擴(kuò)展立方體（Scalability Cube）中水平擴(kuò)展的要求。

另外，五要素能力建設(shè)是隨著架構(gòu)演進(jìn)一步步增強(qiáng)的。從單服務(wù)+單體應(yīng)用的強(qiáng)耦合開始，將應(yīng)用、數(shù)據(jù)庫、文件服務(wù)器等拆分到獨立服務(wù)器，保證了各自的高可用和性能；通過集群、負(fù)載均衡、無狀態(tài)既解決了高并發(fā)的問題，又滿足了架構(gòu)的可伸縮、高性能、高可用的需求；將數(shù)據(jù)庫、文件系統(tǒng)、緩存、大數(shù)據(jù)、搜索引擎等改造為分布式架構(gòu)，又進(jìn)一步提高了整體架構(gòu)的高性能、高可用、可擴(kuò)展水平。最后隨著容災(zāi)和業(yè)務(wù)拆分的需求，逐漸演化為多地多中心及單元化架構(gòu)，高可用、可擴(kuò)展水平又一次提升。

可以看到業(yè)務(wù)的發(fā)展是架構(gòu)演進(jìn)的重要驅(qū)動力之一，它一步步推動著分布式架構(gòu)各要素水平不斷提升。高可用在每次架構(gòu)銳變都是必須考量的，同時成本也是比較大的。那么，企業(yè)上云，將最大的成本交給云廠商，也是一個不錯的選擇。

Q: 容錯、高可用、災(zāi)難恢復(fù)有什么區(qū)別？

A: 容錯指系統(tǒng)運(yùn)行過程中，即使某部分功能單元故障，也可以繼續(xù)運(yùn)行，關(guān)鍵在“容忍”部分故障。高可用指系統(tǒng)在故障發(fā)生時可以用極少的時間恢復(fù)業(yè)務(wù)運(yùn)行，需要的中斷時間越短高可用性等級越高，其關(guān)鍵在“快速”的恢復(fù)能力。災(zāi)難恢復(fù)指當(dāng)災(zāi)難發(fā)生時，可以切換業(yè)務(wù)、數(shù)據(jù)到其它地域進(jìn)行恢復(fù)，關(guān)鍵在通過“切換”實現(xiàn)恢復(fù)，這里注意災(zāi)難恢復(fù)不是為了挽救基礎(chǔ)設(shè)施，而是為了挽救業(yè)務(wù)或數(shù)據(jù)。此處可參考下圖中業(yè)務(wù)連續(xù)性管理的國際標(biāo)準(zhǔn)PDCA循環(huán)模型：

Q: 高可用方案設(shè)計需要從哪些角度討論和思考？

A: 首先，應(yīng)用側(cè)、支撐側(cè)、運(yùn)維側(cè)的設(shè)計方式方法不同。應(yīng)用側(cè)高可用除了可以通過上述提到的冗余、集群、負(fù)載均衡等做到快速的故障轉(zhuǎn)移，還包括熔斷、限流、容錯、降級、應(yīng)急等保障手段，框架組件的超時及重試策略、異步調(diào)用、冪等性設(shè)計來補(bǔ)充。支撐側(cè)（或稱基礎(chǔ)設(shè)施平臺）需要一整套高可用相關(guān)的監(jiān)控指標(biāo)，滿足故障的提前預(yù)警、快速報警、可視化監(jiān)控和分析。常見指標(biāo)包括請求量、請求錯誤率、平均延時、HTTP狀態(tài)，以及系統(tǒng)資源消耗相關(guān)指標(biāo)等。

另外支撐側(cè)自身組件本質(zhì)上也是應(yīng)用，所以也需要上述應(yīng)用側(cè)的方法保證自身高可用，尤其在多地多中心架構(gòu)中，支撐側(cè)要配合應(yīng)用側(cè)做整體高可用適配。運(yùn)維側(cè)中關(guān)鍵一點是DevOps，自動化發(fā)布、灰度發(fā)布、優(yōu)雅發(fā)布、版本控制、健康檢查等能力，可以在業(yè)務(wù)發(fā)生故障前和發(fā)生故障時，幫助應(yīng)用最大程度減小服務(wù)不可用時長。

其次，公有云與私有云的高可用方案差異很大。公有云落地過程中，主要由云廠商提供基礎(chǔ)設(shè)施高可用保障和最佳實踐。私有云落地場景有較大差異，確定高可用方案時各干系人（客戶側(cè)、云廠商側(cè)、開發(fā)商側(cè)各角色）是有各自訴求的，那么高可用方案本身就可能因非技術(shù)原因變更。

客戶希望云廠商根據(jù)高可用要求提供合適的可落地執(zhí)行的高可用方案建議，ISV希望高可用方案盡量少的影響當(dāng)前業(yè)務(wù)開發(fā)和后續(xù)變更，云廠商希望盡量基于產(chǎn)品現(xiàn)有能力擴(kuò)展，減少定制化開發(fā)。所以，溝通的過程中往往會出現(xiàn)僵持，比如云廠商經(jīng)常成為客戶需求和疑難問題的兜底人，給云廠商帶來不小的成本。所以，方案溝通過程就可能演變成多方利益權(quán)衡妥協(xié)的過程，高可用方案也會在互相妥協(xié)中不斷變化，直到各方達(dá)成統(tǒng)一。

最后，高可用方案中應(yīng)當(dāng)包含應(yīng)用相關(guān)內(nèi)容。有部分同學(xué)認(rèn)為高可用方案只跟架構(gòu)部門有關(guān)，應(yīng)用的代碼質(zhì)量、技術(shù)選型等不重要，甚至有時在激烈討論時可能聽到“這種非功能性需求不應(yīng)該全部由架構(gòu)部解決嗎”“代碼的問題不需要基礎(chǔ)支撐部門過多參與”。原因可能是基礎(chǔ)架構(gòu)師在一些團(tuán)隊中，并不像研發(fā)經(jīng)理一樣對應(yīng)用直接管理。

舉幾個例子：開發(fā)人員上傳excel沒有做文件大小檢查，當(dāng)用戶上傳過大excel文件就會導(dǎo)致前臺應(yīng)用OOM；操作數(shù)據(jù)庫時SQL沒有加limit限制，當(dāng)搜索時間過長時，數(shù)據(jù)庫會一次性返回幾十萬條數(shù)據(jù)；由于開發(fā)人員比較熟悉Struts而未選用SpringMVC，導(dǎo)致Struts安全漏洞被利用；雖然上述神操作可能都是低級錯誤，但管中窺豹，在高可用建設(shè)的過程中，應(yīng)用的整體質(zhì)量會對整體高可用產(chǎn)生直接影響，基礎(chǔ)支撐組件可以幫助應(yīng)用發(fā)現(xiàn)問題，但不能避免問題產(chǎn)生。要想真正保證高可用，勢必要在應(yīng)用質(zhì)量等相關(guān)聯(lián)的部分多下功夫。

Q: 業(yè)務(wù)應(yīng)用開發(fā)中有沒有一些通用的方法提高應(yīng)用自身的質(zhì)量和高可用水平？

A: 此處略過測試向的質(zhì)量保證方法和編碼技能提升這類需要建設(shè)時間的方面，主要幾點拿來即用的建議。

第一，應(yīng)用系統(tǒng)最主要的敵人之一是復(fù)雜性，那么使復(fù)雜性增強(qiáng)的主要原因呢？是耦合，尤其是內(nèi)容耦合（業(yè)務(wù)邏輯）、數(shù)據(jù)耦合（參數(shù)和數(shù)據(jù)庫）、外部耦合（外部依賴）。面對耦合其實有一項利器——消息隊列，通過消息隊列可以讓同步變異步，減少業(yè)務(wù)邏輯之間的耦合度，讓數(shù)據(jù)拆分更容易實現(xiàn)，標(biāo)準(zhǔn)化外部依賴的通訊接口。（消息隊列最佳實踐參考：https://cloud.tencent.com/document/product/1179/44817）

第二，如果不能了解、分析應(yīng)用目前和過去的運(yùn)行狀況，我們就很難預(yù)防未來未知問題的發(fā)生。這就需要我們建立功能完備、高度可視化的監(jiān)控平臺，幫助開發(fā)及運(yùn)維人員及時發(fā)現(xiàn)和快速定位問題。（可視化監(jiān)控應(yīng)用場景參考：https://cloud.tencent.com/document/product/1311/50756）

第三，基礎(chǔ)支撐組件可以支撐應(yīng)用版本化、配置版本化、SQL版本化、服務(wù)優(yōu)雅上下線等能力，一旦生產(chǎn)環(huán)境出現(xiàn)問題可以及時的回滾到原先版本。（配置版本化參考：https://cloud.tencent.com/document/product/649/15539，優(yōu)雅上下線參考：https://cloud.tencent.com/document/product/649/46961）

第四，基礎(chǔ)支撐平臺應(yīng)具備鑒權(quán)、路由、限流、熔斷、容錯等服務(wù)治理能力，這些能力可幫助應(yīng)用的高可用水平上升一個臺階。沒有服務(wù)鑒權(quán)，就可能被非法服務(wù)內(nèi)部攻擊；沒有服務(wù)限流，就可能在流量浪涌中瞬間宕機(jī)；沒有服務(wù)路由，就很難做到灰度發(fā)布、A/B測試等；沒有服務(wù)熔斷，一旦上游服務(wù)出現(xiàn)問題，下游服務(wù)就可能產(chǎn)生連鎖反應(yīng)。（服務(wù)治理原理及最佳實踐參考：https://cloud.tencent.com/document/product/649/15546）

Q: 如何檢測高可用方案落地是否達(dá)到預(yù)期？

A: 全鏈路故障演練，是一種檢測高可用方案是否符合預(yù)期的常用方法。其本身可能還包括一些細(xì)分部分，如應(yīng)急方案、降級方案、演練人員安排、演練場景及用例、演練環(huán)境準(zhǔn)備、演練結(jié)果復(fù)盤等，通過多次演練鍛煉團(tuán)隊的處理故障能力并檢驗相關(guān)流程。另外，實際落地故障演練會消耗大量人力、物力，這對高可用要求不高的中小企業(yè)很不友好。但并不能因為成本高就放棄演練，做不到故障對用戶完全無感知，至少保證核心鏈路可用，最差也要保證持久化數(shù)據(jù)完整一致。同時，可通過監(jiān)控平臺對各功能單元的監(jiān)控數(shù)據(jù)，分析鏈路中可能存在的隱患。

結(jié)語

在架構(gòu)演進(jìn)過程中，高可用是一個始終繞不開的話題，本文對高可用建設(shè)的部分問題進(jìn)行了片面的討論。尤其近些年云原生趨勢明顯，又會給高可用設(shè)計帶來哪些機(jī)遇與挑戰(zhàn)？我們需不斷迎難而上，進(jìn)行突破和創(chuàng)新，持續(xù)探索更優(yōu)秀的高可用設(shè)計方案。

引用

1. https://cloud.netapp.com/blog/azure-high-availability-basic-concepts-and-a-checklist
2. https://en.wikipedia.org/wiki/Availability
   
3. https://en.wikipedia.org/wiki/Service-level_agreement
   
4. https://www.fdevops.com/2021/02/24/sla-25325
5. http://www.djbh.net/webdev/file/webFiles/File/cpzg/20122616046.pdf
6. http://dannyzhang.run/2020/03/21/system-desing-1/
7. http://www.pbenson.net/2014/02/the-difference-between-fault-tolerance-high-availability-disaster-recovery/

8. https://cloud.tencent.com/developer/article/1058500