服务容错保护Hystrix - Spring Cloud系列(三)

深藏阁楼爱情的钟 2022-03-21 07:30 291阅读 0赞

本文章基于spring-boot-starter-parent 2.0.6RELEASE，spring-cloud-dependencies Finchley.SR2。

### Hystrix是什么 ###

Hystrix是Netflix公司开源的一个用于处理分布式系统延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。Spring Cloud Hystrix基于开源框架Hystrix实现，实现了断路器、线程隔离等一系列服务保护功能，

### 容错限流原理 ###

**基本的容错模式**

*  **超时：** 主动超时
 *  **限流：** 限制最大并发数
 *  **熔断：** 错误数达到阈值时，类似保险丝熔断
 *  **隔离：** 隔离不同的依赖调用
 *  **降级：** 服务降级

**断路器模式**

断路器模式源于Martin Fower的Circuit Breaker一文。断路器本身是一种开关装置，用于在电路上保护线路过载。在分布式架构中，断路器模式的作用也是类似，当某个服务单元发生故障后，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

### Hystrix使用 ###

#### 服务降级 ####

> 服务降级是指当我们的某个微服务响应时间过长或是不可用了，不能让其他调用者卡在那里或者收到错误信息，因此要准备一个对应的策略，当发生这种问题时我们直接调用某个不依赖网络请求的方法直接返回请求结果，不让依赖方一直卡在那。

我们以上一篇文章中使用的例子为基础，对实例进行改造：

*  User：服务调用者
 *  Order：服务提供者
 *  Eureka：服务注册中心

**第一步： User工程中引入Spring Cloud Hystrix**

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

**第二步：User工程的启动类AppUserApplication添加`@EnableHystrix`注解**

@SpringBootApplication
    @EnableEurekaClient
    @EnableHystrix
    public class AppUserApplication {
        public static void main(String[] args) {
            SpringApplication.run(AppUserApplication.class);
        }
    }

**第三步：改造User工程的UserController**  
**UserController.java**

@RestController
    public class UserController {
    	private static final String ORDER_URL = "http://ORDER-MICRO";
    	
        @Autowired
        RestTemplate restTemplate;
    
    	@RequestMapping("/getOrder.do")
        @HystrixCommand(fallbackMethod = "getOrderFullBack")
        public R getOrder() {
            return R.success("操作成功", restTemplate.getForObject(ORDER_URL + "/getOrder.do", Object.class));
        }
    	
    	// 降级方法
        public R getOrderFullBack() {
            return R.error("系统正在维护中，请稍后重试");
        }
    }

可以看到UserController里getOrder()上新增了一个注解`HystrixCommand`，并配置了降级方法`getOrderFullBack`。

分别启动Eureka、User，然后访问http://localhost:5000/getOrder.do，可以看到在order服务没有启动的时候，执行了服务降级方法`getOrderFullBack`。  
![getOrderFullBack][]  
如果注释掉getOrder方法上的`@HystrixCommand(fallbackMethod = "getOrderFullBack")`，然后重启User看到的是如下页面。说明在引入Hystrix后服务方法被降级了。  
![error][]

#### 服务超时 ####

修改Order工程中的OrderController，增加超时处理，并启动Order。

@RestController
    public class OrderController {
    
        @RequestMapping("/getOrder.do")
        public Map<String, Object> getOrder() throws InterruptedException {
            Map<String,Object> map = new HashMap();
            map.put("key","order");
            // 让处理线程随机等待几秒
            int sleepTime = new Random().nextInt(3000);
            Thread.sleep(sleepTime);
            return map;
        }
    }

再次访问`http://localhost:5000/getOrder.do`，多刷新几次可以发现服务请求偶尔成功、偶尔失败，失败的请求会调用服务降级方法`getOrderFullback()`。  
![success][]  
![error][error 1]  
为什么会出现这种情况呢？由于Hystrix的默认超时时间是1000毫秒，所以这里采用的0-3000的随机数可以让处理过程有一定概率发生超时来触发断路器，即服务消费者因调用的服务超时从而触发熔断请求。

#### 服务熔断 ####

