简单说一下Hystrix

Hystrix是一个微服务的自我保护机制，它具体有什么作用呢？

首先我们来说说微服务可能会出现的问题，比方说一个电商网站的微服务，客户端发送请求过来，看中了一个商品，想要下单支付，这个过程中涉及到很多微服务，比如商品展示服务，购物车服务，订单提交服务，但是如果客户下单的时候，某一个微服务出现了问题，比如购物车服务出现了问题，那么这个服务将会被延迟，并且没办法进行下一个微服务也就是订单提交服务，这个时候整个过程就被延迟了，然而延迟到了一定的时候，有些客户也会不耐烦，一直点击提交操作，然而这会占用服务器的内存，给服务器增加压力，越来越多的提交操作后，服务器将会承受不了这些压力而导致崩溃，所以这就是雪崩问题（雪在山顶上崩开了，导致了一系列的后果）。

如上图所示，一个客户的请求将会调用多个微服务

一旦有一个微服务卡住了，整个服务过程都没办法继续了

如上图所示，这个微服务发生了异常，将会有越来越多的客户卡在这个微服务里面动不了，线程越来越多，并且无法释放，造成服务器压力很大，线程也会被阻塞

那么Hystrix起到一个什么作用呢？Hystrix就是自我保护机制，可以保护服务器可以正常运行而不会发生这种雪崩问题，面对雪崩问题，它提供了两种解决方法：
1.线程隔离
2.服务熔断

先来看一下这个图

使用了Hystrix后会为每个微服务生成一个线程池，每次用户发来请求的时候，都会直接调用线程池里面的微服务进行服务，如果有一个服务出现了故障的话，就会让请求延迟，如果长时间没解决这个问题，那么Hystrix将会让当前微服务拒绝请求，还有一种情况就是，用户的请求太多，很多用户发请求过来某一个微服务，微服务的连接量已经达到了上限，这个时候该微服务也会去拒绝超过上限后还来访问的用户请求，开始自我保护。

除了这个，Hystrix也会服务降级，也就是说出现了上述的情况后，服务器不会什么都不会反馈就直接拒绝，而是有一个专门的说明或者一个友好的信息提醒来向用户提示该请求出现了问题，这就是Hystrix的服务降级。

总的来说，为了解决微服务的雪崩问题，Hystrix就会建立一个线程池让用户去连接，然后用户如果太多或者微服务发生故障导致请求超时了，Hystrix会让服务器进行拒绝请求并且使用服务降级，也就是返回一个友好的提醒。

关于线程池的这个解释是用户不再直接访问微服务，而是访问线程池，在线程池中调用自己的服务，这样比较方便

所以这个Hystrix在哪里配置呢，有以下三个选项，你会选哪一个

客户端，服务端，注册中心

首先我们要知道Hystrix的功能，刚刚上面我们也讲过，主要是用于建立连接池还有帮微服务拒绝用户请求并且服务降级，那既然是用来建立连接池，有些同学就会想，会不会是在服务端进行建立，答案并不是的，因为如果你在服务端进行建立，这么多个客户给你发送请求，你怎么去每个都判定每条服务都顺不顺利，有没有超时，还有就是需不需要拒绝，这么多客户的请求，你一个微服务很难去兼顾每一个客户的感受，所以我们需要把Hystrix直接配置到客户的身上，让他们自己去记录自己的访问时间，还有是否超过连接上限，如果他们访问出现了故障，让他们自己触发机制去发送请求让我们进行服务降级，不香吗？

该如何配置Hystrix？

首先，我们在客户端这边的pom中添加依赖

版本号不要，因为我们已经统一管理版本了，不需要自己写版本号了。
springcloud的版本可以都不用写，最后写个管理版本号就可以了，避免版本对应不上而出现错误

这里复习一下我们导入springcloud的一些组件功能该如何导入，之前一篇博客说过，就是三个步骤：
1.导入启动器
2.覆盖配置
3.添加到引导类

这上面的导入依赖即是我们导入启动器的步骤，然后配置的话我们也不需要配置了，因为Hystrix不需要我们在yml中写相关的配置，我们只需要做最后一步就可以了，也就是添加到引导类

红色框圈起来的部分就是添加到引导类的注解，Hystrix也是相当于一个熔断器，因为请求过多负载过多或者微服务出现问题，Hystrix也会让服务器熔断，所以也是相当于家里电路的保险丝一样，保障家里电路的安全

除了在引导类配置完之外，别忘了我们Hystrix的核心功能哦，就是降级服务，服务器过载后用户访问不了了，我们是不是需要给客户返回一个页面告诉客户他的访问已经被拒绝了，因为服务器过载的原因，不能让客户一直等，因此，怎么去做这个页面返回给客户呢，我们需要在controller类里面去完成它，以下就是controller的配置：

