含義

系統高可用，或者說系統的可用性，在計算機領域是一個相當久遠並且重要的概念。小到CPU芯片、內存、硬盤等硬件組件，大到支付寶、微信等日常互聯網服務，在設計、開發、維護的時候，都離不開對它的考量。

可用性度量和考覈
所謂業務可用性(availability)也即系統正常運行時間的百分比，架構組最主要的 KPI (Key Performance Indicators ，關鍵業績指標)。對於我們提供的服務（web，api）來說，更傾向用 N 個9 來量化可用性，最常說的就是類似 “4個9(也就是99.99%)” 的可用性。
可用性的高低是使用不可用時間佔總時間的比例來衡量。不可用時間是從故障發生到故障恢復的時間。比如，可用性 4 個 9 的系統（99.99%），它一年宕機時間不能超過53分鐘。做到高可用系統，需要儘可能的降低故障發生的次數和減少故障持續的時間。

描述	可用性級別	年度停機時間
極高可用性	99.999%	5分鐘
具有故障自動恢復能裏的可用性	99.99%	53分鐘
較高可用性	99.9%	8.8小時
基本可用性	99%	87.6小時

故障時間=故障修復時間點-故障發現（報告）時間點
服務年度可用時間%=（1-故障時間/年度時間）× 100%。
可用性KPI：以99.99%爲例→53m=365*24*60*(1-0.9999)

服務可用性的級別劃分
如果是一個分佈式架構設計，系統由很多微服務組成，所有的服務可用性不可能都是統一的標準。如果所有服務都實現高等級可用性的話，那麼成本就會增加，所以要根據服務的重要程度來進行可用性級別區分。
爲了提高我們服務可用性，我們需要對服務進行分類管理並明確每個服務級別的可用性要求。

類別	可用性最低要求	描述
一級__核心服務	99.999%（全年5分鐘不可用）	系統引擎部分：一旦出現故障，整個系統癱瘓
二級__重要服務	99.99%（全年53分鐘不可用）	如外賣系統中的門店基礎數據服務
三級__一般服務	99.9%（全年8.8小時不可用）	如外賣系統中的智能推薦
四級__工具服務	99%	非業務功能：比如後臺管理系統、運維工具

ps:

平均無故障時間（MTTF）
MTTF（mean time to failure），指模塊處在正常服務狀態的平均時間。
平均修復時間（MTTR）
MTTR（mean time to repair），指模塊處在服務中斷狀態的平均時間。

典型架構分層設計及各層實現高可用的原則

典型架構分層設計如下：按照功能處理順序劃分應用，這是面向業務深度的劃分。架構分層圖如下：

接入層：主要流量入口
應用層：直接對外提供產品功能，例如網站、API接口等。接入層不包含複雜的業務邏輯，只做呈現和轉換。
服務層：根據業務領域每個子域單獨一個服務。
數據層：數據庫和NoSQL，文件存儲、緩存等。

接入層高可用設計

接入層可能出現的問題：

dns被劫持：域名是否使用https。
黑客攻擊：是否有弱密，服務器權限，數據庫權限
ddos攻擊：是否有必要使用高防IP接入流量。
CC攻擊：免費和收費版域名分開，網關是否有限流和防刷措施。

高可用設計方案:

域名規範解析和規範化管理，應該制定《域名規範管理說明》，例如根據產品重要等級，制定使用高防ip的策略。
規範API管理。
明確各個API限流和防刷策略。

接入層高可用架構設計模式：

應用層高可用設計

接入層可能出現的問題：

應用服務器宕機。
應用服務bug。
第三方服務不可用。

應用層設計主要原則:

可以水平擴展：通過接入層的負載均衡，實現故障自動轉移。
無狀態設計：無狀態的系統更利於水平擴展，更利於做負載均衡。

狀態是系統的吞吐量、易用性、可用性、性能和可擴展性的大敵，要盡最大可能避免。
回滾設計：確保系統可以向後兼容，如果應用服務上線後出現bug，可以緊急回滾。
灰度發佈：結合接入層設計A/B 功能，實現灰度發佈，比如按ip，請求參數等分發流量。

服務層高可用設計

服務層可能出現的問題：

服務不可用或者出現bug
第三方服務不可用。
服務壓力過大，由於服務之間大規模的調用關係，會導致系統“雪崩”

服務層高可用設計方案:
服務層設計最主要原則：服務分級管理（核心服務、重要服務、一般服務、工具服務）

