高可用性对于构建高可伸缩系统是一个极其重要的因素,那么什么是可用性,系统可用性和可靠性之间怎么区分。
金融支付系统最敏感的业务场景-资损,用户完成一笔跨境收款,正常钱应该从跨境电商平台资金账户A流转到具备跨境收款能力的跨境支付的用户虚卡账户B,但是由于系统bug,钱流转到了虚卡账户C,业务功能逻辑错误,表示可靠性很低;如果钱流转到了虚卡账户B,但是永远得不到结果,可用性就很低,可靠性可以通过功能测试来修复,但是可靠性很难解决。
测量可用性对保证系统高可用非常重要,任何一款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,这是是多么的可怕。
微服务架构、分布式架构以及云原生架构盛行,导致服务依赖关系复杂度增强,关键服务与非关键服务之间级联故障导致相关服务的可用性极低,解决问题的关键是结合服务的业务场景进行服务分级。
服务分级其实是与服务关联的标签,表示业务场景下,对于业务可用性的关键程度。
1级服务是系统中最关键的服务,如果某个服务出现故障会导致用户或者公司业务出现较大的损失
例如:用户服务、汇兑服务、出金和入金服务、vat付款等
2级服务对于业务非常重要,但是关键性不如1级服务,2级服务只会影响用户体验
例如:订单搜索服务、订单结算服务等
3级服务会对业务系统造成较小的影响,不容易注意到
例如:用户头像服务、推荐服务和站内信等
4级服务是对业务不会造成任何影响
例如:异步邮件或者短信提醒服务等
如何使用已经达成一致的服务分级,一般会从如下维护考虑
服务等级协议是团队和服务所有者之间的协议,提供了一个沟通服务间期望的机制。
服务等级协议是一个提供某种级别可靠性和性能的承诺,它们用来在服务所有者和用户之间创建一个牢固的合约关系。
SLA需要结合具体服务的业务场景,和利益相关者协商服务之间的期望,比如可用性、性能、产品功能等
SLA必须要设定阈值,比如RT<20ms等
比如TP90(百分之90的请求的RT低于20ms)、TP95(百分之95的请求的RT低于20ms)、TP80
(百分之80的请求的RT低于20ms)
比如某个服务在一定流量下,可以保持一定的延迟,比如当TPS<250k 调用延迟TP90<25毫秒,当TPS>=250k 且小于 400k 调用延迟TP90<30毫秒。
在构建大型基于微服务(分布式服务或者云原生服务)的系统时,如何处理服务故障是一个必须要解决的前置条件,服务越多,服务出现故障的可能性就越大,依赖于故障服务的其他服务数据也会越来越多。
依赖的服务发生故障会影响可用性,可以说业务团队几乎每天都在忍受或者着手解决这些故障,因为谁也不能保障我们所依赖的服务什么时候会挂,很多业务团队也没这个经历去梳理这个问题,很多都是被动的等故障发生,然后在做局部的修改,规避故障问题,其实问题的解决是有很多方法论技巧的。
面对服务故障,技术开发人员如何响应很关键,响应服务故障必须具备如下前置条件: