可用性

可靠性：系統是否具備無差別的執行預期操作的能力。主要指標：是否通過了所有測試套件。 3+2=6 ?不可靠

可用性：為了執行這些操作，系統當前可運行的能力。主要指標：是否能進行響應。

測量可用性公式：網站可用性百分比=(該期間的總秒數－系統宕機的秒數)/該期間的總秒數

N個9	百分比	每月的故障時間
2個9	99%	432m
3個9	99.9%	43m
4個9	99.99%	4m
5個9	99.999%	26s
6個9	99.9999%	2.6s

什么可能導致低可用性：

資源耗盡　　io&網絡&內存等

預期之外的壓力變化　　黑客攻擊，突發事件流量

流動行為的增加　　一次上線協作的人越來越多，發生失誤的概率也就越大

外部依賴　　外部的資源是否可用可靠的影響

技術債務　　對已知bug未修復的累計，未知bug的隱患，新需求的合理性問題

提高可用性的五個要點：

?時刻考慮應對故障

時刻考慮如何伸縮

緩和風險　　即使服務和資源無法不可用時，依然確保系統以最好的最完整的狀態工作

監控可用性　　

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

以可預期及明確的方式來處理可用性問題

風險管理

風險管理就是在消除風險的成本與風險發生的成本(緩和風險)之間保持平衡。

風險緩和指的是通過降低風險發生的可能性或者降低風險發生時的嚴重性，來降低風險的影響。

風險的重要程度就會風險發生的嚴重性和可能性兩者之和。為了降低風險，至少需要降低其中之一。?

嚴重性：如果發生風險，所需付出的代價。

可能性：風險發生的幾率。?

管理系統風險的基本步驟：

識別風險　　創建系統已知風險列表即風險模型。

消除風險　　找出需要解決的風險，制定解決計劃

風險緩和　　制定緩和計劃降低風險發生的可能性和嚴重性

定期檢查　　定期檢查風險模型，更新計劃?

