硬件 => CDN =>DNS =>接入层=>逻辑层=>数据层=>缓存层=>安全=>监控=>质量保证=>性能定位分析 =>案例
什么是架构的高可用
架构高可用重要性
架构高可用的手段都有哪些
架构高可用评价维度是什么
架构高可用的如何分级&考核
架构高可用的涉及环节
典型问题你遇到过吗？
什么是软件架构
系统架构两大要素
各个组件
组件见得相关关系
什么是好的软件架构
成本最低
满足用户需求（将来的功能需求）
系统稳定性好
架构足够灵活
数据量维度
并发量维度（同步和异步）
部署运维维度
什么是坏的架构
成本高
系统复杂，笨重
系统不稳定
经常发生故障
系统扩展性差
系统维护性差
维护代价高
软件架构高可用性
一、系统运行依赖的基础
硬件
机器，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，回滚数据
上线更新删除了数据，回滚后数据也没有了，如何处理？
该不该发生，如果发生了改怎么去处理
延迟从，悲剧。
