-服务容错:

           随着时代在进步，用户的需要和要求越来越多，以前的一些服务到现在根本不够用，所以服务会越来越多，数据量就会越来越大，那么数据量大了之后整个架构以及程序出故障的几率就会变大，服务多就会导致容易出错，所以服务容错的需求增加了在复杂的分布式项目架构中的应用程序有很多的依赖，都会不可避免的在某些时候失败，高并发的依赖失败时如果没有隔离措施，当前的应用服务就有被拖垮的风险。

          比如：一个依赖几十个服务的系统，每个服务99.99%可用。

可是随着数据量打了之后就会成指数性增高，这对于一个项目而言是经不住损失的，也不能保证100%的把握。

        典型的案例就是服务雪崩：

         单个实例故障时，处理请求缓慢或者没有相应，导致上层调用它的服务实例也变慢，请求堆积，负载升高，进一步导致更多的服务故障。

最后整个架构大面积出现实例故障，形同异常雪崩，这就是单个连带多个。称为雪崩。

-解决方案

1.超时：在调用方，就是在一定的时间内如果调用其它服务时，没有得到相应就放弃，在异常时，确保资源消耗有上限，会控制时间。

2.限流：在提供方，限制进入系统的流量，确保在系统的负载范围内，保证系统能够正常运转。

3.仓壁模式：运用资源隔离手段，在调用方使用线程池等方式，限制资源消耗在某个范围之内。

把系统服务隔离成多个，互不干扰，不会相互影响，就不会造成单个影响多个情况。

4.熔断器：在调用方，在系统上检测调用，如果发现了某个底层服务故障，则自动断熔，相当于自我保护机制，不会影响其它服务，不再调用该服务，然后会隔一段时间会发出一次测试请求，检测是否恢复正常，如果恢复则加入集群，如果没有回复，则继续打开熔断器。

-Sentinel的流控

 

资源名：唯一名称，自己请求的路径

针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）

阈值类型/单机阈值：

QPS（每秒钟的请求数量）：当调用该api的QPS达到阈值的时候，进行限流
线程数：当调用该api的线程数达到阈值的时候，进行限流

流控模式：

直接：api达到限流条件时，直接限流
关联：当关联的资源达到阈值时，就限流自己
链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）
流控效果：

快速失败：直接失败，抛异常
Warm Up：根据codeFactor（冷加载因子，默认3）的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值。
排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS。否则无效

-熔断器

      在调用方，如果调用的服务是正常的没有异常，则熔断器是关闭状态，也就是调用成功

如果有异常，调用失败，则熔断器会自动打开阈值，会有时间，在这个时间段内熔断器会一直打开，直到时间过了，那么熔断器会发一个测试请求来判断是否回复异常，如果恢复那么熔断器会关闭，继续调用，如果还没有恢复那么就会继续打开熔断器，这样循环发送测试请求。