線上有很多服務，每個服務的可用性要求不一樣，我們需要先這些服務做分級。

1、各級服務的部署原則：核心服務：獨立服務器且N+1部署。三級和四級服務可以共享服務器部署。

2、各級服務上線發佈原則：核心和重要服務：晚上12點上線。，三級和四級隨時可上線

3、各級服務監控原則：

1、核心服務

核心服務設計滿足以下原則：

冗餘N+1部署：故障自動轉移到多部署一個節點，避免單點問題。
可監控：服務流量預警、端口存活、進程佔用的資源、服務接口功能邏輯是否正常，應用FGC等情況。
可回滾、灰度：灰度部署服務，部署的服務出現問題可快速回滾。
可獨立部署：可以直接在運維平臺打包部署，而不需要依賴其他服務部署完成後才能部署運行。
可獨立測試：可以單獨測試。
水平擴展：流量激增可快速擴容。
異步設計：服務需要通知第三方服務，必須通過消息隊列進行異步方式完成。
冪等設計：服務可以重複調用，不影響結果。

冪等廣義上一般指以相同參數調用同一個接口多次，對系統內部產生的影響是一致的。比如說進行支付時，如果一次扣款操作因爲某種原因調用了兩次，那麼理論上應該只生效一次，否則就會出現一定的風險。
舉例說明：
反例：
比如我們在購物網站選好東西后，進入支付頁面點擊支付，此時支付請求發送給銀行後端，然後從數據庫中成功扣除了金錢，並將成功扣錢的消息返回至前端，問題來了，如果在返回途中網絡發生異常，消息丟失，那麼前端將無任何反應，這體現在用戶身上很可能就是再次點擊“支付按鈕”進行支付！按照正常邏輯，此時支付請求發送給銀行後端後是不應該再次扣除金錢的，但由於HTTP協議的無狀態性，它不關心前一次是否扣除了金錢這個條件，只一視同仁地認定這一次是要扣除金錢的，所以最終必然會多扣一次錢！
可容錯：自身有容錯和修復能力：

1)、隔離手段：服務使用的資源（CPU、線程、IO等）隔離，使用艙壁模式；
2)、自我保護手段：快速失敗(failfast)、流控、超時、熔斷；
3)、失效轉移或恢復手段：失效檢測、重試、轉移(failover)、回退恢復（failback)；
4)、降級手段：依據依賴服務的重要性或依賴程度（強、弱）,同步變異步，降級開關、拒絕部分服務等。

2、重要服務

重要服務設計滿足以下原則：

冗餘N+1部署：故障自動轉移到多部署一個節點，避免單點問題。
可監控：監控進程、端口存活、進程佔用的資源，應用FGC等。
可回滾、灰度：灰度部署服務，部署的服務出現問題可快速回滾。
故障隔離：服務器只部署唯一該應用服務，該應用服務出現問題，隻影響自身服務問題。
可獨立部署：可以直接在運維平臺打包部署，而不需要依賴其他服務部署完成後才能部署運行。
可獨立測試：可以單獨測試。
水平擴展：流量激增可快速擴容。
可容錯：自身有容錯和修復能力。

3、一般服務

一般服務設計滿足以下原則：

可以接受單點部署。
可監控：可監控服務進程、端口存活是否正常。
可回滾、灰度：灰度部署服務，部署的服務出現問題可快速回滾。
4、故障隔離：一個服務器上可以部署多個應用，但保證服務器資源充足。
5、可獨立部署：需要獨立部署。
6、可獨立測試：可以單獨測試。
7、水平擴展：流量激增可快速擴容。
8、可容錯：需要具備一般的容錯能力。

4、工具服務

服務設計滿足以下原則：

1、冗餘N+1部署：可以單點部署，只要有個進程存活就可以。
2、可監控：不需要監控。
3、可回滾、灰度：只要部署成功就可以。
4、故障隔離：哪個服務器有資源就可以部署。
5、可獨立部署：不用考慮。
6、可獨立測試：不用考慮。
7、水平擴展：不用考慮。
8、可容錯：不用考慮。

服務與設計原則關係表：