先看看最下面的那个方法，我们必须要保证我们写的Hystrix返回页面的controller方法要对应我们相关的微服务方法，所以最下面的那个方法，方法类型，返回值，传入参数，都要和上面的那个方法一样，当然，方法名不可以一样，还有注解也是不需要，其他都要保持一样，因为上面的方法返回值本来是User，但是为了返回相关提示给客户，我这里就改成了返回值为String类型，那问题来了，我该如何告诉程序，如果上面的方法出问题了或者服务器过载了，就调用下面那个方法呢？因此，我们需要在上面的方法那里打上注解使用fallbackMethod方法，并且指定fallbackMethod为下面的那个方法，把方法名写上去，好了，这样一个Hystrix的配置就写好了

我们来测试一下，但是我们可以关掉服务端的部署，然后测试一下

这样就可以返回一个熔断信息了

那这个时候就有疑问了，以上的配置是针对某一个微服务的Hystrix的配置，我真正要做项目的时候，controller方法里面肯定不止一个微服务的controller啊，到时候会有成百上千个方法，难道要像上面的方法一样一个个去加注解去配置吗，一个个去写对应的Hystrix返回信息吗，我就不能有一个全局的配置来完成Hystrix的配置吗，答案当然是，有！

我们可以在controller最大的那个方法里面（也就是最外层的那个方法）写全局配置

这个注释加上了，然后再写上defaultFallback方法，然后去指定那个Hystrix的方法的方法名（方法名我已经改了，因为刚刚只是配置一个方法的，现在是配置全局的了，所以方法名改成fallbackMethod）。

还要注意的是，我们也要去掉单个微服务对应的controller的注解方法

红框圈住的部分需要去掉，但是注解需要保留

为什么要保留注解呢？因为你的controller里面不是所有方法都需要熔断，有的需要熔断，有的不需要，那如何告诉程序你需要在哪些方法上配置Hystrix对吧，你只能通过打上这个注解来告诉程序你配置在哪些上

配置了全局熔断方法之后，我们需要注意一点：

如果是全局熔断，刚刚讲的熔断方法返回值，方法类型，参数类型不是都要和全部方法都要一样吗？

如果是全局熔断，我们需要注意的是方法返回值我们全部方法都需要写成String，因为熔断方法返回的是一段提示，也就是字符串，如果我们写其他的返回值的话，将会让服务降级无法返回文字提醒给用户，还有一点就是传入的参数，可以看到上面传入的参数方法是Long id，只有这一个方法的时候我们熔断方法可以跟着它去写，但是如果有其他方法的话该怎么办，比如出现了一个String phone，或者int num，那我们的熔断方法就不和大家一致了啊，所以我们需要的就是把熔断方法的参数类型和参数去掉，写成一个空的，如下

这样就可以无论你写的是什么controller也一样能使用熔断方法。

在这里对超时时间进行设置，Hystrix可以设定超过多少时间服务器没响应，这个服务就自动断开，只要在yml文件中配置上上图所示配置即可。

不知道大家有没有观察到，我们的引导类上面有很多注解，这些注解太多是不是很麻烦？我们可以选择简化这些注解，也就是只用一个注解来代替这些全部的注解

如上图所示，我们可以用一个springcloudApplication来替代上面的全部注解，因为这个注解是springcloud的一个专门注解，标注了之后代表这个引导类的功能就是springcloud的了，所以只用这一个注解就可以了

Hystrix也有一个特点，一般来说如果是其他熔断的话，一般服务器过载，客户端自动熔断后是不可以重新连接回来，但是如果是Hystrix的话，服务器过载，服务器熔断了，一旦情况好转了，Hystrix也可以让一些客户端能够实现连接回来。

Hystrix的三个状态：

1.关闭状态。
也就是熔断器关闭，所有服务正常运行
2.打开状态
熔断器打开，所有的服务都被熔断，如果百分之50的请求没有响应，并且有超过20以上的请求，那么熔断器就会自动打开，然后所有的服务就会被熔断。
3.半打开半关闭状态
如果熔断器打开了，那么在所有服务都降级的情况下，熔断器会自己尝试进行关闭，但不会全部关闭，而是只关闭一半，并且接受一部分请求的传入，如果这一部分请求都是健康的，也就是运行起来没有问题的，那么熔断器自己就会全部关闭，让全部服务正常运行。

这三个在yml中配置的参数分别表示，最少的响应失败的请求数，休眠时间，响应失败的请求占比