服务容错以及sentinel的流控和熔断

一.服务容错

1.1背景：

        在微服务架构中，我们将业务拆分为一个个服务，服务于服务之间可以互相调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量网络涌入，会形成任务堆积，最终导致服务瘫痪。

1.2：服务雪崩效应

        在分布式系统中，由于网络原因或自身的原因，服务一般无法保证100%可用，单个服务实例故障，无法通信时，处理请求缓慢或者没有响应，会导致上层调用它的服务实例也变慢，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这种由单个服务引发的级联故障称为服务雪崩。

1.3：常见的解决方案：

        (1)超时：服务在调用另一个服务长时间没有响应时，就放弃本次请求，放开线程。

        (2)限流：限制同一时间进入服务的流量，保证服务器正常，一旦达到或者超过该阈值，服务器就要限制流量并采取少量措施以完成限制流量

        (3)隔离：将系统中的服务按照一定规则进行划分隔离，使其之间不具有依赖性，当某个服务出现故障时，能将问题与影响隔离在一个模块，不波及其他模块，这样就不会影响整体的系统服务。常见的有线程池隔离和信号量隔离。

       (4)熔断器： 在调用方进行控制，根据策略定义失败情况，失败数字达到阈值时打开熔断器，不再调用底层服务，熔断窗口一段时间过后达到时，释放一个请求进入下一层，如果请求执行成功则关闭熔断器，正常调用，如果请求失败则继续保持熔断器打开直到下一个熔断窗口达到。

1.4：常见服务容错组件：

        (1)sentinel  阿里巴巴组件，中文，好用

        (2)hystrix  netflix出品,比较旧

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

这里重点介绍阿里的sentinel

二.sentinel

此处介绍sentinel的流控和熔断

2.1流控：  流控分为三个模式a.直接b.关联c.链路（了解）

        1、直接对资源限流

        2、服务A关联服务B，若达到B的阈值则对服务A限流，比如对某个表的查询和更新操作可以设为关联，当更新频繁时限制查询，以提高整体性能。

        3、以调用链路为单位做限流处理，例如：A->B->C 这个链路的总体流量只按入口A的请求量来计算。

        流控的效果：

        1.快速失败：直接拒绝方式。该方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。

        2.warm up（预热）：冷启动方式。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮的情况。比如设置的阈值为100，预热时间10s，冷加载因子是3,那最初的阈值时100/3,逐步加大阈值，10s后达到100。

        3、排队等待：匀速器方式。设置QPS，这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过。

2.2.熔断：

        在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全全体的措施叫做熔断。

2.2.1熔断的三种状态：

        熔断关闭状态：服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。

        熔断开启状态：后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法。

        半熔断状态：尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率，如果成功率达到预期，则说明服务已经恢复，进入熔断关闭状态。如果成功率很低，则重新进入熔断关闭状态。