分布式系统如何保证高可用性？(下)

在上面一篇文章介绍了系统可用性指标以及冗余设计和熔断设计，今天我们接着来介绍高可用的其他方式。

限流设计

熔断设计保护的是服务调用者，即上游服务的可用性，对于下游服务提供者，考虑到自身服务实例的负载能力，同样需要限流设计保护自己不被过量的流量冲垮。一般来讲有以下的限流策略：

• 拒绝服务，把多出来的请求拒绝掉。一般来说，好的限流系统在受到流量暴增时，会暂时拒绝周期时间内请求数量最大的客户端，这样可以在一定程度上把一些不正常的或者是带有恶意的高并发访问挡在门外。
• 服务降级，关闭或是把后端做降级处理，释放资源给支撑主流程服务以支持更多的请求。降级有很多方式，一种是把一些不重要的服务给停掉，把 CPU、内存或是数据的资源让给更重要的功能；一种是数据接口只返回部分关键数据，减少数据查询处理链路；还有更快的一种是直接返回预设的缓存或者静态数据，牺牲数据强一致性的方式来获得更大的性能吞吐。
• 优先级请求，是指将目前系统的资源分配给优先级更高的用户，优先处理权限更高的用户的请求。
• 延时处理，在这种情况下，一般来说会使用缓冲队列来缓冲大量的请求，系统根据自身负载能力消费队列中的请求。如果该队列也满了，那么就只能拒绝用户请求。使用缓冲队列只是为了减缓压力，一般用于应对瞬时大量的流量削峰。
• 弹性伸缩，采用自动化运维的方式对相应的服务做自动化的伸缩。这种方案需要应用性能监控系统，能够感知到目前最繁忙的服务，并自动伸缩它们；还需要一个快速响应的自动化发布、部署和服务注册的运维系统。如果系统的处理压力集中在数据库这类不易自动扩容的外部服务，服务弹性伸缩意义不大。

接下来我们介绍两种常用的限流算法：漏桶算法和令牌桶算法。

漏桶算法(Leaky Bucket)是网络世界中流量整形(Traffic Shaping)或速率限制(Rate Limiting)时经常使用的一种算法，它的主要目的是控制数据注入到系统的速率，平滑对系统的突发流量，为系统提供一个稳定的请求流量。

如上图所示，水(请求)先进入到漏桶，而出去的水量表示系统处理的请求。当访问流量过大时漏桶中就会积水，如果水太多了就会溢出，此时请求将会被拒绝。

令牌桶算法则是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌。桶中存放的令牌数有最大上限，超出之后就被丢弃。当流量或者网络请求到达时，每个请求都要获取一个令牌，如果能够获取到，则直接处理，同时令牌桶会删除一个令牌。如果获取不到，该请求就要被限流，要么直接丢弃，要么在缓冲区等待。

其他设计与方案

降级设计

在应对大流量冲击时，可以尝试对请求的处理流程进行裁剪，去除或者异步化非关键流程的次要功能，保证主流程功能正常运转。

一般来说，我们的降级时可以暂时牺牲的东西有：

• 降低一致性。从数据强一致性变成最终一致性。
• 关闭非关键服务。关闭不重要功能的服务，从而释放出更多的资源。
• 简化功能。把一些功能简化掉，比如，简化业务流程，或是不再返回全量数据，只返回部分数据。也可以使用缓存的方式，返回预设的缓存数据或者静态数据，不执行具体的业务数据查询处理。

无状态设计

在分布式系统设计中，都倡导使用无状态化的方式设计开发服务模块。无状态的意思是指对于功能相同的服务模块，在服务内部不维护任何的数据状态，只会根据请求中携带的业务数据从外部服务比如数据库、分布式缓存中查询相关数据进行处理，这样能够保证请求到任意服务实例中处理结果都是一致的。

无状态设计的服务模块可以简单通过多实例部署的方式进行横向扩展，各服务实例完全对等，可以有效提高服务集群的吞吐量和可用性。但是如此一来，服务处理的性能瓶颈就可能出现在提供数据状态一致性的外部服务中。

幂等性设计

幂等性设计是指系统对于相同的请求，一次和多次请求获取到的结果都是一样的。幂等性设计对分布式系统中的超时重试、系统恢复有重要的意义，它能够保证重复调用不会产生错误，保证系统的可用性。一般我们认为声明为幂等性的接口或者服务出现调用失败是常态，由于幂等性的原因，调用方可以在调用失败后放心进行重新请求。举个简单的例子，在支付系统中，在一笔订单的支付请求中，由于网络抖动或者其他未知的因素导致请求没能及时返回，如果支付接口是幂等性，我们应该可以放心使用同一笔订单号重新请求支付，如果上次支付请求已经成功，将会返回支付成功，如果上次支付请求未成功，将会重新进行金额扣费，这样就能保证请求的正确进行，避免重复扣费的错误。

重试设计

在很多时候，由于网络不可靠或者服务提供方宕机的原因，服务调用者的调用很可能会失败，如果此时服务调用者中存在一定的重试机制，就能够在一定程度上减少服务失败的概率，提高服务可用性。比如业务系统在某次数据库请求中，由于临时的网络原因，数据请求超时了，如果业务系统中具备一定的超时重试机制，根据请求参数再次向数据库请求数据，就能正常获取到数据，完成业务处理流程，避免该次业务处理失败。

使用重试设计的时候需要注意以下问题：一是待重试的服务接口是否为幂等性，对于某些超时请求，请求可能在服务提供方中执行成功了，但是返回结果在网络传输中丢失了，此时重复调用非幂等性服务接口很可能会导致额外的系统错误；二是服务提供方是否只是临时不可用，对于无法快速恢复的服务提供方或者网络无法立即恢复的情况下，盲目的重试只会使情况更加糟糕，无脑地消耗服务调用方的 CPU 、线程和网络 IO 资源，在这种情况下建议结合熔断设计对服务调用方进行保护。

接口缓存

接口缓存是应对大并发量请求，提高系统吞吐量，保证系统可用性的有效手段。基本原理是，在系统内部，对于某部分请求参数和请求路径完成相同的请求的结果进行缓存，在周期时间内，这部分相同的请求的结果将会直接从缓存中读取，减少业务处理过程的负载。最简单的例子是在一些在线大数据查询系统中，查询系统会将周期时间内系统查询条件相同的查询结果进行缓存，加快访问速度。

接口缓存同样有着它不适用的场景。接口缓存牺牲了数据的强一致性，对于实时性要求高的系统并不适用。接口缓存加快的是相同请求的请求速率，对于请求差异化较大的系统同样无能为力，过多的缓存反而会大量浪费系统内存等资源。

实时监控和度量

由于分布式中服务节点众多，问题的定位变得异常复杂，对此建议对每台服务器资源使用情况和服务实例的性能指标进行实时监控和度量。最常见的方式健康检查，通过定时调用服务提供给健康检查接口判断服务是否可用。目前业内也有开源的监控系统 Prometheus，它监控各个服务实例的运行指标，并根据预设的阀值自动报警，及时通知相关开发运维人员进行处理。

常规划化维护

定期清理系统的无用代码，及时进行代码评审，处理代码中 bad smell。对于无状态服务可以定期重启服务器减少内存碎片和防止内存泄漏。这些都是非常有效的提高系统可用性的运维手段。

总结

虽然在分布式系统中，由于系统的复杂性，大大加大了服务错误的可能性，但是也有足够的方案保证系统可用性。本文首先介绍了系统可用性指标，接着阐述了分布式系统中故障不可避免的情况，最后笼统地介绍了一些有效的高可用设计。