hystrix熔断和降级的区别_学习笔记32-Hystrix

处理灾难性雪崩效应

1、

2、

3、

4、

解决灾难性雪崩效应的方法：

降级、缓存、请求合并、熔断、隔离

---降级：对服务做降级处理

创建consumer项目，添加Hystrix的坐标

修改启动类，开启熔断器

配置文件

在Service项目中新建Product实体类，在service接口中添加方法，使用昨天的feign项目，所以provider和service项目稍作修改即可。

在新建的consumer项目中添加fallback方法

启动项目，发起请求，当停止provider时继续请求将会返回托底数据。

触发fallback方法：

(1) 方法抛出非 HystrixBadRequestException 异常。

(2) 方法调用超时

(3) 熔断器开启拦截调用

(4) 线程池/队列/信号量是否跑满

--缓存：Hystrix 为了降低访问服务的频率，支持将一个请求与返回结果做缓存处理。如果再次请求的 URL 没有变化，那么 Hystrix 不会请求服务，而是直接从缓存中将结果返回。这样可以大大降低访问服务的压力。

Hystrix 自带缓存。有两个缺点：

1. 是一个本地缓存。在集群情况下缓存是不能同步的。

2. 不支持第三方缓存容器。Redis，memcache 不支持的。

可以使用 spring 的 cache。

创建一个新的consumer项目，添加Hystrix和redis的坐标

配置redis

修改启动类开启缓存

配置consumer项目的方法

给key-value添加前缀，开启缓存，清除缓存

启动测试

--请求合并：

没有合并的请求：

合并之后的请求：

使用请求合并：在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相配合工作，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加，同时，线程池的资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解 Hystrix 的请求合并。

请求合并的缺点：设置请求合并之后，本来一个请求可能 5ms 就搞定了，但是现在必须再等 10ms 看看还有没有其他的请求一起的，这样一个请求的耗时就从 5ms 增加到 15ms 了，不过，如果我们要发起的命令本身就是一个高延迟的命令，那么这个时候就可以使用请求合并了，因为这个时候时间窗的时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景。

创建新的consumer项目，修改访问的方法：

请求合并参数：

--服务熔断：

创建新的consumer项目，添加Hystrix依赖，在启动类上添加熔断器

修改consumer中的方法：

参数：

--隔离（线程池隔离）

创建项目添加依赖开启熔断器

修改方法在注解上添加配置：

参数：

--隔离（信号量隔离）：

创建项目添加依赖

修改方法：

参数：

线程池隔离和信号量隔离的区别：

可视化的数据监控：Hystrix-dashboard 是一款针对 Hystrix 进行实时监控的工具，通过 HystrixDashboard 我们可以在直观地看到各 Hystrix Command 的请求响应时间, 请求成功率等数据。

将原有的consumer项目拷贝一份，添加依赖：

在启动类上加入注解开启dashboard

接口继承provider

依次启动provider和consumer，访问list，触发降级，

访问dashboard

输入要监控的地址

详细参数介绍

Turbine：

Turbine 是聚合服务器发送事件流数据的一个工具，hystrix的监控中，只能监控单个节点，实际生产中都为集群，因此可以通过turbine来监控集群服务。

可以使用RabbitMQ来收集监控数据

案例略。