如何构建高可用的系统(一):Overview

1. What

在聊如何构建高可用系统之前,我们需要对"可用"下一个定义。

业界常用SLA(Service Level Agreement)来描述一个系统对外部系统承诺的可用性, SLA包含很多信息(服务内容、故障恢复时间、可用性等), 在这里我们笼统的用“N个9”来指代,比如4个9指的是99.99%的可用性、 5个9指的是99.999%的可用性。

假如一个系统声称它的年可用性是4个9, 那它提供的可用性承诺就是一年之内, 不可用时间不超过52.56分钟(60 * 24 * 365 * 0.0001)。

在此基础之上,我们来看看, 系统需要做到什么程度, 可以称为高可用:

  1. 低故障总时长: 一般认为4个9以上才有资格称为高可用
  2. 快速的故障恢复: 即使一个系统一年只挂一次但是需要52分钟才能恢复(那么这个系统的年可用性是4个9), 那其实也是不能接受的。

2. Why

为什么要构建高可用系统? 这个其实不必多说,大家都懂, 因此一笔带过。 系统的高可用对于个人口碑、产品、公司的形象、营收、股价,甚至社会稳定, 都至关重要。

3. How

3.1 问题所在

在着手构建高可用系统之前,我们需要知道是哪些因素在阻碍我们提高系统的可用性:

  1. 一切单点都是不可靠的, 如果系统中某个地方可能会出问题(就算概率很低),那么它迟早会出问题。 也就是我们常说的Murphy’s Law。
  2. 系统依赖的一切下游系统都是不可靠的, 它们随时可能出问题
  3. 系统的上游可能有多个, 而且每个上游的行为都是不可预知的。如果某个上游抽风把我的系统搞崩, 那么就会影响所有的上游
  4. 高可用是有前提条件的,一个系统对当前的负载能提供高可用, 不代表负载上升之后仍然高可用
  5. "人"是不可靠的, 费劲心思设计的高可用系统,会因为新引入一个低级错误而崩溃
  6. 高可用需要指标来衡量, 我们不能靠嘴来构建高可用系统

3.2 逐个击破

知道了问题所在, 那么就有解决的方向了:

  1. 既然单点肯定会出问题,那么我们就避免单点
  2. 既然下游肯定会出问题, 那么我们得处理下游不可用的情况
  3. 既然某个上游的抽风行为会影响别的上游, 那么我们需要想办法来最小化这种影响
  4. 既然系统只能在一定负载内提供高可用, 那么我们就得为系统构建一套过载保护机制
  5. 既然“人”肯定会犯错, 那么我们就引入各种机制,来减少犯错的概率, 以及减少犯错的损失
  6. 为系统构建一套监控, 数据说话

接下来的几篇文章, 我会对以上几点展开来讲,干货多多, 欢迎持续关注。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页