可伸縮架構-面向增加應用的高可用

可用性

可靠性：系統是否具有無差異的執行預期操做的能力。主要指標：是否經過了全部測試套件。 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

什麼可能致使低可用性：

1. 資源耗盡　　io&網絡&內存等
2. 預期以外的壓力變化　　黑客攻擊，突發事件流量
3. 流動行爲的增長　　一次上線協做的人愈來愈多，發生失誤的機率也就越大
4. 外部依賴　　外部的資源是否可用可靠的影響
5. 技術債務　　對已知bug未修復的累計，未知bug的隱患，新需求的合理性問題

提升可用性的五個要點：

1.  時刻考慮應對故障
2. 時刻考慮如何伸縮
3. 緩和風險　　即便服務和資源沒法不可用時，依然確保系統以最好的最完整的狀態工做
4. 監控可用性　　
   • 服務器監控
   • 配置變化監控
   • 應用程序性能監控
   • 人爲測試
   • 報警　　
5. 以可預期及明確的方式來處理可用性問題

風險管理

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

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

風險的重要程度就會風險發生的嚴重性和可能性二者之和。爲了下降風險，至少須要下降其中之一。 

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

可能性：風險發生的概率。 

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

1. 識別風險　　建立系統已知風險列表即風險模型。
2. 消除風險　　找出須要解決的風險，制定解決計劃
3. 風險緩和　　制定緩和計劃下降風險發生的可能性和嚴重性
4. 按期檢查　　按期檢查風險模型，更新計劃 

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

1. 風險ID：每一個風險的惟一標識。
2. 系統：風險所屬系統或者子系統或者模塊的名稱。
3. 全部人：風險負責人抑或團隊，負責制定風險的緩和計劃和解決計劃。
4. 風險描述：風險的概要描述，便於查看和領會。
5. 標識日期：該風險入模型的日期。
6. 可能性：分高中低。
7. 嚴重性：分高中低。
8. 風險緩和計劃：正在使用的或者已商定的用來下降該風險嚴重性和可能性的措施和策略。
9. 狀態：該風險當前的狀態。活躍，已緩和，正在修復，已解決等。
10. ETA：該風險預估解決日期。
11. 監控：是否對該風險進行了監控，監控方式策略，譬如人爲監控，每週定位。自動監控，日誌觸發。
12. 觸發計劃：此風險發生後，是否有計劃處理此風險。時間響應文檔，應急手冊等。
13. 備註：記錄風險對演化歷史，以便於回溯。
14. 跟蹤ID：需求或者bug ID。

風險模型的做用域：

1. 團隊管理
2. 公司戰略
3. 系統模塊
4. 我的
5. 售後支持
6. 安全威脅

維護風險模型：

風險模型最大挑戰就是人的惰性和模型自己對過期，需按期變換檢查風險模型對人員，能夠有碰撞和嶄新對視角。

1. 發現新風險
2. 刪除舊風險
3. 更新可能性和嚴重性
4. 檢查優先級高的風險　　計劃是否生效  當前狀態和頻率
5. 檢查優先級低的風險

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

1. 冗餘　　加強可用性
2. 冪等　　下降出錯的機率
3. 獨立性　　冗餘後卻都部署在一個機房就不具有獨立性
4. 安全　　攻擊，誤操做等
5. 自修復　　集羣 主備切換等
6. 運維流程　　保持腳本自動化  可追溯 可重現 減小人爲的參與　　 

 微服務

爲什麼要用微服務：

全部者收益：讓每一個服務都有清晰的全部權，團隊能夠只關注於他們負責的模塊，以及依賴服務的api約定。

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

如何決定服務的邊界：

1. 特定的業務需求　　 監管 信用卡等業務
2. 清晰獨立的團隊全部權　　負責該功能的團隊是否清晰和獨立，在不一樣城市不一樣樓層可否幫助肯定服務邊界
3. 自然的隔離的數據　　其管理的數據是否自然與其餘數據相獨立？
4. 共享的能力和數據 　　是否須要被其餘模塊共享？代辦，消息等。

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

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

