进来抄作业：分布式系统中保证高可用性的常用经验

Posted 2021-10-09 英姐

系统可用性指标

系统可用性指标简单来将就是系统可用时间与总运行时间之比

Availability=MTTF/(MTTF+MTTRMTTF)

​MTTF 是 Mean Time To Failure，指平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长(简单理解MTTF 就是指系统正常运行的时间)。MTTR 是 Mean Time To Recovery， 平均修复时间，即从故障出现到故障修复的这段时间，也就是系统不可用的时间，这段时间越短越好。系统可用性指标可以用通过下表站长交易的999标准衡量，现在普遍要求至少2个9，最好4个9以上：

故障不可避免

高可用性是指系统提供的服务要始终可用，然而故障不可避免，特别是在分布式系统，面对不可控的用户流量和机房环境，系统故障将会显得更加复杂和不可预测。在大规模的分布式系统中，各个模块之间存在错综复杂的依赖，任一一个环节出现问题，都有可能导致雪崩式、多米诺骨牌式的故障，甚者可以断言出现故障成了常态。

如上图的分布式系统中，用户请求系统中的某个服务接口，请求需要经过长长的调用链才能处理返回。我们起码要保证网络连接正常，服务网关正常、前端服务正常、后台服务正常、数据库正常，请求才能被正常处理，如果调用链中的任一环节出现问题，都会直接反馈到用户体验上。

系统出现故障的原因多种多样，主要有以下这些：

网络问题，网络连接故障，网络带宽出现超时拥塞等；

性能问题，数据库慢查询、Java Full GC、硬盘 IO 过大、CPU 过高、内存不足等

安全问题，被网络攻击，如 DDoS 等、异常客户端请求，如爬虫等。

运维问题，需求变更频繁不可控，架构也在不断地被调整，监控问题等；

管理问题，没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步；

硬件问题，硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题(前一阵子机房电缆就经常被挖断)等

面对如此多的天灾人祸，可控和不可控的故障因素，似乎系统的高可用性变成不可能完成的任务，但是在日常开发运维中，我们可以采用一些有效的设计、实现和运维手段来提高系统的高可用性，尽量交付一个在任何时候都基本可用的系统。

冗余设计

分布式系统中单点故障不可取的，而降低单点故障的不二法门就是冗余设计，通过多点部署的方式，并且最好是部署在不同的物理位置，避免单机房中多点同时失败。冗余设计不仅可以提高服务的吞吐量，还可以在出现灾难时快速恢复。目前常见的冗余设计有主从设计和对等治理设计，主从设计又可以细分为一主多从、多主多从。

冗余设计中一个不可避免的问题是考虑分布式系统中数据的一致性，多个节点中冗余的数据追求强一致性还是最终一致性。即使节点提供无状态服务，也需要借助外部服务，比如数据库、分布式缓存等维护数据状态。根据分布式系统下节点数据同步的基本原理CAP(Consistency (一致性)、Availablity (可用性)、Partition tolerance (分区容忍性)三个指标不可同时满足)，数据强一致性的系统无法保证高可用性，最典型的例子就是 Zookeeper。

Zookeeper 采用主从设计，服务集群由 Leader、Follower 和 Observer 三种角色组成，它们的职责如下：

Leader: Zookeeper 集群使用 ZAB 协议通过 Leader 选举从集群中选定一个节点作为 Leader。Leader 响应客户端的读写请求；

Follower：只提供数据的读服务，会将来自客户端的写请求转发到 Leader 中。在 Leader 选举的过程中参与投票，并与 Leader 维持数据同步；

Observer：与 Folllower 的功能相同，但不参与 Leader 选举和写过程的"过半写成功"策略，单纯为了提高集群的读能力。

在 Zookeeper 集群中，由于只有 Leader 角色的节点具备写数据的能力，当 Leader 节点宕机时，在新的 Leader 节点没有被选举出来之前，集群的写能力都是不可用的。虽然 Zookeeper 保证了集群数据的强一致性，但是放弃了集群的高可用性。

对等治理设计中比较优秀的业内体现为 Netiflx 开源的 Eureka 服务注册和发现组件。Eureka 集群由 Eureka Client 和 Eureka Server 两种角色组成，其中 Eureka Client 是指服务实例使用的服务注册和发现的客户端，用于注册和查询服务实例信息；Eureka Server 作为服务注册中心，存储有各服务的实例信息列表，采用多实例的方式部署保证高可用性。每一个 Eureka Server 都是对等的数据节点，Eureka Client 可以向任意的 Eureka Server 发起服务注册请求和服务发现请求。Eureka Server 之间的数据通过异步 HTTP 的方式同步，由于网络的不可靠性，不同 Eureka Server 中的服务实例数据不能保证在任意时间节点都相等，只能保证在 SLA 承诺时间内达到数据的最终一致性。Eureka 点对点对等的设计保证了服务注册与发现中心的高可用性，但是牺牲了数据的强一致性，降级为数据的最终一致性。

熔断设计

在分布式系统中，一次完整的请求可能需要经过多个服务模块的通力合作，请求在多个服务中传递，服务对服务的调用会产生新的请求，这些请求共同组成了这次请求的调用链。当调用链中的某个环节，特别是下游服务不可用时，将会导致上游服务调用方不可用，最终将这种不可用的影响扩大到整个系统，导致整个分布式系统的不可用，引发服务雪崩现象。

为了避免这种情况，在下游服务不可用时，保护上游服务的可用性显得极其重要。对此，我们可以参考电路系统的断路器机制，在必要的时候壮士断腕，当下游服务因为过载或者故障不能用时，及时“熔断”服务调用方和服务提供方的调用链，保护服务调用方资源，防止服务雪崩现象的出现。

断路器的基本设计图如下，由关闭、打开、半开三种状态组成：

关闭(Closed)状态：此时服务调用方可以调用服务提供方。断路器中使用失败计数器周期性统计请求失败次数和请求总次数的比例，如果最近失败频率超过了周期时间内允许失败的阈值，则切换到打开(Open)状态。在关闭状态下，失败计数器基于时间周期运作，会在每个统计周期开始前自动重置，防止某次偶然错误导致断路器进入打开状态。

打开(Open)状态：在该状态下，对应用程序的请求会立即返回错误响应或者执行预设的失败降级逻辑，而不调用服务提供方。断路器进入打开状态后会启动超时计时器，在计时器到达后，断路器进入半开状态。

半开(Half-Open)状态：允许应用程序一定数量的请求去调用服务。如果这些请求对服务的调用成功，那么可以认为之前导致调用失败的错误已经修正，此时断路器切换到关闭状态，同时将失败计数器重置。如果这一定数量的请求存在调用失败的情况，则认为导致之前调用失败的问题仍然存在，断路器切回到打开状态，并重置超时计时器来给系统一定的时间来修正错误。半开状态能够有效防止正在恢复中的服务被突然而来的大量请求再次打垮。

使用断路器设计模式，能够有效地保护服务调用方的稳定性，它能够避免服务调用者频繁调用可能失败的服务提供者，防止服务调用者浪费 CPU 周期、线程和 IO 资源等，提高服务整体的可用性。

小结

本文主要介绍了几种高可用的设计，除了上面介绍的方式之外，还有限流设计和一些其他设计与方案，如降级设计、无状态设计、幂等性设计、重试设计、接口缓存、实时监控和度量以及常规划化维护。