硬件 => CDN =>DNS =>接入層=>邏輯層=>數據層=>緩存層=>安全=>監控=>質量保證=>性能定位分析 =>案例
什麼是架構的高可用
架構高可用重要性
架構高可用的手段都有哪些
架構高可用評價維度是什麼
架構高可用的如何分級&考覈
架構高可用的涉及環節
典型問題你遇到過嗎？緩存
什麼是軟件架構安全
系統架構兩大要素網絡
各個組件架構
組件見得相關關係併發
什麼是好的軟件架構負載均衡
成本最低運維
知足用戶需求（未來的功能需求）異步
系統穩定性好性能
架構足夠靈活網站
數據量維度
併發量維度（同步和異步）
部署運維維度
什麼是壞的架構
成本高
系統複雜，笨重
系統不穩定
常常發生故障
系統擴展性差
系統維護性差
維護代價高
軟件架構高可用性
1、系統運行依賴的基礎
硬件
機器，CPU，內存，硬盤，網卡
軟件
操做系統
文件系統
軟件自己
系統運行依賴的基礎不可用性
硬件
生命週期，硬件故障
軟件
軟件bugs
軟件間資源的爭搶
軟件架構高可用
任什麼時候間都正常提供讀寫服務
7*24
機器硬件故障
-cpu，內存，硬件，網卡
機器軟件故障
-os，fileSystem
網絡劃分
-機器間網絡隔離
-網絡弱可用
高可用架構的重要性
-業務快速發展的支持
-系統不可用，系統頻繁故障、系統不穩定
用戶體驗差，用戶留不住
精力放在系統穩定性方面
無精力響應業務功能需求
-系統不可用，公司品牌、形象受影響
2011年4月12日，亞馬遜雲計算服務EC2宕機半天
貴公司有不可用的案例嗎？
架構高可用的重要性
-系統不可用，公司利益
2010年1月12日，百度DNS被劫持
經濟損失百萬到！！
宕機時間==損失收入（金錢）
-沒有系統高可用，談其餘一切都是扯淡
架構高可用的重要性
架構高可用手段
設計無狀態化
子系統冗餘
冪等性設計
異步調用
避免一個服務失敗致使的整個服務失敗
超時機制
分級管理（核心系統，非核心監控）
服務降級
架構高可用的手段
服務治理
進程
語義
錯誤
coredump
數據波動
-。。
服務可管理、可視化
日誌監控系統
架構高可用評價維度
系統在面對各類異常時，能夠提供正常服務的能力
系統的可用性能夠用系統停服的時間和正常服務時間的比例來衡量
系統不可用時間（故障時間=故障修復時間點-故障發現時間點）
4個9的可用性（99.99%）
一年停機時間不能超過53分鐘
365*24*60/10000=53分鐘
架構高可用評價維度是什麼？
架構高可用評價維度
2個9的可用性（99%）
基本可用
一年停機的時間不能超過88個小時
365*24*60/100=88個小時
-3個99的可用性（99.9%）
較高可用性
一年停機時間不能超過9個小時
365*24*60/1000=9個小時
5個99的可用性（99.999%）（Google沒有作到）
極高可用性
一年停機的時間不能超過5分鐘
365*24*60/100000=5分鐘
架構高可用評價維度
加多的網站可用性不足2個9
--88個小時
Twitter網站
一目標
作到4個9
具有自動恢復能的高可用
架構高可用涉及的環節
架構關鍵節點層面
負載均衡
軟件質量保證
預發佈
灰度發佈
安全
監控
回滾方案
線上問題定位分析
高可用架構遇到問題
上線發生數據改動，格式和以前的不兼容，回滾也不正常，如何處理？
1.備份 2.生成新的一份數據，若是ok切換到新的數據，若是不ok，回滾數據
上線更新刪除了數據，回滾後數據也沒有了，如何處理？
該不應發生，若是發生了改怎麼去處理
延遲從，悲劇。