點(diǎn)擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”

回復(fù)”669“獲取獨(dú)家整理的精選資料集

回復(fù)”加群“加入全國服務(wù)端高端社群「后端圈」

作者 | 崔凱

出品?| 騰訊云中間件

導(dǎo)讀

高可用可以說是分布式系統(tǒng)中最常談到的詞之一，那么我們在聊高可用時(shí)，我們其實(shí)在聊什么？本文將通過問答的形式拋磚引玉，其中不會(huì)涉及過多的技術(shù)細(xì)節(jié)，旨在為企業(yè)的系統(tǒng)高可用建設(shè)提供一些參考思路和啟發(fā)。

作者介紹

崔凱

騰訊云 CSIG 微服務(wù)產(chǎn)品中心產(chǎn)品架構(gòu)師

多年分布式、高并發(fā)電子商務(wù)系統(tǒng)的研發(fā)、系統(tǒng)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，擅長主流微服務(wù)架構(gòu)技術(shù)平臺(tái)的落地和實(shí)施

目前專注于微服務(wù)架構(gòu)相關(guān)中間件的研究推廣和最佳實(shí)踐的沉淀，致力于幫助企業(yè)完成數(shù)字化轉(zhuǎn)型

概念篇

什么是高可用性

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

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

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

那么可用性設(shè)計(jì)的對(duì)象是誰？有的同學(xué)認(rèn)為是服務(wù)，因?yàn)橄蛴脩艚桓兜挠肋h(yuǎn)是服務(wù)，服務(wù)高可用才具備價(jià)值；也有同學(xué)說是系統(tǒng)，因?yàn)樽罱K要將高可用設(shè)計(jì)落地到整體系統(tǒng)中；還有同學(xué)認(rèn)為是架構(gòu)，因?yàn)楹侠淼募軜?gòu)是保障高可用的基礎(chǔ)，高可用設(shè)計(jì)本身也常以架構(gòu)的形式討論。此處仁者見仁，不過架構(gòu)師通常會(huì)通過整體架構(gòu)，提綱挈領(lǐng)的將應(yīng)用、組件、平臺(tái)等進(jìn)行高可用方面的組織和規(guī)劃。

高可用指標(biāo)

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

常見的可用性評(píng)價(jià)指標(biāo)：

• MTBF：Mean Time Between Failure，平均故障間隔時(shí)間。

• MTTR：Mean Time To Repair，平均恢復(fù)前時(shí)間。

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

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

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

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

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

高可用設(shè)計(jì)理論

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

高可用設(shè)計(jì)要素

• 冗余：確保對(duì)系統(tǒng)操作至關(guān)重要的任何元素都有一個(gè)額外的冗余組件，這些組件可以在發(fā)生故障時(shí)接管。

• 監(jiān)控：從正在運(yùn)行的系統(tǒng)中收集數(shù)據(jù)，并檢測組件何時(shí)發(fā)生故障或停止響應(yīng)。

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

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

問答篇

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

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

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

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

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

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

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

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

另外，五要素能力建設(shè)是隨著架構(gòu)演進(jìn)一步步增強(qiáng)的。從單服務(wù)+單體應(yīng)用的強(qiáng)耦合開始，將應(yīng)用、數(shù)據(jù)庫、文件服務(wù)器等拆分到獨(dú)立服務(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ū)動(dòng)力之一，它一步步推動(dòng)著分布式架構(gòu)各要素水平不斷提升。高可用在每次架構(gòu)銳變都是必須考量的，同時(shí)成本也是比較大的。那么，企業(yè)上云，將最大的成本交給云廠商，也是一個(gè)不錯(cuò)的選擇。

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

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

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

A: 首先，應(yīng)用側(cè)、支撐側(cè)、運(yùn)維側(cè)的設(shè)計(jì)方式方法不同。應(yīng)用側(cè)高可用除了可以通過上述提到的冗余、集群、負(fù)載均衡等做到快速的故障轉(zhuǎn)移，還包括熔斷、限流、容錯(cuò)、降級(jí)、應(yīng)急等保障手段，框架組件的超時(shí)及重試策略、異步調(diào)用、冪等性設(shè)計(jì)來補(bǔ)充。支撐側(cè)（或稱基礎(chǔ)設(shè)施平臺(tái)）需要一整套高可用相關(guān)的監(jiān)控指標(biāo)，滿足故障的提前預(yù)警、快速報(bào)警、可視化監(jiān)控和分析。常見指標(biāo)包括請求量、請求錯(cuò)誤率、平均延時(shí)、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)鍵一點(diǎn)是DevOps，自動(dòng)化發(fā)布、灰度發(fā)布、優(yōu)雅發(fā)布、版本控制、健康檢查等能力，可以在業(yè)務(wù)發(fā)生故障前和發(fā)生故障時(shí)，幫助應(yīng)用最大程度減小服務(wù)不可用時(shí)長。

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

