Java教程

如何理解高可用?

本文主要是介绍如何理解高可用?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

我们知道,如今的网购、娱乐、物联网等,给我们生活带了诸多便利,这其中很大一部分原因是互联网提供的服务是高可用的,能够随时随地满足你诉求,那么究竟什么是高可用?

什么是高可用?

试想下,你中午需要做饭,想在某平台购买食材,发现该平台不能下单,无法满足你的诉求。我们能说该平台是高可用的吗,显然不能。高可用是面对故障时,服务能够自愈或能够尽最大努力提供有损服务。

那是什么原因导致系统出现故障的呢?其实,可能只是一个小的、随意的原因引起系统的故障,比如:

  • 库存不足;
  • 新增第三方支付,引起的故障;
  • 服务变更,版本兼容引起的故障;
  • 触发某安全策略意外拦截,导致无法下单;
  • https证书过期导致;
  • 优惠券服务导致下单服务出现故障;
  • 库存校验失败,引起故障;
  • 某依赖云厂商出现硬件故障导致;
  • 光纤被挖了;
  • ……

对于能够引起系统故障的因素我们称之为影响高可用因素,这块我在下文会讲。

高可用从架构设计角度,可以理解是面向风险设计,也就是指面对风险时,能够提供高可用性的能力,从可靠性角度,可以理解是通过设计减少系统不能提供服务的时间。们在进行系统架构设计时,要考虑拓展性、安全性等等,其中,高可用也是必须要考虑的因素。

如何度量系统可用性?

上面的例子,我们能够大体地认识并了解高可用,所有的系统,必然是一步步地提升系统可用性的,不能一蹴而成,因此我们也要能够知道如何去度量高可用,管理学大师彼得.德鲁克曾说过:“如果你不能度量它,你就无法改进它 ”。

对于高可用的度量,一般从“可用性”和“可靠性”两个维度来描述:

  • 可用性:在单位时间内,系统可提供服务的持续时间;
  • 可靠性:根据系统平均失效时间来衡量。平均失效时间越短可靠性越高。

首先我们来看可用性。一般我们会用几个9来描述可用性(几个9也通常用来标识服务的SLA,即服务等级协议)。

可用性的计算公式: 可用性=系统无故障运行时间/(系统无故障运行时间+系统故障维护时间)

举个例子:某图书管理平台计划投入运行10天,计划运行时间为每天早8点至晚6点(每天运行10小时),第2天上午9点发生一次故障,故障恢复用了1小时;第5天下午又发生一次故障,故障恢复用了4个小时;第9天上午发生一次故障,故障恢复用了1小时,那么图书管理平台的可用性是多少呢?

  • 系统故障恢复时间:一共用了1+4+1=6个小时
  • 系统无故障运行时间:7*10+9+6+9=94个小时
  • 图书管理平台的可用性:94/(94+6)=94%

通过上述案例能够看到,图书管理平台系统的可用性是94%,才一个9,对于很多平台,系统的可用性要求在三个9以上,要求更为严格的是4个9以上或者5个9。

以年为单位,倒推下,不同要求下对于故障的可容忍时间:

  • 1个9:(1-90%)*365=36.5天

  • 2个9:(1-99%)*365=3.65天

  • 3个9:(1-99.9%)*365*24=8.76小时

  • 4个9:(1-99.99%)*365*24=0.876小时=52.6分钟

  • 5个9:(1-99.999%)*365*24*60=5.26分钟

所以,当你的系统可用性不满足三个9的时候,你就要注意了,考虑系统的可用性是不是要提高,换句话说一年内有三天多的时间系统是不可用的,无法正常提供服务,带来的损失也是不可估量的,因此,很多平台对系统的可用性要求在三个以上。