> 熔断就好比我们生活中的跳闸一样，比如说电路出现故障了，为了防止出现事故，断路器会直接切断你的电源以防意外继续发生。把这个概念放在程序上也是如此，当一个微服务调用多次出现问题（Hystrix中默认是10内20次），hystrix就会采用熔断机制（默认熔断5秒），熔断期间不在继续调用你的方法，5秒后会先试探性关闭熔断机制，但是如果这时候再失败一次（之前是20次）那么又会进行熔断，这样就一定程度上避免了服务雪崩的问题。

**第一步：修改Order工程中的OrderController，使其返回异常信息**

@RestController
    public class OrderController {
    
        @RequestMapping("/getOrder.do")
        public Map<String, Object> getOrder() throws Exception {
            Map<String,Object> map = new HashMap();
            map.put("key","order");
            throw new Exception();
        }

**第二步：修改User工程的配置文件application.yml，增加熔断配置**

hystrix:
      command:
        default:
          circuitBreaker:
            requestVolumeThreshold: 5 //断路器生效必须满足的流量阀值(默认值是10S内20次）
            sleepWindowInMilliseconds : 5000   // 熔断后重置断路器的时间间隔（默认5S）

**第三步：修改User工程中的UserController，增加一条打印语句`System.out.println("调用方法");`，用来测试是否请求了服务。**

@RequestMapping("/getOrder.do")
        @HystrixCommand(fallbackMethod = "getOrderFullBack")
        public R getOrder() {
        	System.out.println("调用方法");
            return R.success("操作成功", userService.getOrder());
        }

重启User和Order服务，访问`http://localhost:5000/getOrder.do`，在10秒内访问5次后，会发现`System.out.println("调用方法");`这条语句不在打印，说明Hystrix已触发熔断请求。  
![服务熔断][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6eWdjcw_size_16_color_FFFFFF_t_70]  
5S中后再访问一次请求，发现又有打印了，但是之后打印又消失了，说明在初次熔断后的后续尝试连接中，服务依然访问失败，所以服务继续熔断了。  
![服务熔断2][2]

#### 服务限流 ####

> 限流，顾名思义就是限制某个微服务的使用量（可用线程）。Hystrix通过线程池的方式来管理你的微服务调用，默认是一个线程池（10大小）管理你的微服务，你可以给某个微服务开辟新的线程池。

**第一步：还原上面更改的Order服务变动，使其服务延迟2S返回结果。**

@RequestMapping("/getOrder.do")
        public Map<String, Object> getOrder() throws Exception {
            Map<String,Object> map = new HashMap();
            map.put("key","order");
            // 让处理线程等待2秒
            Thread.sleep(2000);
            return map;
        }

**第二步：修改User服务的配置文件，增加线程池配置**

hystrix:
      command:
        default:
          execution:
            isolation:
              thread:
                timeoutInMilliseconds: 5000 // 为了测试服务限流，设定命令执行超时时间为5S
                
      threadpool:
        default:
          coreSize: 2  // 并发执行的最大线程数, 默认是10
          maxQueueSize: 1 // 最大队列数为1

重启User和Order服务，访问`http://localhost:5000/getOrder.do`。因为设置了Order服务延迟2秒返回结果，假设这个方法调用时间是3s执行完， 那么在3s内如果有超过2+1（队列）个请求进来的话，剩下的请求则全部降级。将命令执行超时时间设为5s，是为了避免降级是因为超时引起的。*为了更清晰的说明结果，读者可自行在调用函数中添加时间记录。*

**上述线程池配置也可以直接在代码里添加**

@RequestMapping("/getOrder.do")
    	@HystrixCommand(fallbackMethod = "getFeignPowerFullBack",
                threadPoolKey = "order",
                threadPoolProperties = {@HystrixProperty(name = "coreSize", value = "2"),
                        @HystrixProperty(name = "maxQueueSize", value = "1")})
        public R getOrder() {
            System.out.println("访问getOrder请求");
            return R.success("操作成功", userService.getOrder());
        }

`threadPoolKey`是线程池唯一标识， Hystrix会拿你这个标识去计数，看线程占用是否超过了，超过了就会直接降级该次调用，会覆盖application.yml中的默认设置（default）。

### Hystrix主要配置项 ###

**Execution相关的属性配置（前缀hystrix.command.default）**

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>execution.isolation.strategy</td> 
   <td>线程“THREAD”或信号量“SEMAPHORE”隔离(Default: THREAD)</td> 
  </tr> 
  <tr> 
   <td>execution.isolation.thread.timeoutInMilliseconds</td> 
   <td>run()方法执行超时时间(Default: 1000)</td> 
  </tr> 
  <tr> 
   <td>execution.isolation.semaphore.maxConcurrentRequests</td> 
   <td>信号量隔离最大并发数(Default:10)，该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效</td> 
  </tr> 
  <tr> 
   <td>fallback.isolation.semaphore.maxConcurrentRequests</td> 
   <td>如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10</td> 
  </tr> 
 </tbody> 
</table>

**Circuit Breaker相关的属性配置（前缀hystrix.command.default）**

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>circuitBreaker.requestVolumeThreshold</td> 
   <td>一个rolling window内最小的 请 求数。如果设为20，那么当一个rolling window的时间内(比如说1个rolling window是10秒)收到19个请 求， 即使19个请求都失败，也不会触发circuit break。默认20</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.errorThresholdPercentage</td> 
   <td>熔断的错误百分比阀值(Default:50)</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.sleepWindowInMilliseconds</td> 
   <td>熔断后重置断路器的时间间隔(Default:5000)</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.forceOpen</td> 
   <td>设true表示强制熔断器进入打开状态(Default: false)</td> 
  </tr> 
  <tr> 
   <td>circuitBreaker.forceClosed</td> 
   <td>设true表示强制熔断器进入关闭状态(Default: false)</td> 
  </tr> 
 </tbody> 
</table>

**Metrics相关的属性配置（前缀hystrix.command.default）**

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>metrics.rollingStats.numBuckets</td> 
   <td>设置一个rolling window被划分的数 量，若numBuckets=10，rolling window=10000，那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10</td> 
  </tr> 
 </tbody> 
</table>

**ThreadPool相关的属性配置（前缀hystrix.threadpool.default）**  
线程数默认值10适用于大部分情况，如果需要设置得更大，可参考基本公式：每秒最大支撑的请求数 (99%平均响应时间 + 缓存值) 。比如:每秒能处理1000个请求，99%的请求响应时间是60ms，那么公式是: 1000 \*(0.06+0.012)  
基本得原则时保持线程池尽可能小，主要是为了释放压力，防止资源被阻塞。 当一切都是正常的时候，线程池一般仅会有1到2个线程激活来提供服务

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>coreSize</td> 
   <td>使用线程池时的最大并发请求(Default: 10)</td> 
  </tr> 
  <tr> 
   <td>maxQueueSize</td> 
   <td>BlockingQueue的最大队列数，当设为-1，会使用SynchronousQueue，否则会使用使用LinkedBlcokingQueue。该设置只会在初始化时有效，之后不能修改 threadpool的queue size，除非reinitialising thread executor。默认-1</td> 
  </tr> 
  <tr> 
   <td>queueSizeRejectionThreshold</td> 
   <td>队列大小阀值，超过则拒绝(Default:5)</td> 
  </tr> 
  <tr> 
   <td>metrics.rollingStats.timeInMilliseconds</td> 
   <td>线程池统计指标的时间， 默 认10000</td> 
  </tr> 
  <tr> 
   <td>metrics.rollingStats.numBuckets</td> 
   <td>将rolling window划分为n个 buckets，默认10</td> 
  </tr> 
 </tbody> 
</table>

Spring Cloud除了整合了Hystrix，还整合了Hystrix的仪表盘组件[Hystrix Dashboard][]，想了解的可以点击连接。

--------------------

\------------本文结束感谢您的阅读------------

[getOrderFullBack]: /images/20220321/c48cf1d1fbe9494cbdbf7430cf2d1fce.png
[error]: /images/20220321/1891cfad659f4139a38a110128e89f56.png
[success]: /images/20220321/ffdc783bb7c243659bb033433a6d50d4.png
[error 1]: /images/20220321/9041c7adc8c3477a82171cb4f9a364a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h6eWdjcw_size_16_color_FFFFFF_t_70]: /images/20220321/aa171d1d06d44c8fa4d355adcd3ec90c.png
[2]: /images/20220321/435a6c9c374a4e50ad9f9116b09d70f8.png
[Hystrix Dashboard]: https://blog.csdn.net/hzygcs/article/details/87370201