SpringCloud学习笔记（十二）基于Hystrix解决雪崩效应

专辑目录：SpringCloud学习日志

什么是雪崩效应？

当请求数量远超出服务器承受能力或者服务器无法再处理请求时，导致请求等待时间比较久，也就是平常说的卡。由于微服务是利用RPC相互请求的，所以可能一个接口无法访问或延迟响应，导致大量接口无法访问或延迟响应。

在项目上线之前，应该做压力测试来评估服务器承受能力。

插入一个知识点，设置Ribbon的请求响应等待时间。（如图设置超时响应时间为5秒）

###   springcluoud 默认开启ribbon了
ribbon:
  ###  响应超时时间，单位：毫秒
  ReadTimeout: 5000
  ###  连接超时时间，单位：毫秒
  ConnectTimeout: 5000

利用Hystrix解决雪崩效应的三大机制：服务降级、服务熔断、服务隔离

服务降级是最常用的方法，就是处理不了就不处理了，返回一个友好的提示给用户，省得用户一直等在无响应的页面。

服务熔断和服务降级是一起的，像线程池一样，超过了最大值就拒绝，然后用服务降级来提示。

服务隔离是为了防止大面积服务瘫痪，就是一个服务堵死了，其他服务也访问不了，所以将各个服务隔离开来，防止连续翻车。默认是线程池隔离的方式，即将不同的服务放在不同的线程池里，使其互不占用互不影响，但是缺点是CPU占用率大大提升，所以只对核心服务采用这种方法。

现在我们将hystrix引入项目，加入依赖

<!-- Hystrix断路器 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

然后在SpringBoot启动类加入注解:

@EnableHystrix

然后在application.yaml中配置hystrix的参数：

###  Hystrix
feign:
  hystrix:
    #启用Hystrix
    enabled: true

hystrix:
  command:
    default:
      execution:
        timeout:
          ### 关闭超时时间，如果不关闭，熔断之后就无法再访问了
          enabled: false
  threadpool:
    default:
      ### 线程池隔离时每个线程池最大线程数，默认是10
###   coreSize: 12

为了方便测试，我就不用RPC了，只用一个项目中进行演示。

@RestController
public class TestServiceImpl implements TestService {