系统高可用分析

思考：导致系统不可用的原因有哪些？保障系统稳定高可用的方案有哪些？

针对问题，从以下方面进行分析理解。

一、导致系统不可用的原因

对于系统而言，导致不可用的原因非常多。但是，并不是无法理解，而是只要涉及系统运行的各个环节，都有可能导致系统不可用。

（1）硬件故障

系统部署于服务器之上，当服务器本身出现问题，报出硬件故障，这个时候则是直接导致系统无法正常可用。例如部署数据库的机器，其磁盘发生损坏，导致系统无法正常访问数据库以及数据丢失，此时，如果没有做备份机制，则影响系统运行。

（2）程序问题

系统是基于程序运行的，是系统资源按照程序指令运行的，当程序编写错误，出现了异常 bug，严重的情况直接影响系统无法运行，导致系统奔溃。因此，这就要求编码者需要具有极强的编码能力。

（3）系统错误上线

在互联网领域，产品更新迭代的速度非常快，在较短的时间内，系统就要进行升级更新。此时，有可能出现运维人员上线了错误的版本，导致系统不兼容，出现问题，进而影响系统运行。故而，版本控制也是需要开发人员重视的。

（4）大量用户访问

移动互联网带来的大量用户并发访问系统，系统针对用户请求产生线程，分配计算机资源，此时，大量并发访问的用户使得系统的压力增大，当用户请求数超出了系统能够承受的极限时，便会导致系统奔溃，进而系统不可用。

（5）外部条件

系统运行，我们也不能忽略外界的条件。当发生火灾、自然灾害、人为破坏时，都是会影响系统正常运行，进而使得系统不可用。例如中美跨太平洋电缆，就无法真正保证中美之间的互联网通信 100%可靠。

二、高可用的解决方案

针对导致系统不可用的原因，提供以下系统高可用的解决方案，进而保障系统的可用。

（1）解耦

系统组成元素之间会因相互之间的关联关系而影响，所以，解耦是保障系统可用的重要方法，基于一定的原则和模式：

• 高内聚、低耦合的组件设计原则

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

（2）隔离

为了减少系统组成元素之间的相互影响，也需要采取隔离的方式，如下：

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离

• 虚拟机与容器隔离

（3）异步

某种意义上说，异步也是为了解耦，通常基于以下考虑

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

（4）备份

在今天的环境下，单体的方式已经非常不适用，备份是需要做出的选择，通产采取以下方式

• 集群设计

• 数据库复制

• CAP 原理

（5）失效转移

失效转移通常针对数据库主主失效转移和负载均衡失效转移，问题的关键在于如何确认失效，需要转移。这就要求设计无状态的服务。

（6）幂等

系统发生延时，发送的请求未获得响应结果，此时，则会出现再次发送请求的情况。整个网络环境是无法避免延时的情况发生，这就要求系统必须针对重复的调用，响应的结果是一样的。以性别为例，无论如何请求，响应的结果都是一样。但是，当重复发生交易提交时，不进行幂等性控制，交易总金额重复增加，这是不允许的。

（7）事务补偿

事务补偿，就是通过执行业务逻辑逆操作，使事务回滚到原来的状态。通常分为传统事务和分布式事务。

传统事务的 ACID

• 原子性（Atomicity）

• 一致性（Consistency）

• 隔离性（Isolation，又称独立性）

• 持久性（Durability）

分布式事务的 BASE

• 基本可用（Basic Availability ）

• 软状态（Soft-state）

• 最终一致性（Eventual consistency）

（8）重试

基于线程阻塞、垃圾回收或者网络抖动等原因，远程服务可能会无法及时返还响应，调用者可以通过重试的方式修复单次调用的故障

（9）熔断

当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。断路器具有三种状态：关闭，打开，半开。

（10）限流

在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的。

限流的算法包括计数器算法（固定窗口，滑动窗口）、令牌桶算法、漏桶算法

（11）自适应限流

这就要求我们针对系统，建立实时自动评估 QPS 的机制，通过这个机制达到自适应限流。

（12）降级

有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，为了解决这种问题。解决办法就是在系统高并发的时候，将非核心的功能关闭，留出资源给核心功能。

（13）异地多活

为了应对一个地方出现问题导致整个系统不可用的问题，采用了异地多活的多机房架构策略，也就是说将数据中心分布在多个不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问，这样每个机房都可以提供完整的系统服务，即使某一个机房不可使用，系统也不会宕机，依然保持可用。

异地多活的真正难点在于如何保证数据的一致性。

以上便介绍了保证系统高可用的架构方案。