服务容错保护Hystrix
一、灾难性的雪崩效应
1.概念：在微服务架构中，一个请求需要调用多个服务是很常见的，如客户端访问A服务，而A服务需要调用B服务，B服务需要调用C服务，
若由于网络原因或者自身的原因，B服务或C服务不能及时响应。A服务将处于阻塞状态，直到B服务和C服务响应，此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。由于服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩效应”
2.造成雪崩的原因
a.服务调用者不可用（硬件故障、程序Bug，缓存击穿、用户当量请求）
b.重试加大流量（用户重试、代码逻辑重试）
c.服务调用者不可用（同步等待造成的资源耗尽）
最终的结果就是—>导致服务不可用，导致服务的一系列不可用，而这种后果往往是无法预料的
3.解决灾难性雪崩的方式
a.降级：超时降级、资源不足时（线程或信号量）降级，降级后可以配合降级接口返回的托底数据，实现一个fallback方法，当请求后端服务出现异常的时候，可以使用fallback方法返回具体的值
b.隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，式某一个调用的服务出现问题不会影响其他服务的正常调用
c.熔断：当失败率（如因网络故障/超时造成的失败率高）达到阈（yu）值自动触发降级，熔断器触发的快速失败会进行快速修复
d.缓存：提供了请求缓存（eg：redis）
e.请求合并：提供请求合并（多请求合并为单请求）
二、服务降级
降级：对服务做降级处理
1.创建项目，配置pom.xml文件，添加SpringCloud依赖，添加Hystrix依赖，添加Eureka依赖（配合服务注册中心解决服务雪崩效应）
2.修改application.properties/yml全局配置文件，配置应用名，端口，注册中心地址
3.修改服务API，通过@HystrixCommand注解配置托底方法，编写返回托底数据的方法，编写Controller以供访问
4.修改SpringBoot启动类，开启熔断器
5.项目结构
@EnableCircuitBreaker注解：一般配合启动类使用，标识开启熔断器
@HystrixCommand注解（非常重要）：与Hystrix解决服务雪崩的方案都需要通过此注解进行相应的配置，可以简单理解为，开启解决雪崩的开关
什么情况下会触发getFallback的调用：
1.方法抛出非HystrixBadRequestException异常
2.方法调用超时
3.熔断器开启拦截调用
4.线程池/队列/信号量是否跑满
三.1、低版本中的请求缓存
请求缓存的概念：Hystrix为了降低访问服务的频率，支持将一个请求与返回结果做缓存处理，如果再次请求的URL没有变化，那么Hystrix不会请求服务，而是直接从缓存中将结果返回，这样可以大大降低服务的压力
Hystrix自带的缓存有两个缺点：
a.是一个本地缓存，在集群情况下缓存是不能同步的
b.不支持第三方缓存容器。Redis，memcache不支持，但可以使用Spring的Cache
由于Spring支持Redis，所以我们这里整合Redis缓存数据库作为请求缓存
1.安装Redis，
创建项目，配置pom.xml文件，添加hystirx依赖、添加SpringCache依赖，添加Redis依赖，添加Eureka服务依赖，添加SpringCloud依赖，添加web启动器等
2.修改application.properteis/yml全局配置文件，配置Redis连接信息，应用名，端口，Eureka服务中心地址等
3.修改Service，配置缓存方法
4.编写Controller以供访问
5.修改启动类，添加@EnableCacheing注解标识开启缓存，开启Eureka客户端
6.项目结构，及测试访问
启动测试：
@CacheConfig注解：开启缓存配置，通过cacheNames属性指定映射的对象（名字可以随意起）
@CacheEvict注解：添加了@CacheEvice注解的方法可以执行同步删除缓存操作，通过key属性指定参数
@EnableCaching注解：一般配合启动类使用，标识开启缓存
三、2、高版本中的请求缓存配置
pom.xml文件中添加Letturce依赖
application.properties配置文件中的不同
四、请求合并
简述：请求合并就是将Consumer中一次性（某个时间，eg：10ms内）的所有请求，合并为一次请求，然后调用Provider进行处理
使用请求合并：
在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相配合工作，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加；
同时，线程池的资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解Hystrix的请求合并
请求合并的缺点：
使用请求合并之后，本来一个请求可能5ms就搞定了，但是现在需要再等10ms看看还有没有其他的请求一起的，这样一个请求的耗时就从5ms增加到了15ms。不过、如果我们要发起的命令本身就是一个高延迟的命令，那么这个时候就可以使用请求合并了，因为这个时候时间窗的时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景
1.创建项目，配置pom文件，添加hystirx依赖，添加其他依赖等
2.修改application.properteis/yml配置文件，配置应用名，端口，服务注册中心地址等
3.修改ProductService
//利用hystrix合并请求
@HystrixCollapser(batchMethod ="batchProduct",
scope = com.netflix.hystrix.HystrixCollapser.Scope.GLOBAL,
collapserProperties = {
//请求时间间隔在20ms之内的请求会被合并为一个请求,默认为10ms
@HystrixProperty(name ="timerDelayInMilliseconds",value ="20"),
//设置触发批处理之前,在批处理中允许的最大请求数
@HystrixProperty(name ="maxRequestsInBatch",value ="200"),
})
常用的注解
@HystrixCollapser注解：使用@HystrixCollapser注解开启对某个API的请求合并
@HystrixProperty注解：设置属性参数，时间间隔、最大请求数等等
@HystrixCollapser注解中的batchMethod属性：合并请求的方法，方法只能接受一个参数，如果你需要传递多个参数，那么请将他们封装成一个类参数
@HystrixCollapser注解中的scope属性：设置请求方式，默认为REQUEST
@HystrixCollapser注解中的timerDelayInMiliseconds属性：设置时间间隔
@HystrixCollapser注解中的maxRequestsInBatch属性：设置批处理中允许的最大请求数
4.修改Controller
5.项目结构，启动测试
测试结果
五、服务熔断
服务熔断机制相当于电路的跳闸功能
例如：我们可以配置熔断策略为当请求错误比例在10s>50%时，该服务将进入熔断状态，后续请求都会进入fallback
1.创建项目，配置pom.xml文件，添加各种依赖
2.修改application.properties/yml配置文件
3.修改ProductService
@HystrixCommand(fallbackMethod ="fallback",
commandProperties = {
//默认20个;10内请求数大于20个时就启动熔断器,当请求符合熔断条件时将出发getFallback()
@HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD,value ="10"),
//请求错误率大于50%时就熔断,然后for循环发起请求,当请求符合熔断条件时将触发getFallback()
@HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE,value ="50"),
//默认5秒;熔断多少秒后去尝试请求
@HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS,value ="5000"),
})
4.编写Controller，修改启动类，使用@EnableCircuitBreaker开启熔断器/断路器，使用@EnableEurekaClient开启Eureka客户端
5.项目结构
熔断参数详解：
circuitBreaker.enabled：是否开启熔断
circuitBreaker.requestVolumeThreshold：一个统计窗口内熔断触发的最小个数/10s
circuitBreaker.sleepWindowInMiliseconds：熔断多少秒后去尝试请求
circuitBreaker.errorThresholdPercentage：失败率达到多少百分比后熔断
circuitBreaker.forceOpen：是否强制开启熔断
circuitBreaker.forceClosed：是否强制关闭熔断
六、线程池隔离
Hystrix处理资源隔离有两种解决方案
a.线程池隔离 b.信号量隔离
线程池隔离：线程池隔离将不同的服务调用处理隔离为不同的线程，为这些线程开辟一个独立的、抽象的空间，称为线程池，互不干扰
线程池隔离优点：
a.使用线程池可以完全隔离依赖的服务，请求线程可以快速放回
b.当线程池出现问题时，线程池隔离是独立的，不会影响其他服务和接口
c.当失败的服务再次变得可用时，线程池将清理并立即恢复，而不需要一个长时间的恢复
d.独立的线程池提高了并发性
缺点：线程池隔离的主要缺点是他们增加计算开销（CPU）。每个命令的执行涉及到排队、调度和上下文切换且都是在一个单独的线程上运行的
1.创建项目，配置pom.xml文件，添加各种依赖
2.配置applicaiton.properties/yml全局文件
3.修改ProductService
@HystrixCommand(groupKey ="ego-product-provider",
commandKey ="getUsers", threadPoolKey ="ego-product-provider",
threadPoolProperties = {@HystrixProperty(name ="coreSize", value ="30"),//线程池大小
@HystrixProperty(name ="maxQueueSize", value="100"),//最大队列长度
@HystrixProperty(name ="keepAliveTimeMinutes", value ="2"),//线程存活时间
@HystrixProperty(name ="queueSizeRejectionThreshold", value ="15")//拒绝请求
}, fallbackMethod ="fallback")
4.配置启动类，@EnableCircuitBreaker开启熔断器
5.启动测试
常用注解各项参数讲解：
@HystrixCommand注解中的threadPoolProperties属性：配置线程池各项属性
@HystrixProperty注解：配置详细参数信息
隔离参数：
groupKey：服务名（相同服务用一个名称、如商品、用户等等）
commandKey：接口（服务下面的接口，如购买商品）
threadPoolkey：线程池的名称：配置全局唯一标识线程池的名称，相同线程池名称的线程池是同一个
coreSize：线程池大小：这是最大的并发执行数量
maxQueueSize：最大队列长度：设置BlockingQueue的最大长度
queueSizeRejectionThreshold：拒绝请求：设置拒绝请求的临界值
keepAliveTimeMinutes：线程存活时间：设置存活时间，单位分钟
最后附上Eureka服务注册中心