服務類別	部署	監控	回滾、灰度	故障隔離	獨立部署	獨立測試	水平擴展	容錯	異步設計	冪等設計
核心服務	冗餘N+1部署：故障自動轉移到多部署一個節點，避免單點問題。	服務流量預警、端口存活、進程佔用的資源、服務接口功能邏輯是否正常，應用FGC等情況。	灰度部署服務，部署的服務出現問題可快速回滾。	未提及	可以直接在運維平臺打包部署，而不需要依賴其他服務部署完成後才能部署運行。	需要	需要	自身有容錯和修復能力	需要	需要
重要服務	⚡⚡	監控進程、端口存活、進程佔用的資源，應用FGC等	⚡⚡	服務器只部署唯一該應用服務，該應用服務出現問題，隻影響自身服務問題	⚡⚡	需要	需要	⚡⚡	不用考慮	不用考慮
一般服務	可以單點部署	監控服務進程、端口存活是否正常	⚡⚡	一個服務器上可以部署多個應用，但保證服務器資源充足	需要獨立部署	需要	需要	具備一般的容錯能力	不用考慮	不用考慮
工具服務	單點部署，只要有個進程存活就可以	不用考慮	只要部署成功就可以	哪個服務器有資源就可以部署	不用考慮	不用考慮	不用考慮	不用考慮	不用考慮	不用考慮

數據層的高可用設計

數據層可能出現的問題：
- 數據庫服務器磁盤損壞導致數據庫不可用等

數據架構設計原則：

保障高可用系統的技術方案

技術	解決的問題
擴展	通過冗餘部署，避免單點故障
隔離	避免業務之間的相互影響。機房隔離避免單點故障
解耦	減少依賴，減少相互間的影響
限流	遇到突發流量時，保證系統穩定
降級	犧牲非核心業務，保證核心業務的高可用
熔斷	減少不穩定的外部依賴對核心服務的影響
自動化測試	通過完善的測試，減少發佈引起的故障
灰度發佈	灰度發佈是速度與安全性作爲妥協，能夠有效減少發佈故障

擴展

擴展是最常見的提升系統可靠性的方法，系統的擴展可以避免單點故障，即一個節點出現了問題造成整個系統無法正常工作。換一個角度講，一個容易擴展的系統，能夠通過擴展來成倍的提升系統能力，輕鬆應對系統訪問量的提升。

一般地，擴展可以分爲垂直擴展和水平擴展：

垂直擴展：是在同一邏輯單元裏添加資源從而滿足系統處理能力上升的需求。比如，當機器內存不夠時，我們可以幫機器增加內存，或者數據存不下時，我們爲機器掛載新的磁盤。
垂直擴展能夠提升系統處理能力，但不能解決單點故障問題。
優點：擴展簡單。
缺點：擴展能力有限。
水平擴展：通過增加一個或多個邏輯單元，並使得它們像整體一樣的工作。
水平擴展通過冗餘部署解決了單點故障，同時又提升了系統處理能力。
優點：擴展能力強。
缺點：增加系統複雜度，維護成本高，系統需要是無狀態的、可分佈式的。

隔離

對系統、業務所佔有的資源進行隔離，限制某個業務對資源的佔用數量，避免一個業務佔用整個系統資源，對其他業務造成影響。
隔離級別按粒度從小到大，可以分爲線程池隔離、進程隔離、模塊隔離、應用隔離、機房隔離。在數據庫的使用中，還經常用到讀寫分離。

線程池隔離：不同的業務使用不同的線程池，避免低優先級的任務阻塞高優先級的任務。或者高優先級的任務過多，導致低優先級任務永遠不會執行。
進程隔離：Linux 中有用於進程資源隔離的 Linux CGroup，通過物理限制的方式爲進程間資源控制提供了簡單的實現方式，爲 Linux Container 技術、虛擬化技術的發展奠定了技術基礎。
模塊隔離、應用隔離：很多線上故障的發生源於代碼修改後，測試不到位導致。按照代碼或業務的易變程度來劃分模塊或應用，把變化較少的劃分到一個模塊或應用中，變化較多的劃分到另一個模塊或應用中。減少代碼修改影響的範圍，也就減少了測試的工作量，減少了故障出現的概率。
機房隔離：主要是爲了避免單個機房網絡問題或機房電源故障。
讀寫分離：一方面，將對實時性要求不高的讀操作，放到 DB 從庫上執行，有利於減輕 DB 主庫的壓力。另一方面，將一些耗時離線業務 sql 放到 DB 從庫上執行，能夠減少慢 sql 對 DB 主庫的影響，保證線上業務的穩定可靠。

解耦

