Hystrix使用方式

ゝ一世哀愁。 2023-06-03 04:58 29阅读 0赞

# 1.Hystrix是什么 #

Hystrix是一款开源容错插件，具有依赖隔离，系统容错降级等功能，还有请求合并等功能。

# 2、为什么要进行隔离 #

实际工作中，分布式、微服务遍地开花，一个服务经常要调用其他的服务，dubbo的RPC调用，http调用，在调用过程中，因为网络等原因，造成某个服务调用超时，如果没有熔断机制，此时的调用链路会一直阻塞在这里，在高并发的环境下，如果每个请求都卡在这个的话，服务器压力会很大。如果一个多级调用，一个服务的调用结果被其他服务调用了，这就形成了雪崩效应。这个时候hystrix出现了，在一定的异常接口调用出现的时候，能够自动发现这种异常，并快速进行服务降级。常见的降级方式包括超时处理、线程池隔离和信号量隔离。下面就简单的介绍下。

创建一个接口，模拟远程调用其他服务接口

@GetMapping("/getApple")
        public String getApple(){
           return appleService.getApple();
        }

接口代码很简单，就是远程获取一个苹果，下面看实现类，首先看第一种方式，即接口超时的处理，hystrix提供了超时降级熔断机制，即通过添加注解的方式，当这个注解配置在某个方法上面的时候，就会对这个方法生效，当然也可以直接写在接口上，超时配置代码如下，

方式1，超时降级

@Autowired
        private RestTemplate restTemplate;
    
    @HystrixCommand(
                commandKey = "getApple",
                commandProperties = {
                        @HystrixProperty(name="execution.timeout.enabled", value="true"),
                        @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds", value="3000"),
                },
                fallbackMethod = "getAppleFallbackMethodTimeout"
        )
        public String getApple() {
            String appleNo = restTemplate.getForObject("http://localhost:8087/getUserApple",String.class);
            return "下单成功，订单号是:" +appleNo;
        }

这里我们设置超时时间为3秒，在注解上有一个叫做fallbackMethod 的，这个里面对应的方法就是当达到超时时间时走的方法，如下，

//超时降级的方法
        public String getAppleFallbackMethodTimeout() throws Exception {
            System.err.println("-------超时降级策略执行------------");
            return "hysrtix timeout !";
        }

下面我们来测试一下，在另外一个工程中，我这里提供了一个非常简单的接口，用以测试调用，

@RestController
    public class UserInfoController {
    
        @GetMapping("/getUserApple")
        public String getUserApple(){
            return UUID.randomUUID().toString().substring(0,6);
        }
    
    }

启动两个demo工程，为了模拟效果，我们将被调用的接口设置休眠5秒

@GetMapping("/getUserApple")
        public String getUserApple() throws Exception{
            Thread.sleep(5000);
            return UUID.randomUUID().toString().substring(0,6);
        }

启动完毕，浏览器访问：http://localhost:8083/order/createOrder，从返回结果可以看到，超时降级策略执行了，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pbmdtZW5nYmFieQ_size_16_color_FFFFFF_t_70][]

方式2，线程池隔离  
所谓线程池隔离，就是每个过来的请求，系统会单独将这个请求的执行放在一个线程或线程池里，这个根据自己的需求进行配置，以后，相同的请求不管有多少打进来，都会在指定数量的线程池内进行，因此不会出现诸如线程资源耗尽的情况，这种隔离方式在某些场景下是非常有用的，下面来看具体的代码，

线程池隔离这里同样采用注解的方式，只是注解里面的相关配置发生了变化，这里我们仍以请求创建订单号为例，

//    限流策略：线程池方式
        @HystrixCommand(
                commandKey = "createOrder",
                commandProperties = {
                        @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD")
                },
                threadPoolKey = "createOrderThreadPool",
                threadPoolProperties = {
                        @HystrixProperty(name = "coreSize", value = "3"),
                        @HystrixProperty(name = "maxQueueSize", value = "5"),
                        @HystrixProperty(name = "queueSizeRejectionThreshold", value = "7")
                },
                fallbackMethod = "createOrderFallbackMethod4Thread"
        )
        public String createOrder() {
            String orderNo = restTemplate.getForObject("http://localhost:8087/getUserOrder", String.class);
            return "下单成功，订单号是:" + orderNo;
        }

