Java中间件-Hystrix

一、背景介绍

1、服务雪崩

分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，

如果各个服务正常运行，那大家齐乐融融，高高兴兴的，但是如果其中一个服务崩坏掉会出现什么样的情况呢？如下图，

当Service A的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算Service A能扛得住请求，Service B和Service C未必能扛得住这突发的请求。

此时，如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用。

So，简单地讲。一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩。

2、引起雪崩的原因和服务雪崩的三个阶段

原因大致有四：

1、硬件故障；

2、程序Bug；

3、缓存击穿（用户大量访问缓存中没有的键值，导致大量请求查询数据库，使数据库压力过大）；

4、用户大量请求；

服务雪崩的第一阶段: 服务不可用；

第二阶段：调用端重试加大流量（用户重试/代码逻辑重试）；

第三阶段：服务调用者不可用（同步等待造成的资源耗尽）；

3、解决方案

1） 应用扩容（扩大服务器承受力）

加机器

升级硬件

2）流量控制（超出限定流量，返回类似重试页面让用户稍后再试）

限流

关闭重试

3） 缓存

将用户可能访问的数据大量的放入缓存中，减少访问数据库的请求。

4）服务降级

服务接口拒绝服务

页面拒绝服务

延迟持久化

随机拒绝服务

5） 服务熔断

如果对服务降级和服务熔断的概念模糊点此了解 关于服务熔断和服务降级的详解

二、Hystrix入门

Hystrix简介

Hystrix [hɪst’rɪks]，中文含义是豪猪，因其背上长满棘刺，从而拥有了自我保护的能力。

以项目案例开始，快速入门（使用IDEA）

场景假设1( 服务提供方报错) : 在服务提供端中因为访问不到数据库中的数据(比如数据不存在，或是数据库压力过大，查询请求队列中),在这种情况下，服务提供方这边如何实现服务降级,以防止服务雪崩.

使用IDEA新建一个
microservice-provider-hystrix 工程

因为此工程要受到Hystrix保护，所以加入依赖.

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>

</dependency>

在
microservice-provider-hystrix 工