说完了可用性,我们再来说一下可靠性。在业界,一般谈到可靠性,必然离不开MTTR平均修复时间、MTBF平均无故障时间、MTTF平均失效时间这三个指标,在前面也讲到过平均失效时间越短可靠性越高。

  • MTTR平均修复时间,它的计算方式是:MTTR=维护时间总和/维护次数之和,比如计算图书管理平台的MTTR:6/3=2个小时。MTTR反应出对线上响应和问题修复的效率,MTTR的数值越小,对故障的修复效率越高。
  • MTBF平均无故障时间,它的计算方式是:MTBF=总运行时间/总失败次数,比如计算图书管理平台的MTBF:94/3≈31个小时。MTBF反应出系统的可用性,系统的可用性越高,平均无故障时间越长。
  • MTTF平均失效时间,它的计算方式是:MTTF= 服务副本数的总运行时间/副本数,我们还是来计算图书管理平台的MTTF:图书管理平台是单机部署,所以只有一个副本,故MTTF:94/1=94个小时。MTTF反应出系统的故障间隔周期,该数值越低,说明系统故障的频率越频繁。

知道了什么是可用性和可靠性,那对于一个稳定性系统来说,哪一点更重要呢?

其实,系统的首要目标是先降低故障的次数,频率要低,从而提高可靠性;同时在故障出现后,要提高故障的恢复时间,速度要快,从而提高业务的可用性。

我们举个例子来说明二者的区别。如果系统在每小时崩溃1ms,那么它的可用性就超过99.9999%,但是它还是高度不可靠,因为它只能无故障运行1小时。与之类似,如果一个系统从来不崩溃,但是每年要停机两星期,那么它是可靠的,但是可用性只有96%。

还有个问题:为什么大家经常讲提升系统可用性(稳定性),而不经常提到可靠性呢?我认为可用性包含可靠性,理由是假设系统不可靠,那么面临的问题可能是业务Bug或者导致系统出错等情况,这些是不允许的,如果存在这些漏洞是无法上线的,所以大家经常讲可用性。

业界也有很多典型的案例,可以从中了解到对于有足够影响力的平台,一旦出现故障导致不可用,那也将影响着我们的生活,供我们参考和学习:
  • 2020年国庆前一天,受“2020年最难打车日”的需求影响,滴滴平台和嘀嗒平台相继出现宕机故障;
  • 2018年亚马逊prime day:亚马逊会员日故障(顾客无法将商品添加到购物车结账),导致公司损失高达9900万美元。
  • 2015年由于中国工商银行部分地区因计算机系统升级,造成柜面和电子渠道业务办理缓慢,甚至不能受理业务
  • 2012年12306铁路订票网站因机房空调系统故障,导致暂停互联网售票、退票、改签业务。

构建高可用系统,面临哪些难题?

不过,打造高可用系统,这个话题还是相对来说比较虚。高可用构建不是一个点,而是所有点组合的一个结果。不像技术案例具体可实现,高可用更抽象,需要有足够的技术视野,需要能够观测并提前做好布局。即便如此,在构建稳定性时,还是会遇到很多难题。

  • 难题一:业务变化之快

对于一个业务来说,不同阶段业务目标是不同的,对系统的要求也是如此:业务初期的要求迭代效率,业务中期的要求是业务起量,业务长期的要求是高可用(稳定性)。需要注意的是,面对业务的快速发展及不确定性,想要提升系统稳定性,需要贴合业务的节奏,对于影响稳定性高严重性、高可能性的风险进行风险管控处理。

例如:我们针对某个核心关键流程进行优化、容错、解耦设计,这个改动可能涉及系统层面从上到下的多处修改,包括数据结构调整、业务逻辑改造、数据交互方式等等,可能上线一段时间,因业务变化,该业务废弃,那么前期所做的一切都是无用功。

面对业务的快速,我们对服务的优化和改造,一定要有远瞻性,可以提前做好稳定性建设布局:

  • 基础设施建设,比如:日志、监控、告警、分布式配置中心;
  • 通用性业务组件建设,比如:分布式锁、限流、熔断器;
  • 洞察业务趋势,做好技术储备。
  • 难题二:构建范围之广

稳定性建设需要从全局视角总览,建设范围广,工作量大,其中包括研发、测试、运维、DBA等多个角色,流程规范,变更管理,涉及架构设计、数据库、缓存、消息队列等。

例如:我们可能针对某个核心关键流程进行优化、容错、解耦设计,这个改动可能涉及系统层面从上到下的多处修改,包括数据结构调整、业务逻辑改造、数据交互方式等,涉及诸多方面,很可能有遗漏或bug,导致严重的事故,需要有逐一确认某个细节及强有力的测试才可以。

