Hystrix应用场景

最近项目用4.0的开发框架，熔断这块将是重点，在这里简单介绍下熔断。

认识Hystrix

Hystrix是Netflix开源的一款容错框架，包含常用的容错方法：线程隔离、信号量隔离、降级策略、熔断技术。
在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢，资源突然繁忙，暂时不可用，服务脱机等。我们要构建稳定、可靠的分布式系统，就必须要有这样一套容错方法。

为什么需要Hystrix？

image

在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等.

雪崩效应：
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程

出现不可用，但是其他依赖仍然可用.

image

当依赖I 阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.如下图:

image

在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

Hystrix特性

1.断路器机制

断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力

断路器触发机制

• 快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。
• 请求总数下限：在快照时间窗内，必须满足请求总数下限才有资格根据熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用此时不足20次，即时所有的请求都超时或其他原因失败，断路器都不会打开。
• 错误百分比下限：当请求总数在快照时间窗内超过了下限，比如发生了30次调用，如果在这30次调用中，有16次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%下限情况下，这时候就会将断路器打开。

2.Fallback

Fallback相当于是降级操作（降级策略）. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.

3.资源隔离

在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.

线程隔离的缺点:

线程池的主要缺点就是它增加了计算的开销，每个业务请求（被包装成命令）在执行的时候，会涉及到请求排队，调度和上下文切换。不过Netflix公司内部认为线程隔离开销足够小，不会产生重大的成本或性能的影响。
Netflix API每天使用线程隔离处理10亿次Hystrix Command执行。 每个API实例都有40多个线程池，每个线程池中有5-20个线程（大多数设置为10个）。
https://www.jianshu.com/p/df1525d58c20

hystrix参数设置
https://www.cnblogs.com/520playboy/p/8074347.html

信号隔离
线程计算机中有限的宝贵资源，线程的调度也需要由用户空间切换到操作系统空间。可以通过Semaphore或者counts限制对依赖资源的并发访问量。如果是同一个业务部同资源的隔离，建议使信号隔离。在需要申请资源时，先去try获取一个permit。在获取的过程中不需要操作系统参与，所以相比于线程来说，信号是个轻量级的隔离方式。
信号量的资源隔离只是起到一个开关的作用，例如，服务X的信号量大小为10，那么同时只允许10个tomcat的线程(此处是tomcat的线程，而不是服务X的独立线程池里面的线程)来访问服务X，其他的请求就会被拒绝，从而达到限流保护的作用。
两种隔离方式对比

当请求的服务网络开销比较大的时候，或者是请求比较耗时的时候，我们最好是使用线程隔离策略，这样的话，可以保证大量的容器(tomcat)线程可用，不会由于服务原因，一直处于阻塞或等待状态，快速失败返回。而当我们请求缓存这些服务的时候，我们可以使用信号量隔离策略，因为这类服务的返回通常会非常的快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了缓存服务的效率

对比项	线程池隔离	信号量隔离
线程	与调用线程非相同线程	与调用线程相同（jetty线程）
异步	排队、调度、上下文开销等	无线程切换，开销低
并发支持 支持	支持（最大线程池大小）	支持（最大信号量上限）

熔断技术

如何使用Hystrix？

监控环境搭建

第一步：创建一个普通的Spring Boot工程
创建一个Spring Boot工程这个比较简单，直接创建一个名为hystrix-dashboard的Spring Boot工程。

第二步：添加相关依赖
Spring Boot工程创建好之后，修改pom.xml文件，添加相关依赖，如下：

    com.belle.blf
    blf-tools
    4.0.1-SNAPSHOT


blf-hystrix-center
blf::tools::hystrix::center


    
        org.springframework.boot
        spring-boot-starter
    

    
        org.springframework.boot
        spring-boot-starter-actuator
    
    
        org.springframework.cloud
        spring-cloud-starter-hystrix
    
    
        org.springframework.cloud
        spring-cloud-starter-hystrix-dashboard
    