在軟件架構設計中，模塊之間的解耦或者說鬆耦合有兩種，假設有兩個模塊A、B，A依賴B：

模塊A和模塊B只通過接口交互，只要接口設計不變，那麼模塊B內部細節的變化不影響模塊A對模塊B服務能力的消費。
將同步調用轉換成異步消息交互

比如在買機票系統中，機票支付完成後需要通知出票系統出票、代金券系統發券。如果使用同步調用，那麼出票系統、代金券系統宕機是會影響到機票支付系統。如果我們將同步調用替換成異步消息，機票支付系統發送機票支付成功的消息到消息中間件，出票系統、代金券系統從消息中間件訂閱消息。這樣一來，出票系統、代金券系統的宕機也就不會對機票支付系統造成任何影響了。

限流

一個系統的處理能力是有上限的，當服務請求量超過處理能力，通常會引起排隊，造成響應時間迅速提升。如果對服務佔用的資源量沒有約束，還可能因爲系統資源佔用過多而宕機。因此，爲了保證系統在遭遇突發流量時，能夠正常運行，需要爲你的服務加上限流。
限流分類：

按照計數範圍，可以分爲：單機限流、全侷限流。單機限流，一般是爲了應對突發流量，而全侷限流，通常是爲了給有限資源進行流量配額。
按照計數週期，可以分爲：QPS、併發（連接數）。
按照閾值設定方式的不同，可以分爲：固定閾值、動態閾值。

常見的限流算法有：漏桶算法、令牌桶算法、滑動窗口計數法。

降級

業務降級，是指犧牲非核心的業務功能，保證核心功能的穩定運行。要實現優雅的業務降級，需要將功能實現拆分到相對獨立的不同代碼單元，分優先級進行隔離。在後臺通過開關控制，降級部分非主流程的業務功能，減輕系統依賴和性能損耗，從而提升集羣的整體吞吐率。

簡單的說：當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運作或高效運作。

降級的重點是：業務之間有優先級之分，保證核心業務的執行。降級的典型應用是：電商活動期間關閉非核心服務，保證核心買買買業務的正常運行。

業務降級通常需要通過開關工作，開關一般做成配置放在專門的配置系統，配置的修改最好能夠實時生效，畢竟要是還得修改代碼發佈那就太 low 了。開源的配置系統有阿里的diamond、攜程的Apollo、百度的disconf。

降級往往需要兜底方案的配合，比如系統不可用的時候，對用戶進行提示，安撫用戶。提示雖然不起眼，但是能夠有效的提升用戶體驗。

微服務架構—服務降級

熔斷

在電力學中，當電流會不斷升高，負載過大，保險絲會熔斷切斷電流，從而起到保護電路安全運行的作用。此處熔斷的意思跟電力學的熔斷差不多。
在分佈式系統中，如果調用的遠程服務或者資源由於某種原因無法使用時，沒有這種過載保護，就會導致請求阻塞在服務器上等待從而耗盡服務器資源。很多時候剛開始可能只是系統出現了局部的、小規模的故障，然而由於種種原因，故障影響的範圍越來越大，最終導致了全局性的後果。而這種過載保護就是大家俗稱的熔斷器(Circuit Breaker)。

漫畫：什麼是服務熔斷

自動化測試

爲什麼自動化測試是構建高可用系統的技術方案？

衆所周知，一個項目上線前需要經歷嚴格的測試過程，但是隨着業務不斷迭代、系統日益複雜，研發工程師、產品經理、測試工程師等都在測試過程中投入了大量精力，而一個個線上故障卻表明測試效果並不是那麼完美。究其原因，目前的測試工作主要存在兩方面問題：

測試範圍難以界定：隨着業務邏輯的不斷迭代、系統的不斷拆分與細化，精確評估項目改動的影響範圍變得越來越困難，從而很難梳理出覆蓋全面的測試點。
case驗證成本過高：驗證一個case需要構造測試場景，包括數據的準備和運行環境的準備，當case量較大或者存在一些涉及多個系統模塊且觸發條件複雜的case時，這一過程也將花費大量的時間。

解決上述問題可以使用模塊級自動化測試。具體方案是：針對某一模塊，收集模塊線上的輸入、輸出、運行時環境等信息，在離線測試環境通過數據mock模塊線上場景，回放收集的線上輸入，相同的輸入比較測試場景與線上收集的輸出作爲測試結果。

灰度發佈&回滾

