Hystrix的原理及使用

 一、背景介绍

       1、服务雪崩

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

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

         当Service A的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算Service A能扛得住请求，Service B和Service C未必能扛得住这突发的请求。
此时，如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用。

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

原因大致有四：
1、硬件故障；
2、程序Bug；
3、缓存击穿（用户大量访问缓存中没有的键值，导致大量请求查询数据库，使数据库压力过大）；
4、用户大量请求；

服务雪崩的第一阶段: 服务不可用；
第二阶段：调用端重试加大流量（用户重试/代码逻辑重试）；
第三阶段：服务调用者不可用（同步等待造成的资源耗尽）；

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

加机器
升级硬件
2）流量控制（超出限定流量，返回类似重试页面让用户稍后再试）

限流
关闭重试
3） 缓存

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

4）服务降级

服务接口拒绝服务
页面拒绝服务
延迟持久化
随机拒绝服务
5） 服务熔断

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

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

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

1. 使用IDEA新建一个 microservice-provider-hystrix 工程
2. 因为此工程要受到Hystrix保护，所以加入依赖.
3. 3.在microservice-provider-hystrix 工程的启动类上启用断路器
   在启动类上加入注解
   @EnableCircuitBreaker //启用断路器
   注意: 这里其实也可以使用 spring cloud应用中的@SpringCloudApplication注解，因为它已经自带了这些注解,源码如下:

            org.springframework.cloud
            spring-cloud-starter-netflix-hystrix

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class application {
    public static void main(String[] args) {
        SpringApplication.run(application.class, args);
    }
}

@RestController
@RequestMapping("/test")
public class test {

    @GetMapping("/hello/{id}")
    @HystrixCommand(fallbackMethod="errorCallBack")       //模仿没有这个数据时，服务降级
    public Object hello(@PathVariable("id") long id){
        if(id == 0){
            throw new RuntimeException("查询无此产品");
        }
       return id;
    }

    //指定一个降级的方法
    public Object errorCallBack(@PathVariable("id") long id){
        System.out.println("降级了");
        return "接口失败";
    }
}