Chapter Five《SpringCloud微服务实战》

作者: LUOERD | 来源:发表于2019-01-03 16:39 被阅读0次

服务容错保护： Spring Cloud Hystrix

1.引出断路器：

在微服务架构中，我们将系统拆分为很多个服务，各个服务之间通过注册与订阅的方式相互依赖，由于各个服务都是在各自的进程中运行，就有可能由于网络原因或者服务自身的问题导致调用故障或延迟，随着服务的积压，可能会导致服务崩溃。为了解决这一系列的问题，断路器等一系列服务保护机制出现了。

断路器本身是一种开关保护机制，用于在电路上保护线路过载，当线路中有电器发生短路时，断路器能够及时切断故障电路，防止发生过载、发热甚至起火等严重后果。

在分布式架构中，断路器模式的作用也是类似的。

针对上述问题，Spring Cloud Hystrix 实现了断路器、线路隔离等一系列服务保护功能。它也是基于 Netflix 的开源框架 Hystrix 实现的，该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix 具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。

2.快速入门

在开始实现断路器之前，先用之前实现的一些内容作为基础，构建一个如下图所示的服务调用关系。

image.png

2.1Hystrix设计原则

1.防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑
2.用快速失败代替排队 (每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复
3.提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求
4.将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用 隔离技术 来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待

Hystrix特性

1.请求熔断：当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).

这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

2.服务降级：Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。

3.依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放

后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，

我的B服务依然可以用。

4.请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。

5.请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。

Hystrixl流程图如下：

image.png

Hystrix流程说明:

   1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.
　　2:执行execute()/queue做同步或异步调用.
　　4:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤5.
　　5:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤6.
　　6:调用HystrixCommand的run方法.运行依赖逻辑
　　6a:依赖逻辑调用超时,进入步骤8.
　　7:判断逻辑是否调用成功
　　7a:返回成功调用结果
　　7b:调用出错，进入步骤8.
　　8:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.
　　9:getFallback()降级逻辑.以下四种情况将触发getFallback调用：
　　　　(1):run()方法抛出非HystrixBadRequestException异常。
　　　　(2):run()方法调用超时
　　　　(3):熔断器开启拦截调用
　　　　(4):线程池/队列/信号量是否跑满
　　9a:没有实现getFallback的Command将直接抛出异常
　　9b:fallback降级逻辑调用成功直接返回
　　9c:降级逻辑调用失败抛出异常
　　10:返回执行成功结果

对之前的Ribbon进行Hystrix集成。如果对一个请求进行熔断，必然不能让客户直接去调用那个请求，你必然要要对别人的请求进行包装一层和拦截，才能做点手脚，比如进行熔断，所以说要在Ribbon上动手脚。因为它是请求发起的地方。
我们刚开始请求一个服务，为了负载均衡进行了拦截一次，现在我们要进行熔断，所以必须跟Ribbon集成一次，再进行请求拦截来熔断。

2.2 引入Hystrix相关的依赖：

<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-hystrix</artifactId>
        <version>1.4.0.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
        <version>1.4.0.RELEASE</version>
    </dependency>

在启动类中加入@EnableCircuitBreaker注解，表示允许断路器。

import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.RandomRule;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

 @SpringBootApplication
 @EnableDiscoveryClient
  //允许断路器
  @EnableCircuitBreaker
  public class RibbonApplication {

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

  @Bean
  public IRule ribbonRule(){
      return new RandomRule();
  }

  @Bean
  @LoadBalanced
  public RestTemplate restTemplate(){
      return new RestTemplate();
  }
}

2.3 修改之前的 Ribbon ，新建一个service

 /**
   * 测试
   */
@Service
public class HelloService {

 @Autowired
  private RestTemplate restTemplate;
//请求熔断注解，当服务出现问题时候会执行fallbackMetho属性的名为helloFallBack的方法
  @HystrixCommand(fallbackMethod = "helloFallBack")
  public String helloService() throws ExecutionException, InterruptedException {
      return restTemplate.getForEntity("http://HELLO-SERVICE/hello",String.class).getBody();
  }
  public String helloFallBack(){
　　return "error";
  }
}

