文章目录

1 概述
- 1.1 分布式系统面临的问题
- 1.2 是什么
- 1.3 能干嘛
2 Hystrix重要概念
- 2.1 服务降级
- 2.2 服务熔断
- 2.3 服务限流
3 Hystrix案例
- 3.1 构建
- 3.2 高并发测试
- - 3.2.1 Jmeter压测测试
  - 3.2.2 Jmeter压测结论
  - 3.2.3 看热闹不嫌弃事大，80新建加入
- 3.3 故障现象和导致原因
- 3.4 上诉结论
- 3.5 如何解决？解决要求
- 3.6 服务降级
- 3.7 服务熔断
- 3.8 服务限流
4 hystrix工作流程
5 服务监控 hystrixDashboard
- 5.1 概述
- 5.2 仪表盘9001
- 5.3 断路器演示（服务监控hystrixDashboard）

1 概述

1.1 分布式系统面临的问题

1.2 是什么

1.3 能干嘛

服务降级
服务熔断
接近实时的监控

官网资料

https://github.com/Netflix/Hystrix/wiki/How-To-Use

Hystrix官宣，停更进维

https://github.com/Netflix/Hystrix

被动修复bugs
不再接收合并请求
不再发布新版本

2 Hystrix重要概念

2.1 服务降级

服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示，fallback
哪些情况会触发降级
1. 程序运行异常
2. 超时
3. 服务熔断触发服务降级
4. 线程池/信号量打满也会导致服务降级

2.2 服务熔断

类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示
服务的降级 -> 进而熔断 -> 恢复调用链路

2.3 服务限流

秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。

3 Hystrix案例

3.1 构建

1.新建 cloud-provider-hystrix-payment8001

2.pom

3.YML

4.启动类

5.业务类

service
controller

6.正常测试

启动 eureka7001
启动cloud-provide-hystrix-payment8001
访问
success的方法 http://localhost:8001/payment/hystrix/ok/31
每次调用耗费5秒钟 http://localhost:8001/payment/hystrix/timeout/31
上述module均OK
以上述为根基平台，从正确->错误->降级熔断->恢复

3.2 高并发测试

上述在非高并发情形下，还能勉强满足，but…

3.2.1 Jmeter压测测试

开启Jmeter，来20000个并发压死8001,20000个请求都去访问paymentInfo_TimeOut服务
再来访问一个
http://localhost:8001/payment/hystrix/ok/31
看演示结果
两个都在自己转圈圈
为什么会被卡死

3.2.2 Jmeter压测结论

上面还是服务提供者8001自己测试，假如此时外部的消费者80也来访问，那消费者只能干等，最终导致消费者80不满意，服务端8001直接被拖死

3.2.3 看热闹不嫌弃事大，80新建加入

1.新建 cloud-consumer-feign-hystrix-order80

2.pom

3.YML

4.主启动类

5.业务类

PaymentHystrixService
OrderHystrixController

6.正常测试

http://localhost/consumer/payment/hystrix/ok/31

7.高并发测试

2W个线程压8001
消费端80微服务再去访问正常的ok微服务8001地址
http://localhost/consumer/payment/hystrix/ok/32
消费者80
要么转圈圈等待
要么消费端报超时错误

3.3 故障现象和导致原因

8001在同一层次的其他接口服务被困死，因为tomcat线程池里面的工作线程已经被挤占完毕
80此时调用8001，客户端访问响应缓慢，转圈圈

3.4 上诉结论

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

3.5 如何解决？解决要求

超时导致服务器变慢（转圈）
超时不再等待
出错（宕机或程序运行出错）
出错要有兜底
解决
- 对方服务（8001）超时了，调用者（80）不能一直卡死等待，必须有服务降级
- 对方服务（8001）down机了，调用者（80）不能一直卡死等待，必须有服务降级
- 对方服务（8001）OK,调用者（80）自己出故障或有自我要求（自己的等待时间小于服务提供者），自己处理降级

3.6 服务降级

1.降级配置

@HystrixCommand

2.8001先从自身找问题

设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处理，作服务降级fallback

3.8001fallback

业务类启用

@HystrixCommand报异常后如何处理
一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法。
主启动类激活
添加新注解@EnableCircuitBreaker

4.80fallback

80订单微服务，也可以更好的保护自己，自己也依样画葫芦进行客户端降级保护
我们自己配置过的热部署方式对java代码的改动明显，但对@HystrixCommand内属性的修改建议重启微服务
YML
主启动
业务类

5.目前问题

每个业务方法对应一个兜底的方法，代码膨胀
统一和自定义的分开

6.解决问题

每个方法配置一个？？？膨胀
- feign接口系列
- DefaultProperties(defaultFallback=“”)
- controller配置
和业务逻辑混在一起？？？混乱
1. 服务降级，客户端去调用服务端，碰上服务端宕机或关闭
2. 本次案例服务降级处理是在客户端80实现完成的，与服务端8001没有关系，只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦
3. 未来我们要面对的异常
  运行超时宕机
