springCloud学习笔记(三)--服务降级--Hystrix

一、Hystrix熔断器

1. 分布式系统面临的问题:                                                                                                                                                              复杂分布式体系结构中的应用程序 有数10个依赖关系,每个依赖关系在某些时候将不可避免地失败                                          服务雪崩
          多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的”扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
           对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
   所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。
2. Hystrix是什么   [ 家里的保险丝]                                                                                                                                                      Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
   “断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
3. Hystrix能干吗
   1. 服务降级
   2. 服务熔断
   3. 接近实时的监控
   4. 限流
   5. 隔离等等
4. Hystrix官网资料 https://github.com/Netflix/hystrix/wiki
5. Hystrix停更 https://github.com/Netflix/hystrix
   1. 被动修复bugs
   2. 不再接受合并请求
   3. 不再发布新版本

二、HyStrix重要概念

1. 服务降级
   1. 服务器忙,请稍后再试,不让客户端等待并立刻返回一个友好提示,fallback
   2. 哪些情况会服务降级
      1. 程序运行异常
      2. 超时
      3. 服务熔断触发服务降级
      4. 线程池/信号量也会导致服务降级
2. 服务熔断
   1. 类比保险丝达到最大服务访问后,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示
   2. 就是保险丝  服务的降级->进而熔断->恢复调用链路
3. 服务限流
   1. 秒杀高并发等操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序进行

三、HyStrix案例

3.1构建

1. 新建cloud-provider-hystrix-payment8001
2. POM
3. YML
4. 主启动
5. 业务类
6. 测试:以上述为根基平台,从正确->错误->降级熔断->恢复

3.2高并发测试

1. 上述在非高并发情形下,还能勉强满足 but...
2. Jmeter压测测试
   1. 下载 https://jmeter.apache.org/download_jmeter.cgi  https://downloads.apache.org/jmeter/binaries/
   2. 开启Jmeter,来20000个并发压死8001,20000个请求都去访问paymentInfo_TimeOut服务
   3. 再来一个访问
   4. 结果
      1. 两个都在转圈圈,都变慢了
      2. 为什么会被卡死: tomcat的默认工作线程数被打满了,没有多余的线程来分解压力和处理
3. Jmeter压测结论  上面还只是服务提供者8001自己测试,假如此时外部的消费者80也来访问,那消费者只能干等,最终导致消费端80不满意,服务端8001直接被拖死
4. 看热闹不嫌弃事大,80新建加入
   1. cloud-consumer-feign-hystrix-order80
   2. 正常测试 http://localhost/consumer/payment/hystrix/ok/32
   3. 高并发测试
      1. 2w个线程压8001
      2. 消费者80微服务再去访问的OK服务8001地址 http://localhost/consumer/payment/hystrix/ok/32
      3. 消费者80,o(╥﹏╥)o
         1. 要么转圈圈
         2. 要么消费端报超时错误

3.3故障和导致现象

8001同一层次的其他接口被困死,因为tomcat线程池里面的工作线程已经被挤占完毕

80此时调用8001,客户端访问响应缓慢,转圈圈

正因为有上述故障或不佳表现  才有我们的降级/容错/限流等技术诞生

3.4如何解决

1. 超时导致服务器变慢(转圈)  超时不再等待
2. 出错(宕机或程序运行出错)  出错要有兜底
3. 对方服务(8001)超时了,调用者(80)不能一直卡死等待,必须有服务降级
4. 对方服务(8001)down机了,调用者(80)不能一直卡死等待,必须有服务降级
5. 对方服务(8001)ok,调用者(80)自己有故障或有自我要求(自己的等待时间小于服务提供者)

3.5服务降级

1. 降级配置@HystrixCommand
2. 8001先从自身找问题
   1. 设置自身调用超时时间的峰值,峰值内可以正常运行,  超过了需要有兜底的方法处理,做服务降级fallback
3. 8001fallback
   1. 业务类启用  @HystrixCommand报异常后如何处理 一旦调用服务方法失败并抛出了错误信息后,会自动调用@HystrixCommand标注好的fallbckMethod调用类中的指定方法
   2. @EnableCircuitBreaker
   3. 
