可靠性：系統是否具備無差別的執行預期操作的能力。主要指標：是否通過了所有測試套件。 3+2=6 不可靠
可用性：為了執行這些操作，系統當前可執行的能力。主要指標：是否能進行響應。
測量可用性公式：**可用性百分比=(該期間的總秒數－系統宕機的秒數)/該期間的總秒數
n個9百分比
每月的故障時間
2個999%
432m
3個999.9%
43m4個9
99.99%
4m5個9
99.999%
26s6個9
99.9999%
2.6s
什麼可能導致低可用性：
資源耗盡 io&網路&記憶體等
預期之外的壓力變化 黑客攻擊，突發事件流量
流動行為的增加 一次上線協作的人越來越多，發生失誤的概率也就越大
外部依賴 外部的資源是否可用可靠的影響
技術債務 對已知bug未修復的累計，未知bug的隱患，新需求的合理性問題
提高可用性的五個要點：
時刻考慮應對故障
時刻考慮如何伸縮
緩和風險 即使服務和資源無法不可用時，依然確保系統以最好的最完整的狀態工作
監控可用性
以可預期及明確的方式來處理可用性問題
風險管理就是在消除風險的成本與風險發生的成本(緩和風險)之間保持平衡。
風險緩和指的是通過降低風險發生的可能性或者降低風險發生時的嚴重性，來降低風險的影響。
風險的重要程度就會風險發生的嚴重性和可能性兩者之和。為了降低風險，至少需要降低其中之一。
嚴重性：如果發生風險，所需付出的代價。
可能性：風險發生的機率。
管理系統風險的基本步驟：
識別風險 建立系統已知風險列表即風險模型。
消除風險 找出需要解決的風險，制定解決計畫
風險緩和 制定緩和計畫降低風險發生的可能性和嚴重性
定期檢查 定期檢查風險模型，更新計畫
風險id：每個風險的唯一標識。
系統：風險所屬系統或者子系統或者模組的名稱。
所有人：風險負責人抑或團隊，負責制定風險的緩和計畫和解決計畫。
風險描述：風險的概要描述，便於檢視和領會。
標識日期：該風險入模型的日期。
可能性：分高中低。
嚴重性：分高中低。
風險緩和計畫：正在使用的或者已商定的用來降低該風險嚴重性和可能性的措施和策略。
狀態：該風險當前的狀態。活躍，已緩和，正在修復，已解決等。
eta：該風險預估解決日期。
監控：是否對該風險進行了監控，監控方式策略，譬如人為監控，每週定位。自動監控，日誌觸發。
觸發計畫：此風險發生後，是否有計畫處理此風險。時間響應文件，應急手冊等。
備註：記錄風險對演化歷史，以便於回溯。
跟蹤id：需求或者bug id。
風險模型的作用域：
團隊管理
公司戰略
系統模組
個人售後支援
安全威脅
維護風險模型：
風險模型最大挑戰就是人的惰性和模型本身對過時，需定期變換檢查風險模型對人員，可以有碰撞和嶄新對視角。
發現新風險
刪除舊風險
更新可能性和嚴重性
檢查優先順序高的風險 計畫是否生效 當前狀態和頻率
檢查優先順序低的風險
構建低風險系統的常用手段：
冗餘 增強可用性
冪等 降低出錯的概率
獨立性 冗餘後卻都部署在乙個機房就不具備獨立性
安全 攻擊，誤操作等
自修復 集群 主備切換等
運維流程 保持指令碼自動化 可追溯 可重現 減少人為的參與
為何要用微服務：
所有者收益：讓每個服務都有清晰的所有權，團隊可以只關注於他們負責的模組，以及依賴服務的api約定。
規模收益：系統在不同模組上的伸縮性需求不一樣。
如何決定服務的邊界：
特定的業務需求 監管 信用卡等業務
清晰獨立的團隊所有權 負責該功能的團隊是否清晰和獨立，在不同城市不同樓層能否幫助確定服務邊界
天然的隔離的資料 其管理的資料是否天然與其他資料相獨立？
共享的能力和資料 是否需要被其他模組共享？代辦，訊息等。
服務故障的常見形式和解決方案
級聯式的服務故障：乙個服務故障可能導致整個系統發生嚴重的問題。
對服務api的響應約定：
可**的 返回錯誤提示資訊
可理解的 格式和結構要穩定和統一
對當前情形是合理的 需要的是可刪除的使用者，因為錯誤，不能返回全部使用者，應當返回無或者無法返回結果。
對服務api的請求約定：
服務約束 服務的能力範圍，入參的合法性約束
qps 服務所能提供的最高併發請求數
服務故障的應對：
優雅降級 不重要的服務可選擇提供有限的功能，捨棄故障服務提供的資料
優雅補償 搜尋銷量前十的服務故障，可返還最流行的前十的資料
盡早失敗 核心的依賴服務故障或者輸入引數不合法，自身的服務在注定會失敗的前提下盡早失敗。
微服務的伸縮性(保證兩個失誤的高度，即掛兩個節點的伸縮性)：
丟失乙個節點 qps會不會爆
公升級或者重啟乙個節點(輪流部署) 公升級中丟乙個節點qps會不會爆
資料中心的冗餘和恢復 乙個中心可能有多個節點 即也須考慮多個中心的伸縮性 資料中心越多每個資料中心所需的節點越少
隱藏的共享故障 機架停電 城市斷電
服務所有權的義務和權利：
api設計 api的設計實現測試和版本管理工作
服務開發 業務邏輯的設計開發和測試
資料 資料展現，模型，訪問方式以及生命週期
部署 負責決定服務是否需要公升級以及部署
部署視窗 決定什麼時間可以進行安全部署
產品變更 負載均衡器的設定和系統調優
環境 管理服務的生產環境以及所有環境
服務sla 討論確定並監控sla，以及保障服務滿足sla的相關工作職責
監控 監控sla io cpu等
值班/突發事件響應 確保突發事件的響應速度能滿足之前定的sla
報告 向外部傳送內部報告，以及服務的執行健康報告。
服務分級：
1級服務 如果某個服務出現故障會導致使用者或者公司業務產生重大損失。 登入服務，許可權服務，訂單處理服務。
2級服務 如果某個服務發生故障，會導致使用者體驗顯著受到影響，但是不會導致無法使用你的系統。 搜尋服務，訂單結算服務。
4級服務 即使失敗也不會對使用者體驗造成任何嚴重的影響，也不會對業務和資金方有任何影響。 銷售報告服務，郵件傳送服務。
使用服務分級：sla服務等級協議
期望 對這個級數的服務的期望，可成為溝通語言的一部分，描述使用者對系統的期待(外部sla)，服務呼叫方對服務提供方的要求(內部sla)
響應性 對這個級數的服務的響應性要求
依賴 依賴的梳理歸類
ps:排名sla，tp90>20ms(前置條件相同的qps下)
tp90：(抽樣總數*10%) 需要排除的樣本數量 排除掉這麼多的耗時最高的響應樣本
20ms：取剩下的樣本中耗時最高的響應時間
區域：雲資源相連形成的一大片地區成為區域，表示乙個特定的地理區域。描述和記錄了雲資源的地理拓撲多樣性，網路拓撲多樣性。
可用區：乙個區域包含多個可用區，表示乙個區域指定部分的雲資源。
資料中心：乙個可用區包含多個資料中心。乙個用來放置系統資源(例如伺服器)的指定樓層，建築物或者建築群。
雲資源分配：
基於固定額度的資源分配，指定例項的數量，伺服器的大小等。
基於使用量的分配，可按儲存和傳輸的資料量來計費。
各種基於雲服務的應用程式執行環境：
雲伺服器 比較基礎的伺服器技術
動態容器 動態分配資源，在不同伺服器中遷移容器。包裝了完整的伺服器功能，提供了快速啟動停止服務以及遷移服務到新系統的能力。 譬如docker
微計算 體積小，高度可擴充套件，基於事件驅動的執行環境。 譬如aws lambda。
重磅 《高可用可伸縮微服務架構》預售了
近年來微服務架構已經成為大規模分布式架構的主流技術，越來越多的公司已經或開始轉型為微服務架構。高可用可伸縮微服務架構 基於dubbo spring cloud和service mesh 不以某一種微服務框架的使用為主題，而是對整個微服務生態進行系統性的講解，並結合工作中的大量實戰案例為讀者呈現一本讀...
高可用集群架構的演進
我們專案組是做企業資料匯流排的，一開始的架構是採用apache httpd mod jk 做負載均衡，應用則部署在tomcat集群上面，該架構方案雖然考慮了tomcat容器級別的高可用，但並未考慮httpd的高可用，該方案的拓撲圖如下 該方案的缺點顯而易見，一旦httpd宕機，使用者將無法訪問應用，...
高效能，高可用，安全的架構
高效能 rt reponse time 時間 高可用 任何時候專案都必須可用 可公升縮 大促，流量瞬間增大 可擴充套件 開發角度 新需求進行迭代 擴充套件 安全性 網路安全，硬體安全，軟體安全 敏捷性 可持續交付，可持續部署 什麼是高效能？較短的響應時間 較大的併發處理能力 較高的吞吐量與穩定的效能...