可用性知识原理
什么是可用性呢？我们先来看看两个概念：
- 可用性（Availability）：在某个考察时间内，系统能够正常运行的概率或时间占有率期望值。
- 高可用（High Availability）：通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性；
这里还有两个大家很容易混淆的概念，可靠性和可用性。
- 可靠性：通过系统运行的平均故障间隔时间来衡量
- 可用性：用户在特定环境下完成指定目标的效果、效率和满意度；
可用性指标
MTTR、MTTF、MTBF是体现系统可用性的重要指标，我们看下面一张图来解释三者之间的关系
T1 表示的是平均无故障运行时间即系统多久不出现故障（主要通过代码的code review、测试手段、上线流程的管控让T1的时间尽可能的长）
T2 表示的是系统出了故障到人发现故障的时间（主要通过监控、巡检等手段能尽早发现问题，让这一时间尽可能短）
T3 表示的是故障修复时长（主要通过对系统的应急预案，故障预演让这一时间尽可能短）
那么结合这三个关键时间段我们可以推算出系统可用性
- MTTF（Mean Time To Failure）：平均无故障时间，取所有从系统开始正常运行到发生故障之间的时间段的平均值。
MTTF = ∑T1/ N - MTTR（Mean Time To Repair）：平均修复时间，取系统从发生故障到维修结束之间的时间段的平均值。
MTTR=∑(T2+T3)/ N - MTBF（Mean Time Between Failure）：平均故障间隔，取系统两次故障发生时间之间的时间段的平均值。
MTBF=∑(T2+T3+T1)/ N，很明显MTBF= MTTF+ MTTR - 可用性=(MTTF/(MTTF+MTTR))*100%
可用性等级
我们一般用 N个9 来表示系统的可用性等级，下面来看看系统不同可用性等级的具体指标。
| 可用性 | 停机时间/年 | 停机时间/天 | 描述 |
| 90% | 36.5天 | 2.4小时 | 达不到使用门槛 |
| 99% | 2.65天 | 14分钟 | 基本可用 |
| 99.9% | 8.76小时 | 86秒 | 较高可用 |
| 99.99% | 52.6分钟 | 8.6秒 | 自动恢复能力的高可用 |
| 99.999% | 5.25分钟 | 0.86秒 | 极高可用性 |
| 99.9999% | 31.5秒 | 8.6微秒 |
对于一般的交付系统我们的可用性等级需要保证能达到2个9，要想能达到3个9 或者更高等级需要搭配完整的监控运维体系以及自动恢复能力，这就需要对系统进行高可用架构设计。
小伙伴们你们的系统能达到几个9呢？
可用性架构
- 串联架构
- 在这种架构下虽然你的子系统都能达到2个9，但是最终系统的可用性等级并不能达到2个9。这也说明我们在系统设计时不能过多进行串联设计或者说我们的系统层级不能太深。
- 并联架构
- 另外一种架构就是并联架构，一个相同的系统部署三份，这样让整体可用性也能达到2个9。但是这种架构会带来人力和资源成本的上升，这种架构对成本不是很友好。
- 混合架构
- 比较好的架构就是这种架构，串联加并联的混合架构。对于关键业务场景上我们采用并联架构，对于非关键场景采用串联架构。
可用性计算
日常开发中我们有一些常见的可用性计算方式
- 硬件可用时间计算法 只要硬件没挂系统就是可用（这种一般不采用）
- 用户抱怨数量统计法 只要老板或关键用户没发现系统挂了那系统就是可用的
- 外部服务监控统计法可以使用外部的监控工具来判断是否可用，这是实际比较常用的计算方式，还可以结合业务特点进行灵活选择。
- 业务流量对比计算法 通过对业务流量的观察判断系统是否可用
高可用影响因素
高可用的影响因素有很多，可以按照计划内和计划外两种方式进行分类。
- 计划内
1、日常维护：硬件扩展、网络调整、配置更新、备份、性能优化、安全管理、软件补丁、数据清理等等；
2、系统更新（软件）；
3、系统更新（硬件）；
这一块的影响其实是可控的，我们可以选择在系统使用频率低的时候进行操作，或者使用灰度发布、滚动更新等方式让影响降到最低。 - 计划外
1、基础设施故障：服务器、防火墙、路由器、交换机、网络、空调、供电等；2、第三方故障：DNS、CDN、外部系统、开源软件等；3、自身系统缺陷：客户端缺陷、服务端缺陷等；4、正常突发流量预估不足：运营活动、爆款产品、促销等；5、人为误操作：误清除数据、执行上线命令出错、拨网线等；6、故障处理流程和操作不顺畅 7、人为恶意操作：权限控制不严；（微盟事件） 8、黑客攻击：破坏性以及非破坏性；9、自然灾害：地震、龙卷风等；
典型可用性问题
以下是我们会经常遇到的一些可用性问题：
- 服务器网卡突发故障
- 服务器扩展内存后重启失败
- 网线接入不规范被误拔/断网
- 服务器电源线被误拔/停电
- CDN节点被运营商屏蔽
- 域名网络劫持
- 机房网络突发不稳定
- 外部依赖服务异常
- 现网大表建索引，直接卡死
- 各种程序BUG和不良设计
- ... 你们还有遇到其他可用性问题吗？
系统化提升思路
目标定义
高可用目标需要根据实际的业务需求确定对应的指标，主要受到以下几个因素的影响
- 业务所处的阶段：起步阶段&发展阶段&成熟阶段 如果你的业务刚刚起步就要求你的系统可用性需要达到4个9，那么随之而来的是需要构建一整套的监控体系以及考虑跨机房等手段来保障这个目标，资源和人力成本会巨幅增加。在不知道业务死活的前提下就给系统定那么高的可用性指标显然是不合适的，所以要求架构师在做架构设计时一定要了解业务所处的阶段，根据业务阶段来制定响应的可用性指标，这点很关键。
- 业务所属的类型：涉及金额和不涉及金额
如果我们系统跟钱发生了关系，那么我们就需要对系统的可用性和设计进行反复评估，保证任何情况下系统都不能宕机或者就算发生宕机也需要保证金额是一致的。 - 业务成本预算：根据成本进行评估
高可用跟成本有很大的关系，要保证高可用我们同一套系统可能需要在不同机房部署多份，而且多机房之间可能还需要专线网络部署，再或者是redis、db、nginx等各种集群，这样会造成成本大幅上升。所以架构师在做架构设计时也需要考虑业务方的成本预算，不能一味的追求高可用导致预算成本不可接受。 - 不同的企业文化和市场策略：创新风险&保守稳定
目标分解
定义完系统高可用目标后我们需要对高可用目标进行分解，量化。比如下面这个例子就是一个不好的高可用定义 一年业务的不可用时间是X分钟，或者系统可用性指标为3个9。这种目标定义不直观、缺乏指导意义。如何定义一个合理的可量化可衡量的目标呢？大家可以参考以下4个点：
- X分钟发现故障
- X分钟定位故障
- X分钟恢复业务
- 平均最多X个月发生X次问题
如：可用性达到99.99%：平均3分钟发现故障、平均5分钟定位故障、平均5分钟恢复业务、平均最多3个月发生一次故障
高可用的架构的提升思路是通过良好的技术架构带动运维体系最终保证系统质量。
高可用架构核心设计
下面是一张典型的高可用设计的架构分层图
后面我们会对分层中涉及到关键点进行重点讲述，在此之前我们先看一下高可用架构涉及到的常见技术选型：
| 类别 | 内容 |
| 智能DNS | F5、dnspod-sr、pdnsd、DNSPod（腾讯）、114DNS、阿里云 |
| CDN加速 | 蓝汛、网宿、帝联 |
| 负载均衡 | 硬件：F5 软件：LVS、Nginx(Tengine)、HAProxy |
| 应用服务器 | Tomcat、Undertow、JBOSS、WebLogic、Websphere |
| 中间件 | Flume、Nacos、Sentinel、Rocketmq、Kafka、ElasticSearch、SkyWalking |
| 服务框架 | Dubbo、DubboX、SpringCloud |
| 数据库 | 关系：Mysql 非关系：Mongodb、Hbase、Neo4j |
| 缓存 | Redis、Memcache、Varnish、Squid、ATS |
| 富媒体存储与处理 | Swift、TFS、GraphicsMagick、ImageMagick、Ffmpeg、阿里、七牛、又拍、ucloud |
对于工期比较紧的项目推荐大家使用上面比较成熟的技术组件。
智能DNS
智能DNS系统是功能特殊的域名解析系统，可以将单一域名解析为多个不同的IP地址，主要服务于具有多个镜像站点的网站。比如将南方用户路由到广州机房的服务，将北方用户路由到北京机房的服务。
CDN加速
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。
用户在自己的浏览器中输入要访问的网站的域名，浏览器向本地DNS请求对该域名的解析，本地DNS将请求发到网站的主DNS，主DNS根据一系列的策略确定当时最适当的CDN节点，并将解析的结果（IP地址）发给用户，用户向给定的CDN节点请求相应网站的内容。
LB高可用
通过双主模式部署结构、负载均衡健康检查配置实现LB层的高可用
多级缓存架构
这一块的架构比较常见，大家注意的是需要对缓存组件本身进行高可用设计。
MYSQL高可用
要保证mysql的高可用现在一般推荐使用MHA+keepalive的架构实现。这里不细讲大家可以自行查阅。
系统拆分
对于一些大型系统我们需要对系统做一些拆分，可以根据以下几种场景进行拆分。
核心非核心拆分
核心系统与非核心系统进行物理隔离，出现故障时优先保证核心业务系统正常运行，针对于非核心业务系统可以做降级和限流，这个在业界也是很常见的做法。
用户隔离
这一部分讲的是根据用户属性隔离，区分VIP 用户和 普通用户，在系统有问题时优先关注VIP用户，或者优先保障vip用户的用户体验。
降级
当访问量剧增、服务出现问题（如响应时间慢或不响应）严重时可能导致宕机。为了保证核心功能正常运行，需要对服务进行降级，即有损服务。降级的实现步骤是梳理出系统业务中哪些是“卒”，哪些是“帅”。针对不同的“卒”制定降级方案，开发支持问题出现时自动或者手动实施降级。
推荐使用alibaba 开源的sentienl组件进行降级实现。
限流
通过对系统的并发量请求量进行限制来保护总体系统，避免出现总体崩溃的情况。一般进行限流的都是核心系统。
推荐使用alibaba 开源的sentienl组件进行限流实现。
依赖原则
在系统架构设计中要遵循以下几个依赖原则：
- 能不依赖就不依赖
- 能少依赖就不多依赖
- 能弱依赖就不强依赖
- 强依赖尽可能支持容错
- 所有依赖要清晰符合预期
最好有可视化的组件来直观的查看系统之间的依赖关系，这里推荐部署APM工具SkyWalking，不仅能看到调用链路还能方便的看到系统之间的依赖。
掌握系统可用性设计，成为优秀的架构师！
好了，各位朋友们，本期的内容到此就全部结束啦，能看到这里的同学都是优秀的同学，下一个升职加薪的就是你了！