4. 80fallback
   1. 80调用8001,8001正常峰值执行5s,80只能等待2s,所以80也要有自己的fallback
   2. 80订单微服务,也可以更好的保护自己,自己也依样画葫芦进行客户端端降级保护
   3. 我们自己配置过的热部署方式对java代码的改动明显,但对@HystrixCommand内属性的修改建议重启微服务
   4. POM
   5. YML
   6. 主启动@EnableHystrix
   7. 业务类
5. 目前问题
   1. 每个业务方法对应一个兜底的方法,代码膨胀
   2. 统一和自定义的分开
6. 解决办法
   1. 每个方法配置一个???膨胀
      1. feign接口系列
      2. @DefaultProperties(defaultFallback="")
      3. controller配置
   2. 和业务逻辑混在一起???混乱
      1. 服务降级,客户端去调用服务端,碰上服务端宕机或关闭
      2. 本次案例服务降级处理是在客户端80实现完成,与服务端8001没有关系  只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦
      3. 未来我们要面对的异常:运行 超时 宕机
      4. 再看我们的业务类PaymentController
      5. 修改cloud-consumer-feign-hystrix-order80
      6. 根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口,重新新建一个类(PaymentFallbackService)实现接口,统一为接口里面的方法进行异常处理
      7. PaymentFallbackService类实现PaymentFeginService接口
      8. YML
      9. PaymentFeignClientService接口
      10. 测试
          1. 单个eureka先启动7001
          2. PaymentHystrixMain8001启动
          3. 正常访问测试
          4. 故意关闭微服务8001
          5. 客户端自己调用提示  此时服务端provider已经downl ,但是我们做了服务降级处理,  让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器

3.6服务熔断

1. 断路器
2. 熔断是什么:https://martinfowler.com/bliki/CircuitBreaker.html
   1. 熔断机制概述
      熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，
      会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。
      当检测到该节点微服务调用响应正常后，恢复调用链路。
   2. 在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，
      当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是@HystrixCommand。
3. 实操
   1. 修改cloud-provider-hystrix-payment8001的service和controller
   2. 输入负数就服务降级
   3. 测试
      1. 正确:http://localhost:8001/payment/circuit/31
      2. 错误:http://localhost:8001/payment/circuit/-31
   4. 一开始输入负数,只是服务降级,后来超过配置的出错率,被迫打开断路器,这个时候正确的也访问不到了,过一会才恢复
4. 总结
   1. 服务熔断:服务降级->服务熔断->恢复调用链路
   2. 熔断打开:请求不再调用当前服务,内部设置一般为MTTR(平均故障处理时间),当打开长达导所设时钟则进入半熔断状态
   3. 熔断关闭:熔断关闭后不会对服务进行熔断
   4. 熔断半开:部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断
   5. 断路器什么时候起作用:
      1. 涉及到断路器的三个重要参数:快照时间窗、请求总数阀值、错误百分比阀值。
      2. 快照时间窗:断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。
      3. 请求总数阀值:在快照时间窗内，必须满足请求总数阀值才有资格熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用次数不足20次即使所有的请求都超时或其他原因失败，断路器都不会打开。
      4. 错误百分比阀值:当请求总数在快照时间窗内超过了阀值，比如发生了30次调用，如果在这30次调用中，有15次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%阀值情况下，这时候就会将断路器打开。
   6. 断路器打开之后:
      1. 再有请求调用的时候，家不会调用主逻辑，而是直接调用降级fallback。通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。
      2. 原来的主逻辑要如何恢复呢?
         对于这一问题，hystrix也为我们实现了自动恢复功能。
         当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。
   7. 全部参数

3.7总结

1. 工作流程:https://github.com/Netflix/Hystrix/wiki/How-it-Works
2. 步骤说明

3.8仪表盘

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控(Hystrix Dashboard)，Hystrix会持续地记录所有通过Hystrik发
起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通时
hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。