在构建范围上,可以考虑从以下几个维度入手:

  • 业务上,要面向异常情况考虑,比如:页面加载失败、要友好提示;
  • 技术方案上,要面向失败设计,比如:数据一致性、强依赖失败;
  • 核心关键流程上,要标准化,比如:上线审批流程、技术方案评审必须由架构师确认;
  • 工具上,要尽可能自动化、避免人为操作,比如:部署系统。
  • 难题三:实施成本之高

稳定性建设是需要投入一定的成本,带来的收益也是隐形的,不像业务目标那么明显。一般情况下,业务上不会给技术做稳定性建设的,除非是业务已取得一定的收益,业务模型已形成闭环,此刻业务为了走的更远,打稳地基,允许投入一定的成本做稳定性建设。

不过技术债,还是要尽早还,因为坐在前期的成本要小很多。比如,服务依赖不合理,前期调整比后期调整的成本就要小的多。

影响稳定性因素有哪些?

在前面我们举了个买菜的例子,能够看到影响稳定性的因素有很多,比如网络通信、证书协议出了问题,或者配置信息有误等,为了便于我们理解和记忆,我这里对影响稳定性的因素进行抽象的总结,分为:人为因素、自然因素两大类。

以下为我简单总结的思维脑图,供参考:

 

 

系统的一砖一瓦都是我们自己搭建起来的,对于系统的稳定性,人为因素占比还是比较大的,相信大家都是深入感触,下面拿几个因素简要说明下:

  • 研发流程方面

很多公司的稳定性都是通过流程规范来保障的,人总是不可靠的,当然不是说人不靠谱,原因是人为的操作过程中,可能出现丢三落四的情况,故尽可能把所有流程都流程化、标准化、自动化,减少人为的过多的干预。

例如:变更管理流程,涉及很多环节开发、测试、预发、灰度、小流程、全量,DB结构变更等等,很多公司都有相应的系统,而这个系统实际上是将变更管理所有要做的点做了自动化,避免了人直接操作,通过系统来避免出错,从而保障稳定性。

题外话:在很多公司,对于线上数据出现不一致的情况,那么该如何修复数据,怎么操作呢?

第一种做法:通过数据库客户端直接修改。

第二种做法:先将修复的数据备份,通过SQL语句直接修改。

第三种做法:通过shell或者python脚本,编写sql,通过执行脚本修复。

对于这种三种方法,你觉得那种比较合适呢?

  • 代码方面

代码问题和研发人员水平有很大关系,例如对某段逻辑处理错误、参数校验合法性、异常逻辑处理、是否死循环、第三方依赖库是否正确使用等等。

关于代码问题,可以通过第三方工具进行代码检测,提前发现一些问题。工具可以帮助检测的内容如下:不遵循代码标准、潜在的缺陷、糟糕的复杂度分布、重复、注释不足或者过多、缺乏单元测试、糟糕的设计等,避免这些问题带到生成环境。

例如:非法数据输入,像入参的校验,我们是否做到参数非空、长度、数值类型、范围等多个维度的校验。

  • 配置方面

很多研发工程师对配置参数了解的很少,大多数沿用默认的,像数据库连接池、消息队列重试次数、超时时间,中间件(Kafka、Redis)配置参数,对参数配置是否合理完全不感知。

当然我不是反对用默认的参数配置,而是说你要提前了解每个参数配置决定什么,对应起到什么作用,面对不同的业务场景配置合理的参数。

例如:超时参数配置,对于用TO-C服务、TO-B服务(业务后台)可能某些接口超时参数是不一样的,可能对TO-C比较短,业务最快响应,对TO-B可能面对某些大数据库查询,超时时间也是不一样的,需要根据业务场景及接口区分开合理配置。

再例如:重试次数配置,重试次数1和3的区别很大,因为是每个请求连接可能可能会流量放大1倍或3倍,试想下,重试参数配置很简单,带来的效果是完全不一样的,针对不同的场景对重试次数合理配置,或不配置用户侧重试,其实是对服务的一种保护机制。

小结

今天我们的学习,能够让你知道什么是高可用,理解度量可用性的方法;学完这篇文章,你还可以尝试着评估你负责的业务系统可用性。同时我们也分析了构建高可用系统面临的现实问题,以及分析现实场景中存在着影响高可用的因素。

 

这篇关于如何理解高可用?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!