4. 再看我们的业务类 PaymentController
5. 修改 cloud-consumer-feign-hystrix-order80
6. 根据cloud-consumer-feign-hystrix-order80已经有的PaymentHystrixService接口，重新新建一个类（PaymentFallbackService）实现该接口，统一为接口里面的方法进行异常处理
7. PaymentFallbackService类实现PaymentFeignClientService接口
8. YML
9. PaymentFeignClientService接口
10. 测试
  - 单个eureka先启动 7001
  - PaymentHystrixMain8001启动
  - 正常访问测试
    http://localhost/consumer/payment/hystrix/ok/31
  - 故意关闭微服务8001
  - 客户端自己调用提示
    此时服务端provider已经down了，但是我们做了服务降级处理，让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器

3.7 服务熔断

1.断路器    一句话就是家里的保险丝

2.熔断是什么？

https://martinfowler.com/bliki/CircuitBreaker.html

3.实操

修改 cloud-provider-hystrix-payment8001
PaymentService

why配置这些参数
PaymentController
测试
自测cloud-provider-hystrix-payment8001
正确：http://localhost:8001/payment/circuit/31
错误：http://localhost:8001/payment/circuit/-31
一次正确一次错误试试
重点测试：多次错误，然后慢慢正确，发现刚开始不满足条件，就算是正确的访问地址也不能进行

4.原理（小总结）

大神结论
熔断类型
- 熔断打开
  请求不再进行调用当前服务，内部设置时钟一般为MTTR(平均故障处理时间)，当打开时长达到所设时钟则进入半熔断状态
- 熔断关闭
  熔断关闭不会对服务进行熔断
- 熔断半开
  部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断
官网断路器流程图
- 官网步骤
- 断路器在什么情况下开始起作用
- 断路器开启或者关闭的条件
- 断路器打开之后
- ALL配置

3.8 服务限流

4 hystrix工作流程

https://github.com/Netflix/Hystrix/wiki/How-it-Works
Hystrix工作流程

官网图例
步骤说明

5 服务监控 hystrixDashboard

5.1 概述

5.2 仪表盘9001

新建cloud-consumer-hystrix-dashboard9001
pom
YML
主启动类
所有Provider微服务提供类(8001/8002/8003)都需要监控依赖配置
启动cloud-consumer-hystrix-dashboard9001 该微服务后续将监控微服务8001
http://localhost:9001/hystrix

5.3 断路器演示（服务监控hystrixDashboard）

修改cloud-provider-hystrix-payment8001

注意：新版本的Hystrix需要在主启动类MainAppHystrix8001中指定监控路径
Unable to coonect to Command Metric Stream

监控测试

启动1个eureka或者3个eureka集群均可
观察监控窗口
- 9001监控8001
- 填写监控地址：http://localhost:8001/hystrix.stream
测试地址
1. http://localhost:8001/payment/circuit/31
2. http://localhost:8001/payment/circuit/-31
3. 上述测试通过
4. 先访问正确地址，再访问错误地址，再正确地址，会发现图示断路器都是慢慢放开的。
  监控结果成功
  
  监控结果失败
如何看?
7 色
1圈

1线

整图说明

整图说明2

7.Hystrix断路器相关推荐

Spring Cloud构建微服务架构：服务容错保护（Hystrix断路器）【Dalston版】
前言在前两篇<Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)>和<Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)&g ...
Hystrix面试 - 深入 Hystrix 断路器执行原理
Hystrix面试 - 深入 Hystrix 断路器执行原理 RequestVolumeThreshold HystrixCommandProperties.Setter().withCircuitB ...
SpringCloud中 Feign结合Hystrix断路器开发。
Feign结合Hystrix断路器开发: 转载于:https://www.cnblogs.com/longdb/p/10468371.html
Hystrix断路器执行原理
深入 Hystrix 断路器执行原理 Hystrix熔断机制,用于监控微服务调用情况,当失败的情况达到预定的阈值(5秒失败20次),会打开断路器,拒绝所有请求,直到服务恢复正常为止. circuitB ...
五、Hystrix断路器
Hystrix断路器概述分布式系统面临的问题复杂分布式体系结构中的应用程序有数十个依赖关系,每一个依赖关系在某些时候将不可避免的失败. 服务雪崩多个微服务之间调用的时候,假如微服务A调用微服务 ...
Hystrix断路器原理及实现（服务降级、熔断、限流）
Hystrix断路器原理及实现(服务降级.熔断.限流) 分布式系统面临的问题 Hystrix重要概念(面试常考) Hystrix案例 Hystrix 服务提供者 Hystrix 服务消费者原因与解决 ...
Netflix Hystrix断路器简介与工作原理
一.前言? 1.Netflix Hystrix断路器是什么? Netflix Hystrix是SOA/微服务架构中提供服务隔离.熔断.降级机制的工具/框架.Netflix Hystrix是断路器的一种 ...
微服务——Hystrix断路器（豪猪哥）
提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档文章目录概述分布式系统面临的问题是什么能干嘛 Hystrix重要概念服务降级(fallback) 哪些情况会触发降级服务熔 ...
SpringCloud07 - Hystrix 断路器
扯淡: 服务与服务之间有业务关联就需要调用,当被调用的服务发生故障(上线后多半是由于网路原因导致连接超时),必然会波及到服务调用者.通俗讲,断路器就是在低层级的服务发生故障时将服务间的连接断开. 个人 ...
SpringClound——Hystrix断路器
SpringCloud学习资料汇总超级棒的如上是我在看文章时忽然看到的一个很好的学习SpringCloud的网站 SpringClound--微服务概述--史上最烂 SpringClound--Sp ...

7.Hystrix断路器