第三步：入口类上添加注解
添加好依赖之后，在入口类上添加@EnableHystrixDashboard注解，表示开启仪表盘功能，如下：

@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardApplication {

    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboardApplication.class, args);
    }
}

运行效果
环境搭建成功之后，运行这个Spring Boot工程，我们可以看到如下页面：
[图片上传失败...(image-bf77be-1527554854790)]

改造要监控的服务

我们来改造一下我们的服务消费者工程，改造方式很简单，两个步骤就搞定，首先在pom.xml文件中添加如下依赖

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

然后在服务消费者工程的入口类上添加@EnableCircuitBreaker注解，表示开启断路器功能。此时，我们再来启动我们的eureka-server、provider(blf-itg)、和consumer(blf-pmsn)工程

模拟调用单据编码熔断

@ApiOperation(value="测试获取系统单据编号", notes="")
    @GetMapping("/code_test.json")
    @HystrixCommand(fallbackMethod = "fallback")
    public String getTestSheeIdCode(){
        int randomInt= random.nextInt(10) ;
        if(randomInt< 8){   //模拟调用失败情况
            throw new RuntimeException("call dependency service fail.");
        }
        return systemCodeFeignApi.getSystemCode("1001");
    }

    public String fallback(){
        return "some exception occur call fallback method.";
    }

参数详解
OK，仪表盘已经显示出来了，那么仪表盘上的各项数据都是什么意思呢？我们来看下面一张图：

[图片上传失败...(image-5768cd-1527554854790)]

Hystrix-feign

fegin接口

@FeignClient(url = "http://localhost:10031",name = Applications.FEIGN_BLF_ITG_API,fallback = SystemCodeHystrixClient.class)
public interface SystemCodeFeignApi {
    
    /**
     * 根据字段获取单据编号
     * @param sysCodeId
     * @param
     * @return
     */
    @RequestMapping(value = "/blf-itg-api/itg/api/sysCodeRule/getSheetIdCode.json", method = RequestMethod.GET)
    public String getSystemCode(@RequestParam(value = "sysCodeId") String sysCodeId);

}

fallback

@Component("systemCodeHystrixClient")
public class SystemCodeHystrixClient implements SystemCodeFeignApi {
    private static final Logger LOGGER = LoggerFactory.getLogger(SystemCodeHystrixClient.class);


    @Override
    public String getSystemCode(String sysCodeId) {
        return "-1";
    }

feign-Consume

@ApiOperation(value="测试获取系统单据编号", notes="")
@GetMapping("/feign_code_test.json")
public String getTestFeignSheeIdCode(){
    return systemCodeFeignApi.getSystemCode("1001");
}

feign-Service

@ApiOperation(value="获取系统单据编号", notes="")
@GetMapping("/getSheetIdCode.json")
public String getSystemCode(@RequestParam(value = "sysCodeId") String sysCodeId){
    try {
        System.out.println("开始休眠");
        //故意设置让客户端等待超时
        Thread.sleep((long)50000);
        System.out.println("休眠结束");
    }catch (Exception e){

    }
    String sysCode="";
    if(StringUtils.isEmpty(sysCodeId)){
        sysCode="-1";
    }
    sysCode=service.doSysCodeByID(sysCodeId);
    return sysCode;

 }

相关超时参数设置

hystrix:
  threadpool:
    # default: 默认参数，作用的所有的hystrix的客户端
    default:
      coreSize: 10
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation:
          thread:
            timeoutInMilliseconds:  60000

turbine:
  cluster-name-expression: "default"
  combine-host-port: true

#默认关闭
feign:
  hystrix:
    enabled: true

###Ribbon的超时            
ribbon:
  ReadTimeout:  60000
  ConnectTimeout: 60000
  
从Spring Cloud Edgware开始，Feign支持使用属性配置超时：
feign:
    client:config:
        feignName:
            connectTimeout:5000
            readTimeout:5000