概述/Hystrix重要概念/ Hystrix案例
概述
官网:https://github.com/Netflix/Hystrix/wiki/How-To-Use
分布式系统面临的问题
有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。互相调用，链路越来越长，一个出事了，就会导致整条链路上的服务都出事。
服务雪崩
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。
Hystrix 是什么
Hystrix 是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
断路器本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的，可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
Hystrix能做什么
- 服务降级
- 服务熔断
- 接近实时的监控
- …………………
Hystrix 重要概念
服务降级：fallback
当发现系统压力过载时，可以通过关闭某个服务，或者限流某个服务来减轻系统的压力，这就是服务降级！
服务熔断：break
当服务A 调用 某个 服务B 不可用时，上游服务A为了保证自己不受影响，从而不再调用B，直接返回一个结果，减轻服务A 与 B 的压力，直到B恢复！
服务限流：flowlimit
秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行 flowlimit
降级和熔断的区别:
- 1.相同:都是为了防止系统崩溃
- 2.相同：都让榕湖体验到某些功能暂时不可用
- 3.不同：熔断是被调用方(下游服务)故障触发的，降级是为了降低系统负载
Hystrix案例
构建正确提供者模块
搭建基础平台：从正确—>错误—>降级熔断—>恢复，以此平台 演示 Hystrix 服务降级 服务熔断 服务限流
1.建module
创建cloud-provider-hystrix-payment8001模块
2.改pom.xml
pom.xml
3.yml
application.yaml
4.主启动类
hystrixMain8001
5.业务类
PaymentService
折叠内容，点击展开折叠内容
正常测试
1.http://127.0.0.1:8001/payment/hystrix/ok/1 秒开
2.http://127.0.0.1:8001/payment/hystrix/timeout/1 3秒后开
高并发测试
设置20000个并发压死8001
结果发现原来可以迅速响应的http://localhost:8001/payment/hystrix/ok/1 变得卡顿。两个都在转圈。
原因：
因为ok跟timeout都在一个微服务里，现在大量的资源被timeout占用，微服务必须集中资源去处理这些 高并发的请求。那么ok方法，得到的资源就少，进而被影响。SpringBoot默认集成的是tomcat容器，里面有一个tomcat的线程池，高并发下没有多余的 线程来分解压力和处理ok方法。 每个线程都要等待3秒钟，才能拿到timeout的结果响应。那么2000个线程一起过来， Tomcat池子里的线程，马上就会被抢占完。
新建消费者模块
1.建module
新建消费者模块：cloud-consumer-feign-hystrix-order80
2.改pom
pom.xml
3.改yaml
pom.xml
4.主启动类
OrderFeignHystrixMain80
5.业务类
PaymentHystrixService
折叠内容，点击展开折叠内容
正常测试
1.正常 :http://127.0.0.1:8001/payment/hystrix/timeout/1
2.报错: http://127.0.0.1/consumer/payment/hystrix/timeout/1
由于使用的是Feign作为客户端，默认1s没有得到响应就会报超时错误。这是正常的，这里我们不进行改动。
高并发测试
2W个线程压8001 消费端80微服务再去访问正常的OK微服务8001地址http://localhost/consumer/payment/hystrix/ok/1: 要么转圈圈等待，要么消费端报超时错误。
原因： 8001同一层次的其他接口服务被困死，因为tomcat线程池里面的工作线程已经被挤占完毕 所以80此时调用8001，客户端访问响应缓慢，转圈圈。 正因为有上述故障或不佳表现，才有了我们的降级/容错/限流等技术诞生。
Hystrix如何解决问题？
如何解决？解决的要求？
- 超时导致服务器变慢(转圈)：超时不再等待
- 出错(宕机或程序运行出错)：出错要有兜底
- 解决
- 对方服务(8001)超时了，调用者(80)不能一直卡死等待，必须有服务降级
- 对方服务(8001)down机了，调用者(80)不能一直卡死等待，必须有服务降级
- 对方服务(8001)OK，调用者(80)自己出故障或有自我要求（自己的等待时间小于服务提供者），自己处理降级
解决:https://www.tinstu.com/2248.html