一文一点 | 系统从高可用到高不可用都经历了什么

这是【一文一点】的第6篇文章，不拘泥于篇幅字数，用一篇文章说清一个知识点。

1、

系统的高可用定义是什么。

 

主要特点就是【可用】前面有个【高】字，加上了高，就是代表系统在发生故障的情况下仍然是可用的，甚至是在极端故障下依然坚挺。

 

比如，有人挖断了通往你一个机房的光缆，但是，你是双机房，所以用户不受影响，这就是【高】可用的体现，【高】的地方在于你有两个机房。

 

高可用可以量化么，可以。

 

计算公式如下，

 

可用性 = （1 - 年度不可用时间 ➗ 年度总时间）* 100%

 

比如你常听到的某个服务的可用性为99.99%，也就是我们常说的4个9，就是这么计算出来的，也就是相当于对系统的可用性做了一个量化显示。

 

那么，反过来讲，确保系统的高可用，也就是通过架构设计减少系统不可用的时间。

 

2、

为了达到这一的高可用我们都经常要做哪些工作呢。

 

让我们首先来看一个正常的互联网分层架构，如下图所示。

 

             

 

在这幅图里面，从客户端请求反向代理，请求web应用服务，请求业务服务，请求数据库，那么大家注意在图中用浅黄色标出来的节点，只要有多份，再加上故障转移，就能够做到高可用。

 

大家想想看，是不是这样。

 

另外呢，我们还可以从地理位置上设计异地多活、还可以从系统内让系统具备容错能力，比如包括降级限流、熔断、快速失败、线程池隔离等措施。

 

3、

那我们要是都做了这些工作，系统还出现不可用，是怎么回事呢。

 

我们可以将这个问题看成是一个攻守失衡的问题，守的是上面那些措施，那么攻的就是故障，当引起故障的变量增速能力大于守的措施能力的时候，便发生了系统的不可用。

 

比如我们说的快速失败，也就是给我们凡是调用RPC的地方都加上超时时间，当前请求的量足够大，以致于请求量的增速时间大于失败的窗口时间，快速失败措施便也无能为力了。

 

在同步调用模式下，请求的线程数据变化急剧增加，最终导致整个系统不可用。

 

那么，我们一般都有哪些故障呢，我们可以把上面那张图继续丰富，来一起看下各技术架构层所处的环境，如下图所示。

 

             

 

也就是我们将其分成了IAAS层、PAAS层、SAAS层，因为一个企业的IT系统组成就是由它们来组成的，从这个角度来看，就便于我们认清每层会遇到什么故障了。

 

（1）、IAAS层的故障

服务器宕机、断电、磁盘满、丢包等等都属于IASS层的故障。

 

（2）、PAAS层的故障

数据库连接池满、数据库主从延迟，另外我们所使用的一切技术中间件也属于这一次，所以还有比如缓存击穿、缓存热点、RPC配置不可读等等，都属于PAAS层的故障。

 

（3）、SAAS层的故障

依赖超时、OOM、幂等失效等等我们所常见的这些，都属于SAAS层的故障。

 

这三层对于我们业务研发人员较为熟悉的是SAAS层和PAAS层的故障，尤其是SAAS层故障距离业务研发人员会更近。

 

这三层任何一层发生故障都有机会让我们的系统不可用。

 

3、

我们再来分享一下高可用这三个字，高我们上面介绍了，可用这俩字，我认为就是一种具有包含的味道在里面了。

 

性能不好，对于要求高性能的系统，还能叫做可用吗，安全出了问题，对于要求安全性高的系统，还能叫做可用吗。

 

所以呢，我个人认为高可用是一个范畴更大的词汇，那么引起不可用的范畴也随之变大了，因为这个时候性能不达标，安全不达标都是不可用了。

 

4、

举一个秒杀系统的例子，你预估流量不合理，资源服务器准备不足，秒杀降临，系统不可用。

 

又来一次秒杀活动，流量预估重复合理，资源服务器准备充足，也使用上了队列技术，增加了基于redis排队系统的支撑，但是redis遇到了缓存热点问题。

 

那天只有一个SKU参与秒杀，你设计的一个SKU一个队列，正常情况下一个4c8g的分片可以8-10w用户，但上午10点瞬间来了20w用户，达到了redis单片的瓶颈上限，系统不可用。

 

更可怕的是，被提示不能下单的用户，正在反复的刷你的服务器，因为他们为了等待秒杀，早早的定好了闹钟，就等这一刻，不愿轻易放弃。

 

             

 

5、

再举一个redis缓存失效的例子，你可能会问了，为什么又拿缓存说事，因为redis缓存常常是我们抗量的“必杀器”。

 

那么，如果这样的“必杀器”也出了问题，高可用是不是就“崩坍”了呢。

 

使用缓存的时候，最常用的方法就是在set的时候设置过期时间了，这种使用方式简单、方便，但同时也带来了”纰漏“。

 

那就是可能会造成“缓存风暴”，怎么理解这个风暴呢，如果短时间内有大量的数据时间过期，这些数据请求就回源到了数据库。

 

本身我们使用redis缓存就是为了增加系统的QPS，redis本身的IOPS也要比数据库高很多，那么在这样的情况下，原本“打”在redis身上的请求，都“回击”到了DB上。

 

             

 

数据库怎么能抗住，本来由redis抗住的量呢，结果可想而知了。

 

6、

以上说的都是技术层面导致原本高可用的系统变成了不可用，当然类似那样的故障种类还有很多。

 

不过，最后我想跟你从故障处理流程上再来说说。

 

故障和问题是一回事吗，咋一听是，其实严格来讲并不是，比如ITIL对这它俩的定义，我帮你总结了下，并画在了一张PPT里面，截图如下。

 

             

 

现在，让我们谈一谈，出现了线上故障，你第一件事最应该做什么？找出引起故障的根源问题吗？

 

记住，一定是先止损。

 

止损的方式有很多，如果你事先有了降级策略，可以立马执行这个策略，如果可以回顾版本，你要立即回顾，如果可以增加机器你要迅速扩容。

 

总之，你要先止损，而不是去苦苦的钻研问题，而不解决故障，找问题可以同步安排其他人员来进行，比如隔离某台服务器，去在上面打出OOM日志。

 

好了，我又写完一个知识点，希望对你有一点帮助。