一、什麼是可用性

高可用性對於構建高可伸縮系統是一個極其重要的因素，那麼什麼是可用性，系統可用性和可靠性之間怎麼區分。數據庫

1.1可用性和可靠性

可靠性服務器
系統是否具有無差錯地執行預期操做的能力微信
可用性網絡
爲了執行可靠性，系統當前可運行的能力架構

金融支付系統最敏感的業務場景-資損，用戶完成一筆跨境收款，正常錢應該從跨境電商平臺資金帳戶A流轉到具有跨境收款能力的跨境支付的用戶虛卡帳戶B，可是因爲系統bug，錢流轉到了虛卡帳戶C，業務功能邏輯錯誤，表示可靠性很低；若是錢流轉到了虛卡帳戶B，可是永遠得不到結果，可用性就很低，可靠性能夠經過功能測試來修復，可是可靠性很難解決。異步

1.2 低可用性的架構驅動因子

資源耗盡分佈式
預期以外的壓力變化ide
流動行爲的增長微服務
外部依賴性能
技術債務

二、如何提高應用程序的可用性

時刻考慮應對故障

設計
依賴
用戶

時刻考慮如何伸縮

設計出可以增長數據庫數量和容量的架構
考慮限制你的數據伸縮的緣由
應用服務器可伸縮，服務狀態如何維護、如何路由流量
將靜態流量導向離線提供方
動態資源靜態化

緩和風險保持系統高可用須要消除系統中的風險，架構約束條件是要先肯定風險及風險分類，從系統思考角度考慮風險類別：

存在系統崩潰的風險
存在數據庫崩潰的風險
存在返回結果不正確的風險
存在網絡鏈接失敗的風險
存在新部署的軟件功能出現故障的風險

監控可用性

服務器監控
配置變化監控
應用程序性能監控
人爲測試
報警

以預測和肯定的方式來應對可用性問題

三、可用性可度量

測量可用性對保證系統高可用很是重要，任何一款APM系統或者自研的監控系統，都具有監控指標的可度量，只有度量才能實時的追蹤系統服務的運行軌跡。

一般可用性都會拿N個9來衡量，好比某跨境支付公司，號稱對外收款核心接口可以保證9999(4個9)的可用性，這是一個什麼概念，每個月只有4分鐘故障時間，見以下表格：

N個9	百分比	每個月故障時間
2個9	99%	432分鐘
3個9	999%	43分鐘
4個9	9999%	4分鐘
5個9	99999%	26秒
6個9	999999%	2.6秒

可用性誤區

可用性等級定義須要結合實際的業務場景
計劃中和平常維護致使系統的不可用也要計算到度量中

維護窗口可用性計算規則

業務接口可用性百分比=(該期間的總秒數-系統宕機的秒數)/該期間的總秒數

每週的小時數=7天*24小時=168小時

每週不可用的小時數=2小時

業務接口可用性(沒有故障)=(168小時-2小時)/168小時=98.8%

業務接口可用性(沒有故障)=98.8%

若是每週系統維護窗口時間爲2小時，那麼系統可用性都達不到最低標準2個9，這是是多麼的可怕。

四、服務分級

微服務架構、分佈式架構以及雲原生架構盛行，致使服務依賴關係複雜度加強，關鍵服務與非關鍵服務之間級聯故障致使相關服務的可用性極低，解決問題的關鍵是結合服務的業務場景進行服務分級。

4.1什麼是服務分級

服務分級實際上是與服務關聯的標籤，表示業務場景下，對於業務可用性的關鍵程度。

1級服務

1級服務是系統中最關鍵的服務，若是某個服務出現故障會致使用戶或者公司業務出現較大的損失

例如：用戶服務、匯兌服務、出金和入金服務、vat付款等

2級服務

2級服務對於業務很是重要，可是關鍵性不如1級服務，2級服務只會影響用戶體驗

