可伸缩架构-面向增长应用的高可用
可用性
可靠性：系統是否具備無差別的執行預期操作的能力。主要指標：是否通過了所有測試套件。 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 |
什么可能導致低可用性：
提高可用性的五個要點：
- 服務器監控
- 配置變化監控
- 應用程序性能監控
- 人為測試
- 報警
風險管理
風險管理就是在消除風險的成本與風險發生的成本(緩和風險)之間保持平衡。
風險緩和指的是通過降低風險發生的可能性或者降低風險發生時的嚴重性，來降低風險的影響。
風險的重要程度就會風險發生的嚴重性和可能性兩者之和。為了降低風險，至少需要降低其中之一。?
嚴重性：如果發生風險，所需付出的代價。
可能性：風險發生的幾率。?
管理系統風險的基本步驟：
風險模型的風險項：模版地址(http://bit.ly/architectbookdl)
風險模型的作用域：
維護風險模型：
風險模型最大挑戰就是人的惰性和模型本身對過時，需定期變換檢查風險模型對人員，可以有碰撞和嶄新對視角。
構建低風險系統的常用手段：
?微服務
為何要用微服務：
所有者收益：讓每個服務都有清晰的所有權，團隊可以只關注于他們負責的模塊，以及依賴服務的api約定。
規模收益：系統在不同模塊上的伸縮性需求不一樣。
如何決定服務的邊界：
服務故障的常見形式和解決方案
級聯式的服務故障：一個服務故障可能導致整個系統發生嚴重的問題。
對服務api的響應約定：
對服務api的請求約定：
?服務故障的應對：
微服務的伸縮性(保證兩個失誤的高度，即掛兩個節點的伸縮性)：
服務所有權的義務和權利：
服務分級：
1級服務 如果某個服務出現故障會導致用戶或者公司業務產生重大損失。 登錄服務，權限服務，訂單處理服務。
2級服務 如果某個服務發生故障，會導致用戶體驗顯著受到影響，但是不會導致無法使用你的系統。 搜索服務，訂單結算服務。?
3級服務 對用戶造成較小的不易注意到的影響，對系統造成有限的影響。用戶頭像服務，推薦服務，每日提醒服務。
4級服務 即使失敗也不會對用戶體驗造成任何嚴重的影響，也不會對業務和資金方有任何影響。 銷售報告服務，郵件發送服務。
使用服務分級：SLA服務等級協議
- 調用延遲
- 流量QPS
- 運行時長 ?一段時間的可用性
- 錯誤率
- 問題的嚴重性
- 出現問題的服務級別
- 關鍵依賴 ? 你的服務級別高于依賴服務的級別 ?自身服務在關鍵依賴故障時需仍然盡力提供功能
- 非關鍵依賴 ?你的服務級別低于依賴服務的級別 ?可以忽略你依賴的此服務的故障，因為此服務的可用性和響應性比你高。
ps:
排名SLA，tp90>20ms(前置條件相同的QPS下)
tp90：(抽樣總數*10%) ?需要排除的樣本數量 ? ?排除掉這么多的耗時最高的響應樣本
20ms：取剩下的樣本中耗時最高的響應時間
云服務?
區域：云資源相連形成的一大片地區成為區域，表示一個特定的地理區域。描述和記錄了云資源的地理拓撲多樣性，網絡拓撲多樣性。
可用區：一個區域包含多個可用區，表示一個區域指定部分的云資源。
數據中心：一個可用區包含多個數據中心。一個用來放置系統資源(例如服務器)的指定樓層，建筑物或者建筑群。
云資源分配：
- 根據業務特性，實際場景或者當前資源的使用情況調整分配。
- 預留容量，固定100臺的使用量，其他100臺的使用按小時計費。
各種基于云服務的應用程序運行環境：
?
?
?
?
?
?
?
總結
以上是生活随笔為你收集整理的可伸缩架构-面向增长应用的高可用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： VMware Converter P2V
- 下一篇： ERP软件的追加开发环节存在特殊价值