點擊上方“服務端思維”，選擇“設為星標”

回復”669“獲取獨家整理的精選資料集

回復”加群“加入全國服務端高端社群「后端圈」

作者 | 崔凱

出品?| 騰訊云中間件

導讀

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

作者介紹

崔凱

騰訊云 CSIG 微服務產品中心產品架構師

多年分布式、高并發電子商務系統的研發、系統架構設計經驗，擅長主流微服務架構技術平臺的落地和實施

目前專注于微服務架構相關中間件的研究推廣和最佳實踐的沉淀，致力于幫助企業完成數字化轉型

概念篇

什么是高可用性

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

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

可用性設計的對象

那么可用性設計的對象是誰？有的同學認為是服務，因為向用戶交付的永遠是服務，服務高可用才具備價值；也有同學說是系統，因為最終要將高可用設計落地到整體系統中；還有同學認為是架構，因為合理的架構是保障高可用的基礎，高可用設計本身也常以架構的形式討論。此處仁者見仁，不過架構師通常會通過整體架構，提綱挈領的將應用、組件、平臺等進行高可用方面的組織和規劃。

高可用指標

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

常見的可用性評價指標：

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

• MTTR：Mean Time To Repair，平均恢復前時間。

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

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

• RPO：Recovery Point Objective，恢復點目標。

• RTO：Recovery Time Objective，恢復時間目標。

國家《信息安全技術-信息系統災難恢復規范》也對信息系統的RPO和RTO做出要求：

高可用設計理論

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

高可用設計要素

• 冗余：確保對系統操作至關重要的任何元素都有一個額外的冗余組件，這些組件可以在發生故障時接管。

• 監控：從正在運行的系統中收集數據，并檢測組件何時發生故障或停止響應。

• 故障轉移：一種手動或自動機制。如果監控顯示活動組件發生故障，該機制可以從當前活動的組件切換到冗余組件。

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

問答篇

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

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

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

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

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

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

Q: 可用性與分布式架構其它四個要素（高性能、可擴展、可伸縮、安全性）以及業務之間是什么關系？

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

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

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

Q: 容錯、高可用、災難恢復有什么區別？

A: 容錯指系統運行過程中，即使某部分功能單元故障，也可以繼續運行，關鍵在“容忍”部分故障。高可用指系統在故障發生時可以用極少的時間恢復業務運行，需要的中斷時間越短高可用性等級越高，其關鍵在“快速”的恢復能力。災難恢復指當災難發生時，可以切換業務、數據到其它地域進行恢復，關鍵在通過“切換”實現恢復，這里注意災難恢復不是為了挽救基礎設施，而是為了挽救業務或數據。此處可參考下圖中業務連續性管理的國際標準PDCA循環模型：

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

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

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

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

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

最后，高可用方案中應當包含應用相關內容。有部分同學認為高可用方案只跟架構部門有關，應用的代碼質量、技術選型等不重要，甚至有時在激烈討論時可能聽到“這種非功能性需求不應該全部由架構部解決嗎”“代碼的問題不需要基礎支撐部門過多參與”。原因可能是基礎架構師在一些團隊中，并不像研發經理一樣對應用直接管理。

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

Q: 業務應用開發中有沒有一些通用的方法提高應用自身的質量和高可用水平？

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

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

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

第三，基礎支撐組件可以支撐應用版本化、配置版本化、SQL版本化、服務優雅上下線等能力，一旦生產環境出現問題可以及時的回滾到原先版本。（配置版本化參考：https://cloud.tencent.com/document/product/649/15539，優雅上下線參考：https://cloud.tencent.com/document/product/649/46961）

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

Q: 如何檢測高可用方案落地是否達到預期？

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

結語

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

引用

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

— 本文結束 —

●?漫談設計模式在 Spring 框架中的良好實踐

●?顛覆微服務認知：深入思考微服務的七個主流觀點

●?人人都是 API 設計者

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

●?要黑盒測試微服務內部服務間調用，我該如何實現？

關注我，回復 「加群」 加入各種主題討論群。

對「服務端思維」有期待，請在文末點個在看

喜歡這篇文章，歡迎轉發、分享朋友圈

在看點這里

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。