回滾。
一般在線上出現故障後，第一個要考慮的就是剛剛有沒有代碼發佈、配置發佈，如果有的話就先回滾。線上故障最重要的是快速恢復，如果等你細細看代碼找到問題，沒準兒半天就過去了。
灰度發佈基礎知識
灰度發佈： 是指在黑與白之間，能夠平滑過渡的一種發佈方式。在其上可以進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面來。灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
灰度期： 灰度發佈開始到結束期間的這一段時間，稱爲灰度期。
好處：
1. 提前獲得目標用戶的使用反饋；
2. 根據反饋結果，做到查漏補缺；
3. 發現重大問題，可回滾“舊版本”；
4. 補充完善產品不足；
5. 快速驗證產品的 idea。

背景監控&報警

監控系統，處於整個服務可靠度層級模型的最底層，是運維一個可靠的穩定系統必不可少的重要組成部分。

爲了保障全鏈路業務和系統高可用運行，需要在用戶感知問題之前發現系統中存在的異常，離開了監控系統，我們就沒有能力分辨客戶端是不是在正常提供服務。

按照監控的領域方向，可以分成系統監控與業務監控：

系統監控，主要用於基礎能力如端到端成功率，服務響應時長，網絡流量，硬件性能等相關的監控。系統監控側重在無業務侵入和定製系統級別的監控，更多側重在業務應用的底層，多屬於單系統級別的監控。
業務監控，側重在某個時間區間，業務的運行情況分析。業務監控系統構建於系統監控之上，可以基於系統監控的數據指標計算，並基於特定的業務介入，實現多系統之間的數據聯合與分析，並根據相應的業務模型，提供實時的業務監控與告警。

按照業務監控的時效性，可以繼續將其細分成實時業務監控與離線業務監控。

實時業務監控，通過實時的數據採集分析，幫助快速發現及定位線上問題，提供告警機制及介入響應（人工或系統）途徑，幫助避免發生系統故障。
離線的業務監控，對一定時間段收集的數據進行數據挖掘、聚合、分析，推斷出系統業務可能存在的問題，幫助進行業務上的重新優化或改進的監控。

拆分

水平拆分
如本文提到的架構分層設計就是水平拆分。架構分層
垂直拆分

根據功能垂直劃分，拆成相對獨立的模塊。有的僅是服務層做了拆分，存儲層共用。更爲徹底的是，拆分與該系統的業務領域模型關聯，一個領域模型劃分成一個模塊。在數據庫層面，還可以分庫分表拆分，這樣一個庫的損壞，不會影響到其他庫。分庫分表需要增加路由邏輯，及保證路由規則的一致性。

緩存

在高併發應用中，肯定避免不了數據的頻繁讀寫，這時候緩存就能夠起到很大作用了，一般會使用像Redis集羣這樣的高性能緩存，減少數據庫的頻繁讀取，以提高數據的查詢效率。

容災備份

容災系統，對於IT而言，就是爲計算機信息系統提供的一個能應付各種災難的環境。當計算機系統在遭受如火災、水災、地震、戰爭等不可抗拒的自然災難以及計算機犯罪、計算機病毒、掉電、網絡/通信失敗、硬件/軟件錯誤和人爲操作錯誤等人爲災難時，容災系統將保證用戶數據的安全性（數據容災），甚至，一個更加完善的容災系統，還能提供不間斷的應用服務（應用容災）。可以說，容災系統是數據存儲備份的最高層次。

數據庫高可用容災方案

劃重點(∩＿∩)

本人程序媛一枚，因爲離港澳較近，週末兼職港澳人肉代購。

歡迎各位大佬添加本人微信，還會經常有點贊活動送價值不菲的小禮品哦。

即使現在不需要代購，等以後有了女（男）朋友、有了寶寶就肯定會需要的嘍。

動動手指頭，掃碼一下，就當是對本博文的支持嘛，也是對一個平凡、勤勞、勇敢、秀外慧中等等優點的程序媛莫大的支持哈。

參考文獻（侵刪）：

高可用架構設計
 高可用系統的一些技術方案
 漫畫：什麼是服務熔斷
 微服務架構—服務降級
 美團2000萬日訂單背後，如何保障系統的高可用？
實現系統高可用，常用的解決手段
 高可用系統設計建議簡介
 高併發&高可用系統應對策略的一些思考
 如何保障高併發系統的穩定性與高可用

程序的高可用相關知識

文章目錄

含義