系统如何做到高可用

基本概念

高可用性：指的是系统具备较高的无故障运行的能力。

可用性的度量：两个相关概念MTBF和MTTR

  1. MTBF（Mean Time Between Failure）：是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。
  2. MTTR（Mean Time To Repair）表示故障的平均恢复时间，也可以理解为平均故障时间。这个值越小，故障对于用户的影响越小。

计算公式如下：

Availability = MTBF / (MTBF + MTTR)

系统设计思路

系统设计主要是以下几个原则或者说关注点

1、故障转移

故障转移分为两种情况

  • 是在完全对等的节点之间做failover。（节点不保存状态，每个节点都可以作为另一个节点的镜像）
  • 是在不对等的节点之间，即系统中存在主节点也存在备节点。（例如MySQL集群）

备注：不对等的节点之间故障转移可能会造成数据丢失

2、超时控制

超时控制实际上就是不让请求一直保持，而是在经过一定时间之后让请求失败，释放资源给接下来的请求使用。这对于用户来说是有损的，但是却是必要的，因为它牺牲了少量的请求却保证了整体系统的可用性。

超时时间通过收集系统之间的调用日志，统计比如说99%的响应时间是怎样的，来设计这个值。

3、降级

降级是为了保证核心服务的稳定而牺牲非核心服务的做法。

4、限流

限流通过对并发的请求进行限速来保护系统。

比如对于Web应用，我限制单机只能处理每秒1000次的请求，超过的部分直接返回错误给客户端。虽然这种做法损害了用户的使用体验，但是它是在极端并发下的无奈之举，是短暂的行为，因此是可以接受的。

5、系统运维

可以从灰度发布、故障演练两个方面来考虑如何提升系统的可用性。

  • 灰度发布：指的是系统的变更不是一次性地推到线上的，而是按照一定比例逐步推进的。一般情况下，灰度发布是以机器维度进行的。比方说，我们先在10%的机器上进行变更，同时观察Dashboard上的系统性能指标以及错误日志。如果运行了一段时间之后系统指标比较平稳并且没有出现大量的错误日志，那么再推动全量变更。
  • 故障演练：指的是对系统进行一些破坏性的手段，观察在出现局部故障时，整体的系统表现是怎样的，从而发现系统中存在的，潜在的可用性问题。

如何让系统易于扩展

通过拆分把庞杂的系统拆分成独立的，有单一职责的模块。即将复杂的问题简单化。

1.存储层的扩展性

储拆分首先考虑的维度是业务维度，之后单一的业务数据库在容量和并发请求量上仍然会超过单机的限制。这时，我们就需要针对数据库做第二次拆分（分库分表、水平扩展）

2.业务层的扩展性

从三个维度考虑业务层的拆分方案，它们分别是：业务维度，重要性维度和请求来源维度。