服务容错的背景，解决方案，与SentInel的基本使用

服务容错的背景

早在1994年，Peter Deutsch就提出了分布式计算的七大谬论，后来被James Gosling(java之父)等人完善为八大谬论

• 网络是可靠的
• 网络是没有延迟的
• 带宽是无限的
• 网络是安全的
• 网络拓扑不会改变
• 肯定至少有一个在值班的管理员
• 传输开销为0
• 网络是同质的

经典案例：服务雪崩

当分布式架构中某一个实例出现故障，处理请求缓慢或者没有响应，导致上层调用它的服务实例也会变慢，请求堆积，负载升高。进一步导致更广泛的服务实例故障。
最后整个架构大面积出现服务实例故障，形同雪崩，突然全线崩溃。这种由单个服务引发的级联故障称为服务雪崩。
造成雪崩的原因主要有三个：

• 服务提供者不可用（硬件故障，程序bug,缓存击穿，用户大量请求）
• 重试加大流量（用户重试，代码逻辑重试）
• 服务调用者不可用（同步等待造成资源耗尽）
  在复杂的分布式架构的应用程序有很多的依赖，都会不可避免的在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。
  1. 例如：一个依赖30个SOA服务的系统，每个服务99.99%可用。
  2. 99.99%的30次方 ≈ 99.7%
  3. 0.3%意味着一亿次请求就会有三十万次失败
  4. 换算成时间大约每月有2两个小时服务不稳定
  5. 随着服务依赖数量的变多，服务不稳定的概率就会呈指数性提高

常见的服务容错模式

• 超时：最简单的容错方式，在调用方为服务调用设置一个超时时间，避免无限制的等待然后造成下游系统的线程堆积
• 限流：在提供方一端限制进入的流量，保证服务不会因为超负荷流量而崩溃
• 仓壁模式：资源隔离手段，在调用方进行组员隔离，比如使用线程池，保证消耗的资源有上限，避免无限量调用资源暂用其他请求的资源
• 熔断器：在调用方进行控制，根据策略定义失败情况，失败数字达到阈值时打开熔断器，不再调用底层服务，熔断窗口（一段时间过后）达到时，释放一个请求进入底层，如果请求执行成功则关闭熔断器，正常调用，如果请求失败则继续保持熔断器打开知道下一个熔断窗口达到。
• 

常用解决方案

netflix-hystrix resillence4j alibaba-sentinel

整合sentinel控制台，懒加载

下载jar包
运行

java -Dserver.port=8840 -Dcsp.sentinel.dashboard.server=localhost:8840 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.1.jar

访问localhost:8840 用户名密码：sentinel
4修在应用配置

spring:
  cloud:
    sentinel:
      transport:
        port: 8719
        dashboard: localhost:8840   # dashboard地址
        client-ip: localhost        # 本机地址，可以不填

**ps：**控制台是懒加载的，需要先发请求，再能看到配置
QPS: Queries Per Second 每秒请求数量

规则默认存放在项目的内存中，若是重启则消失

限流

流量控制有以下几个角度：

• 【对谁】资源的调用关系，例如资源的调用链路，资源和资源之间的关系
• 【统计什么】运行之变，例如QPS,线程池，系统负载等
• 【如何控制】控制的效果，例如直接限流，冷启动，排队等

流控模式

• 直接：直接对资源限流

• 关联：当前资源A设置一个关联资源B，如果B的阈值达到则对A限流。通常用在有关联关系的资源中，比如对某个表的查询和更新操作，可以设为关联，当更新频繁时限制查询，以提高整体性能
  * a:创建两个资源A和B
  * b:对A设置规则，指定关联B
  * c:请求B,使其达到频率，访问发现被流控

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

流控效果

• 快速失败：直接拒绝方式，该方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立刻拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位
• warm up（预热）：冷启动方式。该方式主要用于系统本来性能足够但长期运行在低流量的情况下，当某天流量突然剧增时，可能会直接把系统压垮。通过冷启动，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给一个预热时间，避免系统被压垮
• 排队等待：匀速器 方式 需要设置降阈值模式设置为QPS才能生效。这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。

熔断

三种降级策略：
RT：慢调用比例：选择以慢调用比例作为阈值，需要设置允许的慢调用RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位市场内的请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断市场内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态，若接下来的一个请求响应时间小于设置的慢调用RT，则结束熔断，若大于设置的慢调用RT则会再次被熔断

• 熔断的条件：1：慢调用比例达到条件 ，默认比例为1，就是100%，一个时间段内所有请求都超过设置的最小响应时间，默认位1秒调用次数为5时触发降级，必须达到一秒五次请求以下的情况下再熔断，这是前提条件
• 异常比例：当单位统计时长内请求数目大于设置设置的最小请求数目。并且异常的比例大于阈值，则接下来的熔断时长内请求会被自动熔断。经过熔断时长后熔断器会进入探测回复状态，若接下来的一个请求完成则结束，否证继续熔断，异常比例的阈值范围是0-1
• 异常数：当单位统计市场内的异常数目超过阈值之后会自动进行熔断，经过熔断市场后熔断器会进入探测恢复状态，若接下来的一个请求完成则结束熔断，否则再次熔断

降级

提供一个后被服务
@SentinelResource

@GetMapping("helloB")
@SentinelResource(value = "helloB",fallback = "sayHelloFallback")
public String sayHelloB(String name){
    log.info("name{}",name);
    String s = providerFeignClient.doIt();
    return "你好,"+name;
}

public String sayHelloFallback(String name){
    return "当前服务不可用... ";
}

其他功能

热点参数限流：
一种特殊的流控规则，根据某个请求参数进行限流，适用于存在某些参数的QPS非常高
系统规则：
主要是以服务器整体为单位进行限流保护，保证系统在不被拖垮的情况下保持最大的吞吐量。
主要监控：应用负载，CPU使用率，总体平均RT，入口QPS和并发线程数等指标

授权规则：
可以配置允许或者不允许来自某个来源的请求调用，主要通过获取来源来区别来源，然后根据规则执行允许或者拒绝的操作

调用方信息通过ContextUtil.enter(resourceName, origin）方法中的origin参数传入
区分提示：
熔断和降级提示为一致的
"Blocked by Sentinel(flow limiting）

Hystrix

熔断器 逻辑也是熔断器原理，降级跟熔断