一、什么是可用性

高可用性对于构建高可伸缩系统是一个极其重要的因素，那么什么是可用性，系统可用性和可靠性之间怎么区分。数据库

1.1可用性和可靠性

可靠性服务器
系统是否具有无差错地执行预期操做的能力微信
可用性网络
为了执行可靠性，系统当前可运行的能力架构

金融支付系统最敏感的业务场景-资损，用户完成一笔跨境收款，正常钱应该从跨境电商平台资金帐户A流转到具有跨境收款能力的跨境支付的用户虚卡帐户B，可是因为系统bug，钱流转到了虚卡帐户C，业务功能逻辑错误，表示可靠性很低；若是钱流转到了虚卡帐户B，可是永远得不到结果，可用性就很低，可靠性能够经过功能测试来修复，可是可靠性很难解决。异步

1.2 低可用性的架构驱动因子

资源耗尽分布式
预期以外的压力变化ide
流动行为的增长微服务
外部依赖性能
技术债务

二、如何提高应用程序的可用性

时刻考虑应对故障

设计
依赖
用户

时刻考虑如何伸缩

设计出可以增长数据库数量和容量的架构
考虑限制你的数据伸缩的缘由
应用服务器可伸缩，服务状态如何维护、如何路由流量
将静态流量导向离线提供方
动态资源静态化

缓和风险保持系统高可用须要消除系统中的风险，架构约束条件是要先肯定风险及风险分类，从系统思考角度考虑风险类别：

存在系统崩溃的风险
存在数据库崩溃的风险
存在返回结果不正确的风险
存在网络链接失败的风险
存在新部署的软件功能出现故障的风险

监控可用性

服务器监控
配置变化监控
应用程序性能监控
人为测试
报警

以预测和肯定的方式来应对可用性问题

三、可用性可度量

测量可用性对保证系统高可用很是重要，任何一款APM系统或者自研的监控系统，都具有监控指标的可度量，只有度量才能实时的追踪系统服务的运行轨迹。

一般可用性都会拿N个9来衡量，好比某跨境支付公司，号称对外收款核心接口可以保证9999(4个9)的可用性，这是一个什么概念，每个月只有4分钟故障时间，见以下表格：

N个9	百分比	每个月故障时间
2个9	99%	432分钟
3个9	999%	43分钟
4个9	9999%	4分钟
5个9	99999%	26秒
6个9	999999%	2.6秒

可用性误区

可用性等级定义须要结合实际的业务场景
计划中和平常维护致使系统的不可用也要计算到度量中

维护窗口可用性计算规则

业务接口可用性百分比=(该期间的总秒数-系统宕机的秒数)/该期间的总秒数

每周的小时数=7天*24小时=168小时

每周不可用的小时数=2小时

业务接口可用性(没有故障)=(168小时-2小时)/168小时=98.8%

业务接口可用性(没有故障)=98.8%

若是每周系统维护窗口时间为2小时，那么系统可用性都达不到最低标准2个9，这是是多么的可怕。

四、服务分级

微服务架构、分布式架构以及云原生架构盛行，致使服务依赖关系复杂度加强，关键服务与非关键服务之间级联故障致使相关服务的可用性极低，解决问题的关键是结合服务的业务场景进行服务分级。

4.1什么是服务分级

服务分级实际上是与服务关联的标签，表示业务场景下，对于业务可用性的关键程度。

1级服务

1级服务是系统中最关键的服务，若是某个服务出现故障会致使用户或者公司业务出现较大的损失

例如：用户服务、汇兑服务、出金和入金服务、vat付款等

2级服务

2级服务对于业务很是重要，可是关键性不如1级服务，2级服务只会影响用户体验

例如：订单搜索服务、订单结算服务等

3级服务

3级服务会对业务系统形成较小的影响，不容易注意到

例如：用户头像服务、推荐服务和站内信等

4级服务

4级服务是对业务不会形成任何影响

例如：异步邮件或者短信提醒服务等

五、使用服务分级

如何使用已经达成一致的服务分级，通常会从以下维护考虑

指望
管理服务指望的一种手段就是SLA(服务等级协议)
响应性
系统故障的响应性的关键决策因素：故障的严重性、出现故障的服务级别。
依赖响应性动态调整系统策略：

报警通知
指望的SLA
对于低优先级问题的上报路径
提供响应的时间安排(24*7或仅办公时间)
是否提供紧急部署或者产品更改
根据服务的可用性和响应性制定SLA

依赖

关键依赖
若是你的服务级别高于(数字小于)依赖服务的级别那么这个服务就是关键依赖，不能忽略依赖服务的故障，必须考虑服务降级，尽最大可能保证服务的可用性和可靠性，依赖服务的服务级别比较低，可用性和可靠性比较低
非关键依赖
若是你的服务级别低于(数字大于)依赖服务的级别那么这个服务就是非关键依赖，可用忽略依赖服务的故障。

六、服务等级协议(SLA)

服务等级协议是团队和服务全部者之间的协议，提供了一个沟通服务间指望的机制。

6.1 服务等级协议定义

服务等级协议是一个提供某种级别可靠性和性能的承诺，它们用来在服务全部者和用户之间建立一个牢固的合约关系。

SLA须要结合具体服务的业务场景，和利益相关者协商服务之间的指望，好比可用性、性能、产品功能等

6.2 SLA性能检测

调用延迟
流量
运行时长
错误率

6.3 SLA阈值

SLA必需要设定阈值，好比RT<20ms等

6.4 SLA排名

好比TP90（百分之90的请求的RT低于20ms）、TP95（百分之95的请求的RT低于20ms）、TP80

（百分之80的请求的RT低于20ms）

6.5 延迟分组

好比某个服务在必定流量下，能够保持必定的延迟，好比当TPS<250k 调用延迟TP90<25毫秒，当TPS>=250k 且小于 400k 调用延迟TP90<30毫秒。

七、处理服务故障

在构建大型基于微服务(分布式服务或者云原生服务)的系统时，如何处理服务故障是一个必需要解决的前置条件，服务越多，服务出现故障的可能性就越大，依赖于故障服务的其余服务数据也会愈来愈多。

级联式的服务故障

依赖的服务发生故障会影响可用性，能够说业务团队几乎天天都在忍受或者着手解决这些故障，由于谁也不能保障咱们所依赖的服务何时会挂，不少业务团队也没这个经历去梳理这个问题，不少都是被动的等故障发生，而后在作局部的修改，规避故障问题，其实问题的解决是有不少方法论技巧的。

如何响应服务故障

面对服务故障，技术开发人员如何响应很关键，响应服务故障必须具有以下前置条件：

可预测的
拥有可预测的故障响应式当前服务可以依赖其余服务的一个重要指标，可预测的响应，要求当前服务必须具有统一吃的异常错误码机制，若是依赖的服务给了一个不可预测的响应，当前服务必须给一个合理的响应，保证请求链路故障的可溯源。
可理解的
响应故障必须知足双方的错误处理契约，也就是错误码必须可以识别。
对当前场景是合理的
合理并具有业务意义的响应，便于问题定位。

如何肯定故障

乱码响应
表示致命错误发生的响应
结果能够理解可是所需的结果不匹配
结果超出预期范围
没有接收到响应
接收响应很慢

如何解决故障

优雅降级
优雅补偿
尽早失败

基于高可用的可伸缩架构方法论生态