提供一个熔断超时的方法，

//线程池方式降级
        public String createOrderFallbackMethod4Thread() throws Exception {
            System.err.println("-------超时线程池降级策略执行------------");
            return "hysrtix timeout !";
        }

这个线程池隔离的方式模拟起来稍显麻烦，我这里直接在接口里面通过线程池的方法发起100个请求进行模拟测试，代码如下，

@GetMapping("/createOrder")
        public String createOrder(){
            ExecutorService executorService = Executors.newCachedThreadPool();
            CountDownLatch countDownLatch = new CountDownLatch(requestTotal);
            Semaphore semaphore = new Semaphore(concurrentThreadNum);
            for (int i = 0; i< requestTotal; i++) {
                executorService.execute(()->{
                    try {
                        String result = orderService.createOrder();
                        System.out.println(result);
                        semaphore.release();
                    } catch (Exception e) {
                        System.out.println(e);
                        e.printStackTrace();
                    }
                    countDownLatch.countDown();
                });
            }
           // return orderService.createOrder();
            return "success";
        }

然后启动工程，浏览器访问：http://localhost:8083/order/createOrder，通过控制台打印结果，可以看到，由于并发请求远超过我们在注解上配置的参数，因此走了线程池隔离的熔断方法，但由于这里并不会影响主线程，因此最终接口还是打印了主线程的结果，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pbmdtZW5nYmFieQ_size_16_color_FFFFFF_t_70 1][]

方式2，信号量隔离

信号量的资源隔离只是起到一个开关的作用，比如，服务 A 的信号量大小为 10，那么就是说它同时只允许有 10 个 tomcat 线程来访问服务 A，其它的请求都会被拒绝，从而达到资源隔离和限流保护的作用，下面直接上代码，基本配置和上述两种相似，就是注解不同，

@HystrixCommand(
                    commandKey="createOrder",
                    commandProperties= {
                            @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"),
                            @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="6")
                    },
                    fallbackMethod = "createOrderFallbackMethod4semaphore"
                )
        public String createOrder() {
            String orderNo = restTemplate.getForObject("http://localhost:8087/getUserOrder", String.class);
            return "下单成功，订单号是:" + orderNo;
        }

超时熔断方法

// 信号量方式降级
        public String createOrderFallbackMethod4semaphore() throws Exception {
            System.err.println("-------信号量降级策略执行------------");
            return "hysrtix timeout !";
        }

这里通过字面意义理解，我们仍然可以用上述的接口进行模拟，启动工程，浏览器访问：http://localhost:8083/order/createOrder，通过控制台可以看到，由于我们在注解的配置里面设置的是6个，即允许同时通过的是6个请求，而我们请求的时候使用的是100个，达到了阈值，触发了熔断机制。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pbmdtZW5nYmFieQ_size_16_color_FFFFFF_t_70 2][]

参考：[https://blog.csdn.net/zhangcongyi420/article/details/101723584][https_blog.csdn.net_zhangcongyi420_article_details_101723584]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pbmdtZW5nYmFieQ_size_16_color_FFFFFF_t_70]: /images/20230601/b3d29535b6af48e8b41c726cff2fb4f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pbmdtZW5nYmFieQ_size_16_color_FFFFFF_t_70 1]: /images/20230601/4310d3412ebe4b16ace82657509864e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pbmdtZW5nYmFieQ_size_16_color_FFFFFF_t_70 2]: /images/20230601/f89770cd93aa44f0bb92955726ec0ff0.png
[https_blog.csdn.net_zhangcongyi420_article_details_101723584]: https://blog.csdn.net/zhangcongyi420/article/details/101723584