對服務api的響應約定：

1. 可預測的　　返回錯誤提示信息
2. 可理解的　　格式和結構要穩定和統一
3. 對當前情形是合理的　　須要的是可刪除的用戶，由於錯誤，不能返回所有用戶，應當返回無或者沒法返回結果。

對服務api的請求約定：

1. 服務約束　　服務的能力範圍，入參的合法性約束
2. QPS　　服務所能提供的最高併發請求數

 服務故障的應對：

1. 優雅降級　　不重要的服務可選擇提供有限的功能，捨棄故障服務提供的數據
2. 優雅補償　　搜索銷量前十的服務故障，可返還最流行的前十的數據
3. 儘早失敗　　核心的依賴服務故障或者輸入參數不合法，自身的服務在註定會失敗的前提下儘早失敗。 

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

1. 丟失一個節點　　QPS會不會爆
2. 升級或者重啓一個節點(輪流部署)　　升級中丟一個節點QPS會不會爆
3. 數據中心的冗餘和恢復　　一箇中心可能有多個節點  即也須考慮多箇中心的伸縮性   數據中心越多每一個數據中心所需的節點越少
4. 隱藏的共享故障　　機架停電  城市斷電

服務全部權的義務和權利：

1. API設計　　api的設計實現測試和版本管理工做
2. 服務開發　　業務邏輯的設計開發和測試
3. 數據　　數據展示，模型，訪問方式以及生命週期
4. 部署　　負責決定服務是否須要升級以及部署
5. 部署窗口　　決定什麼時間能夠進行安所有署
6. 產品變動　　負載均衡器的設置和系統調優
7. 環境　　管理服務的生產環境以及全部環境
8. 服務SLA　　討論肯定並監控SLA，以及保障服務知足SLA的相關工做職責
9. 監控　　監控SLA IO CPU等
10. 值班/突發事件響應　　確保突發事件的響應速度能知足以前定的SLA
11. 報告　　向外部發送內部報告，以及服務的運行健康報告。

服務分級：

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

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

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

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

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

1. 指望　　對這個級數的服務的指望，可成爲溝通語言的一部分，描述用戶對系統的期待(外部SLA)，服務調用方對服務提供方的要求(內部SLA)
   • 調用延遲
   • 流量QPS
   • 運行時長  一段時間的可用性
   • 錯誤率
2. 響應性　　對這個級數的服務的響應性要求
   • 問題的嚴重性
   • 出現問題的服務級別
3. 依賴 　　依賴的梳理歸類
   • 關鍵依賴   你的服務級別高於依賴服務的級別  自身服務在關鍵依賴故障時需仍然盡力提供功能
   • 非關鍵依賴  你的服務級別低於依賴服務的級別  能夠忽略你依賴的此服務的故障，由於此服務的可用性和響應性比你高。

ps:

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

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

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

雲服務 

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

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

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

雲資源分配：

1. 基於固定額度的資源分配，指定實例的數量，服務器的大小等。
   • 根據業務特性，實際場景或者當前資源的使用狀況調整分配。
   • 預留容量，固定100臺的使用量，其餘100臺的使用按小時計費。
2. 基於使用量的分配，可按存儲和傳輸的數據量來計費。

各類基於雲服務的應用程序運行環境：

1. 雲服務器　　比較基礎的服務器技術
2. 計算分片　　與服務器獨立的計算環境中以託管的方式運行應用程序。 譬如google app engine
3. 動態容器　　動態分配資源，在不一樣服務器中遷移容器。包裝了完整的服務器功能，提供了快速啓動中止服務以及遷移服務到新系統的能力。 譬如docker
4. 微計算　　體積小，高度可擴展，基於事件驅動的運行環境。 譬如aws lambda。