熔断机制

概念

• 服务熔断

当下游的服务由于某种缘由忽然变得不可用或响应过慢，上游服务为了保证本身总体服务的可用性，再也不继续调用目标服务，直接返回，快速释放资源。若是目标服务状况好转则恢复调用。

通常是指软件系统中，因为某些缘由使得服务出现了过载现象，为防止形成整个系统故障，从而采用的一种保护措施，因此不少地方把熔断亦称为过载保护。
适用场景：防止应用程序直接调用那些极可能会调用失败的远程服务或共享资源

• 服务降级

当服务器压力剧增的状况下，根据当前业务状况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

应该这么理解：服务降级有不少种降级方式，如开关降级、限流降级、熔断降级。服务熔断属于降级方式的一种！

• 雪崩效应

一种因 服务提供者 的不可用致使 服务调用者 的不可用,并将不可用 逐渐放大 的过程

分布式系统中常常会出现某个基础服务不可用形成整个系统不可用的状况, 这种现象被称为服务雪崩效应.。如：在分布式系统架构中多个系统之间一般是经过远程RPC调用进行通讯，也就是 A 系统调用 B 系统服务，B 系统调用 C 系统的服务。当尾部应用 C 发生故障而系统 B 没有服务降级时候可能会致使 B，甚至系统 A 瘫痪。

为了应对服务雪崩, 一种常见的作法是手动服务降级. 而Hystrix的出现,给咱们提供了另外一种选择.

　

雪崩效应造成缘由：

• 服务提供者不可用 

a）硬件故障：硬件损坏形成的服务器主机宕机， 网络硬件故障形成的服务提供者的不可访问

b）程序Bug

c）缓存击穿：通常发生在缓存应用重启，全部缓存被清空时，以及短期内大量缓存失效时，大量的缓存不命中，使请求直击后端，形成服务提供者超负荷运行，引发服务不可用

d）用户大量请求：在秒杀和大促开始前，若是准备不充分，用户发起大量请求也会形成服务提供者的不可用

• 重试加大流量

a）用户重试：在服务提供者不可用后， 用户因为忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单

b）代码逻辑重试： 服务调用端的会存在大量服务异常后的重试逻辑

• 服务调用者不可用

a）同步等待形成的资源耗尽：当服务调用者使用 同步调用  时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 因而服务雪崩效应产生了。

服务雪崩的应对策略：

• 流量控制

a）网关限流：由于Nginx的高性能, 目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制, 由此而来的OpenResty也愈来愈热门

b）用户交互限流：具体措施有： 1. 采用加载动画,提升用户的忍耐等待时间. 2. 提交按钮添增强制等待时间机制.

c）关闭重试

• 改进缓存模式

a）缓存预加载

b）同步改成异步刷新

• 服务自动扩容

a）AWS的auto scaling

• 服务调用者降级服务

a）资源隔离：主要是对调用服务的线程池进行隔离

b）对依赖服务进行分类：根据具体业务，将依赖服务分为： 强依赖和若依赖。强依赖服务不可用会致使当前业务停止，而弱依赖服务不可用不会致使当前业务停止

c）不可用服务的调用快速失败：通常经过 超时机制, 熔断器 和熔断后的 降级方法 来实现

使用Hystrix预防服务雪崩

Netflix的 Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库，它拥有保护系统的能力.

Hystrix的设计原则包括：

• 资源隔离
• 熔断器（Circuit Breaker）
• 命令模式

资源隔离

• 线程隔离

货船为了防止漏水和火灾的扩散，将货仓分隔为多个，这种资源隔离减小风险的方式被称为Bulkheads(舱壁隔离模式)。Hystrix将一样的模式运用到了服务调用者上。

在一个高度服务化的系统中，咱们实现的一个业务逻辑一般会依赖多个服务，好比: 商品详情展现服务会依赖商品服务、 价格服务、商品评论服务。调用三个依赖服务会共享商品详情服务的线程池， 若是其中的商品评论服务不可用， 就会出现线程池里全部线程都因等待响应而被阻塞，从而形成服务雪崩。 如图所示：

 

Hystrix经过将每一个依赖服务分配独立的线程池进行资源隔离，用户的请求将再也不直接访问服务，而是经过线程池中的空闲线程来访问服务，若是线程池已满，则会进行降级处理，用户的请求不会被阻塞，至少能够看到一个执行结果（例如返回友好的提示信息），而不是无休止的等待或者看到系统崩溃。以下图所示, 当商品评论服务不可用时， 即便商品服务独立分配的20个线程所有处于同步等待状态，也不会影响其余依赖服务的调用.

• 信号隔离

信号隔离也能够用于限制并发访问，防止阻塞扩散，与线程隔离最大不一样在于执行依赖代码的线程依然是请求线程（该线程须要经过信号申请，若是客户端是可信的且能够快速返回，可使用信号隔离替换线程隔离，下降开销。信号量的大小能够动态调整，线程池大小不能够。

熔断器模式

