位置:编程技术网 > 人工智能 > 正文 >

阿里架构师浅析系统高可用的实现,如何让你的系统不掉链子?

2020年07月18日 21:22来源:未知手机版

冯远,女人俱乐部大结局,笔记本关触摸板

阿里架构师浅析系统高可用的实现,如何让你的系统不掉链子? 2020-07-14 12:21:49 南瓜音乐

在实际工作中,我们平常更关注系统业务功能的实现,而对于系统是否会出故障,总觉得那是小概率事件,一开始不会考虑得太多。然而系统上线后,我们会发现系统其实很脆弱,每个地方都可能会出问题,处理线上事故的时间往往超过了开发功能的时间。

所以,对于系统的高可用,我想你经常会有这样的疑问:系统的高可用真的很重要吗?如何实现系统的高可用,具体都有哪些手段呢?

十年前的时候,我们有几个数据来说明系统宕机对公司的影响,我记得其中一个是系统每宕掉 1 秒,公司将损失三千美金的收入;现在的大型外卖平台也是如此,如果就餐高峰期宕掉 1 小时,平台至少损失几个亿的直接收入,更加不用说对公司品牌的影响。

但是我们知道,系统中包含了大量的软硬件设备,要保证所有的节点都可用,不是一件容易的事。所以今天这一讲,我会从系统高可用的角度出发,和你介绍如何才能做到让系统不掉链子。

系统有哪些故障点?

那么一个系统,它在运行的过程中,都可能会出现哪些故障呢?我们来看一个简化的系统处理过程。

首先,客户端在远程发起请求,经过接入系统处理后,请求被转发给应用系统;应用系统调用服务完成具体的功能;在这个过程中,应用和服务还会访问各种资源,比如数据库和缓存。这里,我用红色部分,标识出了整个处理过程中可能出现的故障点,如下图所示:

>这些故障点可以归纳为三类:

资源不可用,包括网络和服务器出故障,网络出故障表明节点连接不上,服务器出故障表明该节点本身不能正常工作。

资源不足,常规的流量进来,节点能正常工作,但在高并发的情况下,节点无法正常工作,对外表现为响应超时。

节点的功能有问题,这个主要体现在我们开发的代码上,比如它的内部业务逻辑有问题,或者是接口不兼容导致客户端调用出了问题;另外有些不够成熟的中间件,有时也会有功能性问题。

下面,我们就来看看如何才能应对这些问题,实现系统的高可用。

高可用策略和架构原则

系统可能出问题的地方有很多,解决的方式也不一样,在讨论具体的解决手段之前,我想先说下高可用的总体解决思路,这样你就能更好地理解具体的实现方式。

>要想让系统能够稳定可用,我们首先要考虑如何避免问题的发生。比如说,我们可以通过UPS(Uninterruptible Power System,不间断电源)来避免服务器断电,可以通过事先增加机器来解决硬件资源不足的问题。

然后,如果问题真的发生了,我们就要考虑怎么转移故障(Failover)。比如说,我们可以通过冗余部署,当一个节点发生故障时,用其它正常的节点来代替问题节点。

如果故障无法以正面的方式解决,我们就要努力降低故障带来的影响。比如说流量太大,我们可以通过限流,来保证部分用户可以正常使用,或者通过业务降级的手段,关闭一些次要功能,保证核心功能仍旧可用。

最后是要快速恢复系统。我们要尽快找到问题的原因,然后修复故障节点,使系统恢复到正常状态。

这里我要强调的是,处理线上事故的首要原则是先尽快恢复业务,而不是先定位系统的问题,再通过解决问题来恢复系统。因为这样做往往比较耗时,这里给出的处理顺序也体现了这个原则。

那么结合前面介绍的系统故障点和高可用的解决思路,我们在做架构设计时,就可以从正面保障和减少损失两个角度来考虑具体的应对手段。下面,我就来和你分享一下高可用的设计原则。

>第一个设计原则是冗余无单点。

本文地址:http://www.reviewcode.cn/rengongzhinen/157793.html 转载请注明出处!

今日热点资讯