例如：訂單搜索服務、訂單結算服務等

3級服務

3級服務會對業務系統形成較小的影響，不容易注意到

例如：用戶頭像服務、推薦服務和站內信等

4級服務

4級服務是對業務不會形成任何影響

例如：異步郵件或者短信提醒服務等

五、使用服務分級

如何使用已經達成一致的服務分級，通常會從以下維護考慮

指望
管理服務指望的一種手段就是SLA(服務等級協議)
響應性
系統故障的響應性的關鍵決策因素：故障的嚴重性、出現故障的服務級別。
依賴響應性動態調整系統策略：

報警通知
指望的SLA
對於低優先級問題的上報路徑
提供響應的時間安排(24*7或僅辦公時間)
是否提供緊急部署或者產品更改
根據服務的可用性和響應性制定SLA

依賴

關鍵依賴
若是你的服務級別高於(數字小於)依賴服務的級別那麼這個服務就是關鍵依賴，不能忽略依賴服務的故障，必須考慮服務降級，盡最大可能保證服務的可用性和可靠性，依賴服務的服務級別比較低，可用性和可靠性比較低
非關鍵依賴
若是你的服務級別低於(數字大於)依賴服務的級別那麼這個服務就是非關鍵依賴，可用忽略依賴服務的故障。

六、服務等級協議(SLA)

服務等級協議是團隊和服務全部者之間的協議，提供了一個溝通服務間指望的機制。

6.1 服務等級協議定義

服務等級協議是一個提供某種級別可靠性和性能的承諾，它們用來在服務全部者和用戶之間建立一個牢固的合約關係。

SLA須要結合具體服務的業務場景，和利益相關者協商服務之間的指望，好比可用性、性能、產品功能等

6.2 SLA性能檢測

調用延遲
流量
運行時長
錯誤率

6.3 SLA閾值

SLA必需要設定閾值，好比RT<20ms等

6.4 SLA排名

好比TP90（百分之90的請求的RT低於20ms）、TP95（百分之95的請求的RT低於20ms）、TP80

（百分之80的請求的RT低於20ms）

6.5 延遲分組

好比某個服務在必定流量下，能夠保持必定的延遲，好比當TPS<250k 調用延遲TP90<25毫秒，當TPS>=250k 且小於 400k 調用延遲TP90<30毫秒。

七、處理服務故障

在構建大型基於微服務(分佈式服務或者雲原生服務)的系統時，如何處理服務故障是一個必需要解決的前置條件，服務越多，服務出現故障的可能性就越大，依賴於故障服務的其餘服務數據也會愈來愈多。

級聯式的服務故障

依賴的服務發生故障會影響可用性，能夠說業務團隊幾乎天天都在忍受或者着手解決這些故障，由於誰也不能保障咱們所依賴的服務何時會掛，不少業務團隊也沒這個經歷去梳理這個問題，不少都是被動的等故障發生，而後在作局部的修改，規避故障問題，其實問題的解決是有不少方法論技巧的。

如何響應服務故障

面對服務故障，技術開發人員如何響應很關鍵，響應服務故障必須具有以下前置條件：

可預測的
擁有可預測的故障響應式當前服務可以依賴其餘服務的一個重要指標，可預測的響應，要求當前服務必須具有統一吃的異常錯誤碼機制，若是依賴的服務給了一個不可預測的響應，當前服務必須給一個合理的響應，保證請求鏈路故障的可溯源。
可理解的
響應故障必須知足雙方的錯誤處理契約，也就是錯誤碼必須可以識別。
對當前場景是合理的
合理並具有業務意義的響應，便於問題定位。

如何肯定故障

亂碼響應
表示致命錯誤發生的響應
結果能夠理解可是所需的結果不匹配
結果超出預期範圍
沒有接收到響應
接收響應很慢

如何解決故障

優雅降級
優雅補償
儘早失敗

基於高可用的可伸縮架構方法論生態