客戶希望云廠商根據(jù)高可用要求提供合適的可落地執(zhí)行的高可用方案建議，ISV希望高可用方案盡量少的影響當(dāng)前業(yè)務(wù)開發(fā)和后續(xù)變更，云廠商希望盡量基于產(chǎn)品現(xiàn)有能力擴(kuò)展，減少定制化開發(fā)。所以，溝通的過程中往往會(huì)出現(xiàn)僵持，比如云廠商經(jīng)常成為客戶需求和疑難問題的兜底人，給云廠商帶來不小的成本。所以，方案溝通過程就可能演變成多方利益權(quán)衡妥協(xié)的過程，高可用方案也會(huì)在互相妥協(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ù)選型等不重要，甚至有時(shí)在激烈討論時(shí)可能聽到“這種非功能性需求不應(yīng)該全部由架構(gòu)部解決嗎”“代碼的問題不需要基礎(chǔ)支撐部門過多參與”。原因可能是基礎(chǔ)架構(gòu)師在一些團(tuán)隊(duì)中，并不像研發(fā)經(jīng)理一樣對(duì)應(yīng)用直接管理。

舉幾個(gè)例子：開發(fā)人員上傳excel沒有做文件大小檢查，當(dāng)用戶上傳過大excel文件就會(huì)導(dǎo)致前臺(tái)應(yīng)用OOM；操作數(shù)據(jù)庫時(shí)SQL沒有加limit限制，當(dāng)搜索時(shí)間過長時(shí)，數(shù)據(jù)庫會(huì)一次性返回幾十萬條數(shù)據(jù)；由于開發(fā)人員比較熟悉Struts而未選用SpringMVC，導(dǎo)致Struts安全漏洞被利用；雖然上述神操作可能都是低級(jí)錯(cuò)誤，但管中窺豹，在高可用建設(shè)的過程中，應(yīng)用的整體質(zhì)量會(huì)對(duì)整體高可用產(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è)時(shí)間的方面，主要幾點(diǎn)拿來即用的建議。

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

第二，如果不能了解、分析應(yīng)用目前和過去的運(yùn)行狀況，我們就很難預(yù)防未來未知問題的發(fā)生。這就需要我們建立功能完備、高度可視化的監(jiān)控平臺(tái)，幫助開發(fā)及運(yùn)維人員及時(shí)發(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)問題可以及時(shí)的回滾到原先版本。（配置版本化參考：https://cloud.tencent.com/document/product/649/15539，優(yōu)雅上下線參考：https://cloud.tencent.com/document/product/649/46961）

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

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

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

結(jié)語

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

引用

https://cloud.netapp.com/blog/azure-high-availability-basic-concepts-and-a-checklist

https://en.wikipedia.org/wiki/Availability

https://en.wikipedia.org/wiki/Service-level_agreement

https://www.fdevops.com/2021/02/24/sla-25325

http://www.djbh.net/webdev/file/webFiles/File/cpzg/20122616046.pdf

http://dannyzhang.run/2020/03/21/system-desing-1/

http://www.pbenson.net/2014/02/the-difference-between-fault-tolerance-high-availability-disaster-recovery/

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

— 本文結(jié)束 —

●?漫談設(shè)計(jì)模式在 Spring 框架中的良好實(shí)踐

●?顛覆微服務(wù)認(rèn)知：深入思考微服務(wù)的七個(gè)主流觀點(diǎn)

●?人人都是 API 設(shè)計(jì)者

●?一文講透微服務(wù)下如何保證事務(wù)的一致性

●?要黑盒測試微服務(wù)內(nèi)部服務(wù)間調(diào)用，我該如何實(shí)現(xiàn)？

關(guān)注我，回復(fù) 「加群」 加入各種主題討論群。

對(duì)「服務(wù)端思維」有期待，請?jiān)谖哪c(diǎn)個(gè)在看

喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈

在看點(diǎn)這里

總結(jié)

以上是生活随笔為你收集整理的当我们在聊高可用时，我们其实在聊什么？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。