風險模型的風險項：模版地址(http://bit.ly/architectbookdl)

風險ID：每個風險的唯一標識。

系統：風險所屬系統或者子系統或者模塊的名稱。

所有人：風險負責人抑或團隊，負責制定風險的緩和計劃和解決計劃。

風險描述：風險的概要描述，便于查看和領會。

標識日期：該風險入模型的日期。

可能性：分高中低。

嚴重性：分高中低。

風險緩和計劃：正在使用的或者已商定的用來降低該風險嚴重性和可能性的措施和策略。

狀態：該風險當前的狀態。活躍，已緩和，正在修復，已解決等。

ETA：該風險預估解決日期。

監控：是否對該風險進行了監控，監控方式策略，譬如人為監控，每周定位。自動監控，日志觸發。

觸發計劃：此風險發生后，是否有計劃處理此風險。時間響應文檔，應急手冊等。

備注：記錄風險對演化歷史，以便于回溯。

跟蹤ID：需求或者bug ID。

風險模型的作用域：

團隊管理

公司戰略

系統模塊

個人

售后支持

安全威脅

維護風險模型：

風險模型最大挑戰就是人的惰性和模型本身對過時，需定期變換檢查風險模型對人員，可以有碰撞和嶄新對視角。

發現新風險

刪除舊風險

更新可能性和嚴重性

檢查優先級高的風險　　計劃是否生效 ?當前狀態和頻率

檢查優先級低的風險

構建低風險系統的常用手段：

冗余　　增強可用性

冪等　　降低出錯的概率

獨立性　　冗余后卻都部署在一個機房就不具備獨立性

安全　　攻擊，誤操作等

自修復　　集群 主備切換等

運維流程　　保持腳本自動化 ?可追溯 可重現 減少人為的參與　　?

?微服務

為何要用微服務：

所有者收益：讓每個服務都有清晰的所有權，團隊可以只關注于他們負責的模塊，以及依賴服務的api約定。

規模收益：系統在不同模塊上的伸縮性需求不一樣。

如何決定服務的邊界：

特定的業務需求　　 監管 信用卡等業務

清晰獨立的團隊所有權　　負責該功能的團隊是否清晰和獨立，在不同城市不同樓層能否幫助確定服務邊界

天然的隔離的數據　　其管理的數據是否天然與其他數據相獨立？

共享的能力和數據?　　是否需要被其他模塊共享？代辦，消息等。

服務故障的常見形式和解決方案

級聯式的服務故障：一個服務故障可能導致整個系統發生嚴重的問題。

對服務api的響應約定：

可預測的　　返回錯誤提示信息

可理解的　　格式和結構要穩定和統一

對當前情形是合理的　　需要的是可刪除的用戶，因為錯誤，不能返回全部用戶，應當返回無或者無法返回結果。

對服務api的請求約定：

服務約束　　服務的能力范圍，入參的合法性約束

QPS　　服務所能提供的最高并發請求數

?服務故障的應對：

優雅降級　　不重要的服務可選擇提供有限的功能，舍棄故障服務提供的數據

優雅補償　　搜索銷量前十的服務故障，可返還最流行的前十的數據

盡早失敗　　核心的依賴服務故障或者輸入參數不合法，自身的服務在注定會失敗的前提下盡早失敗。?

微服務的伸縮性(保證兩個失誤的高度，即掛兩個節點的伸縮性)：

丟失一個節點　　QPS會不會爆

升級或者重啟一個節點(輪流部署)　　升級中丟一個節點QPS會不會爆

數據中心的冗余和恢復　　一個中心可能有多個節點 ?即也須考慮多個中心的伸縮性 ? 數據中心越多每個數據中心所需的節點越少

隱藏的共享故障　　機架停電 ?城市斷電

服務所有權的義務和權利：

API設計　　api的設計實現測試和版本管理工作

服務開發　　業務邏輯的設計開發和測試

數據　　數據展現，模型，訪問方式以及生命周期

部署　　負責決定服務是否需要升級以及部署

部署窗口　　決定什么時間可以進行安全部署

產品變更　　負載均衡器的設置和系統調優

環境　　管理服務的生產環境以及所有環境

服務SLA　　討論確定并監控SLA，以及保障服務滿足SLA的相關工作職責

監控　　監控SLA IO CPU等

值班/突發事件響應　　確保突發事件的響應速度能滿足之前定的SLA

報告　　向外部發送內部報告，以及服務的運行健康報告。

服務分級：

1級服務　　如果某個服務出現故障會導致用戶或者公司業務產生重大損失。 登錄服務，權限服務，訂單處理服務。

2級服務　　如果某個服務發生故障，會導致用戶體驗顯著受到影響，但是不會導致無法使用你的系統。 搜索服務，訂單結算服務。?

3級服務　　對用戶造成較小的不易注意到的影響，對系統造成有限的影響。用戶頭像服務，推薦服務，每日提醒服務。

4級服務　　即使失敗也不會對用戶體驗造成任何嚴重的影響，也不會對業務和資金方有任何影響。 銷售報告服務，郵件發送服務。

使用服務分級：SLA服務等級協議

期望　　對這個級數的服務的期望，可成為溝通語言的一部分，描述用戶對系統的期待(外部SLA)，服務調用方對服務提供方的要求(內部SLA)

• 調用延遲
• 流量QPS
• 運行時長 ?一段時間的可用性
• 錯誤率

響應性　　對這個級數的服務的響應性要求

• 問題的嚴重性
• 出現問題的服務級別

依賴?　　依賴的梳理歸類

• 關鍵依賴 ? 你的服務級別高于依賴服務的級別 ?自身服務在關鍵依賴故障時需仍然盡力提供功能
• 非關鍵依賴 ?你的服務級別低于依賴服務的級別 ?可以忽略你依賴的此服務的故障，因為此服務的可用性和響應性比你高。

ps:

排名SLA，tp90>20ms(前置條件相同的QPS下)

tp90：(抽樣總數*10%) ?需要排除的樣本數量 ? ?排除掉這么多的耗時最高的響應樣本

20ms：取剩下的樣本中耗時最高的響應時間

云服務?

區域：云資源相連形成的一大片地區成為區域，表示一個特定的地理區域。描述和記錄了云資源的地理拓撲多樣性，網絡拓撲多樣性。

可用區：一個區域包含多個可用區，表示一個區域指定部分的云資源。

數據中心：一個可用區包含多個數據中心。一個用來放置系統資源(例如服務器)的指定樓層，建筑物或者建筑群。

云資源分配：

基于固定額度的資源分配，指定實例的數量，服務器的大小等。

• 根據業務特性，實際場景或者當前資源的使用情況調整分配。
• 預留容量，固定100臺的使用量，其他100臺的使用按小時計費。

基于使用量的分配，可按存儲和傳輸的數據量來計費。

各種基于云服務的應用程序運行環境：

云服務器　　比較基礎的服務器技術

計算分片　　與服務器獨立的計算環境中以托管的方式運行應用程序。 譬如google app engine

動態容器　　動態分配資源，在不同服務器中遷移容器。包裝了完整的服務器功能，提供了快速啟動停止服務以及遷移服務到新系統的能力。 譬如docker

微計算　　體積小，高度可擴展，基于事件驅動的運行環境。 譬如aws lambda。

?

?

?

?

?

?

?

總結

以上是生活随笔為你收集整理的可伸缩架构-面向增长应用的高可用的全部內容，希望文章能夠幫你解決所遇到的問題。

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