浅析服务容错

浅析服务容错

服务器容错是为解决高并发带来的问题。
在微服务架构中，我们将业务拆分为一个个服务。服务于服务之间可以互相调用但随着服务数量的增加，分布式架构的应用程序之间有很多的依赖，都会不可避免地在某些时候失败。高并发时依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

例如:

1. 一个依赖30个SOA服务的系统,每个服务99.99%可用。
2. 99.99%的30次方 ≈ 99.7% 0.3%不可用
3. 0.3% 意味着一亿次请求 会有 3,000,00次失败
4. 换算成时间大约每月有2个小时服务不稳定.
5. 随着服务依赖数量的变多，服务不稳定的概率会成指数性提高.

服务雪崩效应

单个实例故障时，处理请求缓慢或者没有响应。导致上层调用它的服务实例也变慢，请求堆积，负载升高。进一步导致更广泛的服务实例故障。最后整个架构大面积出现服务实例故障，形同异常雪崩，突然全线崩溃。

服务容错策略

1. 超时：在上游服务调用下游服务时，一定时间内未得到响应则放弃请求，释放掉线程；在异常时，确保资源的消耗有上限。
2. 限流：在被调用方，限制进入系统的流量，确保在系统的负载范围内，保证系统能够正常运转
3. 隔离：又称为仓壁模式，资源隔离为手段。使各个模块之间相对独立，无强依赖，在调用方使用线程池等方式，限制资源消耗在某个范围之内；常见的隔离方式有：线程池隔离和信号量隔离
4. 熔断器： 熔断是以牺牲局部，保全全体的措施，在上游服务调用下游服务时，在系统上检测调用，如果发现了某个底层服务故障，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
   熔断一般有三种状态：
   熔断关闭状态：服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。
   熔断开启状态：请求失败达到一定量时，打开熔断器。后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法。
   半熔断状态：尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率，如果成功率达到预期，则说明服务已经恢复，进入熔断关闭状态。如果成功率很低，则重新进入熔断关闭状态。隔一段时间再次检测是否恢复，如果恢复则加入集群。
   降级：降级其实就是为服务提供一个托底方案，一旦服务无法正常调用，就是用托底方案。

服务容错组件

Hystrix
　　Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者是第三方库，防止级联失败，从而提升系统的可用性和容错性。

Resilience4J
　　Resilience4J是一款轻量级、简单、文档清晰、丰富的熔断工具，这也是Hystrix官方推荐的替代产品，不仅如此，Resilience4J还原生支持SpringBoot，而且监控也支持和promettheus等多款主流产品进行整合
　　https://resilience4j.readme.io/

Sentinel
　　Sentinel是阿里巴巴开源的一款断路器实现，本身在阿里内部已经被大规模采用，非常稳定。
　　https://sentinelguard.io/zh-cn/