如何构建高可用的系统（一）：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. 为系统构建一套监控， 数据说话

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