熔断器是位于线程池以前的组件。用户请求某一服务以后，Hystrix会先通过熔断器，此时若是熔断器的状态是打开，这时将直接进行降级处理，不会继续将请求发到线程池。熔断器至关于在线程池以前的一层屏障。每一个熔断器默认维护10个bucket ，每秒建立一个bucket ，每一个blucket记录成功,失败,超时,拒绝的次数。当有新的bucket被建立时，最旧的bucket会被抛弃。

熔断器模式定义了熔断器开关相互转换的逻辑：

三种状态：

• open：打开熔断，也就是服务调用方执行本地降级策略，不进行远程调用。
• closed：关闭了熔断，这时候服务调用方直接发起远程调用。
• half-open：一个中间状态，容许定量的服务请求直接发起远程调用。

 

服务的健康情况 = 请求失败数 / 请求总数. 
熔断器开关由关闭到打开的状态转换是经过当前服务健康情况和设定阈值比较决定的。

熔断器的开关能保证服务调用者在调用异常服务时，快速返回结果，避免大量的同步等待，而且熔断器能在一段时间后继续侦测请求执行结果，提供恢复服务调用的可能。

Hystrix提供的熔断器具备自我反馈，自我恢复的功能，Hystrix会根据调用接口的状况，让熔断器在closed、open、half-open三种状态之间自动切换：

• closed->open：正常状况下熔断器为closed状态，若是当前健康情况高于设定阈值，保持closed。若是当前健康情况低于设定阈值，则切换为open。

• open->half-open：当服务接口对应的熔断器为open状态，全部服务调用方调用该服务方法时所有执行本地降级方法。Hystrix提供了一种测试策略，即设置了一个时间窗口（通常设置成平均故障处理时间，也就是MTTR），从熔断器变为open状态开始的一个时间窗口内，调用该服务接口时都委托服务降级方法进行执行。若是时间超过了时间窗口，则把熔断状态从open->half-open

• half-open->closed：当熔断器为half-open状态，容许定量的服务请求。 若所有（或必定比例）的请求调用成功， 熔断器恢复到closed，不然，熔断器状态为open， 接下来的请求被禁止经过，从新记录时间窗口开始时间。

命令模式

Hystrix使用命令模式(继承HystrixCommand类)来包裹具体的服务调用逻辑(run方法)，并在命令模式中添加了服务调用失败后的降级逻辑(getFallback).
同时咱们在Command的构造方法中能够定义当前服务线程池和熔断器的相关参数， 以下代码所示:

public class Service1HystrixCommand extends HystrixCommand<Response> {
  private Service1 service;
  private Request request;

  public Service1HystrixCommand(Service1 service, Request request){
    supper(
      Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ServiceGroup"))
            .andCommandKey(HystrixCommandKey.Factory.asKey("servcie1query"))
            .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("service1ThreadPool"))
            .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
            .withCoreSize(20))//服务线程池数量
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
            .withCircuitBreakerErrorThresholdPercentage(60)//熔断器关闭到打开阈值
            .withCircuitBreakerSleepWindowInMilliseconds(3000)//熔断器打开到关闭的时间窗长度
      ))
      this.service = service;
      this.request = request;
    );
  }

  @Override
  protected Response run(){
    return service1.call(request);
  }

  @Override
  protected Response getFallback(){
    return Response.dummy();
  }
}

 在使用了Command模式构建了服务对象以后, 服务便拥有了熔断器和线程池的功能

 

Hystrix的内部处理逻辑

1. 构建Hystrix的Command对象，调用执行方法.

2. Hystrix检查当前服务的熔断器开关是否开启，若开启，则执行降级服务getFallback方法.

3. 若熔断器开关关闭，则Hystrix检查当前服务的线程池是否能接收新的请求，若超过线程池已满，则执行降级服务getFallback方法.

4. 若线程池接受请求，则Hystrix开始执行服务调用具体逻辑run方法.

5. 若服务执行失败，则执行降级服务getFallback方法，并将执行结果上报Metrics更新服务健康情况.（run()方法抛出非HystrixBadRequestException异常）

6. 若服务执行超时，则执行降级服务getFallback方法，并将执行结果上报Metrics更新服务健康情况.

7. 若服务执行成功，返回正常结果.

8. 若服务降级方法getFallback执行成功，则返回降级结果.

9. 若服务降级方法getFallback执行失败，则抛出异常.

执行方式

• 同步执行：即一旦开始执行该命令，当前线程就得阻塞着直到该命令返回结果，而后才能继续执行下面的逻辑
• 异步执行：命令开始执行会返回一个Future<T>的对象，不阻塞后面的逻辑，开发者本身根据须要去获取结果。
• 响应式执行：命令开始执行会返回一个Observable<T> 对象，开发者能够给给Obeservable对象注册上Observer或者Action1对象，响应式地处理命令执行过程当中的不一样阶段。当调用HystrixCommand的observe()方法，或使用Observable的工厂方法（just(),from()）即为响应式执行，这个功能的实现是基于Netflix的另外一个开源项目RxJava（https://github.com/Netflix/RxJava）来的，更细节的用法能够参考：https://github.com/Netflix/Hystrix/wiki/How-To-Use#wiki-Reactive-Execution。

 

 整理自：https://segmentfault.com/a/119000000598889五、https://blog.csdn.net/smillest/article/details/80660565