Hystrix给我们提供了HystrixCommand类，让我们去继承它，去实现灵活的熔断和服务降级。

import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandGroupKey;
import org.springframework.web.client.RestTemplate;

/**
  * 测试
  */
public class HelloServiceCommand extends HystrixCommand<String> {

  private RestTemplate restTemplate;

  protected HelloServiceCommand(String commandGroupKey,RestTemplate restTemplate) {
      super(HystrixCommandGroupKey.Factory.asKey(commandGroupKey));
      this.restTemplate = restTemplate;
  }

  @Override
  protected String run() throws Exception {
      System.out.println(Thread.currentThread().getName());
      return restTemplate.getForEntity("http://HELLO-SERVICE/hello",String.class).getBody();
  }

  @Override
  protected String getFallback() {
      return "error";
   }
 }

PS:非阻塞式IO有两个分别是：Future将来式，Callable回调式

1.Future将来式：就是说你用Future将来式去请求一个网络IO之类的任务，它会一多线程的形式去实现，主线程不必卡死在哪里等待，等什么时候需要结果就通过Future的get()方法去取，不用阻塞。

2.Callable回调式：预定义一个回调任务，Callable发出去的请求，主线程继续往下执行，等你请求返回结果执行完了，会自动调用你哪个回调任务。

其实HelloServiceCommand类几面不用变，只需要改变一下在Controller层的command的调用方式即可，command的叫用方式如下：

Future<String> queue = command.queue();
return queue.get();

然后重启Ribbon模块。

2.4Future的注解方式调用如下所示：

  /**
   * 测试
   */
 @Service
 public class HelloService {

@Autowired
private RestTemplate restTemplate;

@HystrixCommand(fallbackMethod = "helloFallBack")
public String helloService() throws ExecutionException, InterruptedException {

    Future<String> future = new AsyncResult<String>() {
        @Override
        public String invoke() {
            return restTemplate.getForEntity("http://HELLO-SERVICE/hello",String.class).getBody();
        }
    };
      return future.get();
 }
     public String helloFallBack(){
　　    return "error";
      }
}

2.5 使用Hystrix的仪表盘

通过访问http://localhost:8001/hystrix就可以得到如下界面：

image.png

总结：
雪崩效应的原因：

服务提供者不可用
a.硬件故障
b.程序Bug
c.用户大量请求：在秒杀和大促开始前,如果准备不充分,用户发起大量请求造成服务提供者的不可用

重试加大流量
a.用户重试：用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单
b.代码逻辑重试：服务调用端的会存在大量服务异常后的重试逻辑

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

雪崩效应的解决措施：

1) 流量控制
  a.网关限流
  因为Nginx的高性能, 目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制, 由此而来的OpenResty也越来越热门.
  b.用户交互限流
  具体措施:
    a21. 采用加载动画,提高用户的忍耐等待时间.
    a22. 提交按钮添加强制等待时间机制.
  c.关闭重试

2) 改进缓存模式
  a.缓存预加载
  b.同步改为异步刷新

3) 服务自动扩容
  a.AWS的auto scaling

4) 服务调用者降级服务
  a.资源隔离：主要是对调用服务的线程池进行隔离.
  b.对依赖服务进行分类
  依赖服务分为: 强依赖和若依赖. 强依赖服务不可用会导致当前业务中止,而弱依赖服务的不可用不会导致当前业务的中止.
  c.不可用服务的调用快速失败

  一般通过 超时机制,熔断器 和 熔断后的 降级方法 来实现

Less is more.

Chapter Five《SpringCloud微服务实战》

服务容错保护： Spring Cloud Hystrix

1.引出断路器：

2.快速入门

2.1Hystrix设计原则

Hystrix特性

2.2 引入Hystrix相关的依赖：

2.3 修改之前的 Ribbon ，新建一个service

2.4Future的注解方式调用如下所示：

2.5 使用Hystrix的仪表盘

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读