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

1、使用IDEA新建一个 microservice-provider-hystrix 工程
因为此工程要受到Hystrix保护，所以加入依赖.

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

2、在microservice-provider-hystrix 工程的启动类上启用断路器
在启动类上加入注解
@EnableCircuitBreaker //启用断路器
注意: 这里其实也可以使用 spring cloud应用中的@SpringCloudApplication注解，因为它已经自带了这些注解,源码如下:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public @interface SpringCloudApplication {

}

3、在 ProductController中加入断路逻辑

@RequestMapping("/get/{id}")
    @HystrixCommand(fallbackMethod="errorCallBack")   //模仿没有这个数据时，服务降级
  public Object get(@PathVariable("id") long id){
        Product p=this.productService.findById(id);
        if( p==null){
            throw new RuntimeException("查无此产品");
        }
        return p;
    }

    //指定一个降级的方法
    public Object errorCallBack(  @PathVariable("id") long id   ){
        return id+"不存在,error";
    }

4、启动provider服务后测试