【SpringCloud】Hystrix服务隔离（十二）

服务隔离介绍

　　当大多数人在使用Tomcat时，多个HTTP服务会共享一个线程池，假设其中一个HTTP服务访问的数据库响应非常慢，这将造成服务响应时间延迟增加，大多数线程阻塞等待数据响应返回，导致整个Tomcat线程池都被该服务占用，甚至拖垮整个Tomcat。因此，如果我们能把不同HTTP服务隔离到不同的线程池，则某个HTTP服务的线程池满了也不会对其他服务造成灾难性故障。这就需要线程隔离或者信号量隔离来实现了。

　　使用线程隔离或信号隔离的目的是为不同的服务分配一定的资源，当自己的资源用完，直接返回失败而不是占用别人的资源。

　　Hystrix实现服务隔离两种方案

　　Hystrix的资源隔离策略有两种，分别为：线程池和信号量。

线程池方式

　　优点：

　　1、 使用线程池隔离可以完全隔离第三方应用，请求线程可以快速放回。

　　2、 请求线程可以继续接受新的请求，如果出现问题线程池隔离是独立的不会影响其他应用。

　　3、 当失败的应用再次变得可用时，线程池将清理并可立即恢复，而不需要一个长时间的恢复。

　　4、 独立的线程池提高了并发性

　　缺点：

　　线程池隔离的主要缺点是它们增加计算开销（CPU）。每个命令的执行涉及到排队、调度和上 下文切换都是在一个单独的线程上运行的。

　　线程池方式案例

　　1、使用上一章项目工程，在服务端项目的业务类Service中编写如下方法：

// 服务限流
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_Thread",
        // 属性设置参考：HystrixCommandProperties
        commandProperties = {
                // 隔离策略，有THREAD和SEMAPHORE
                @HystrixProperty(name="execution.isolation.strategy", value="THREAD")
        },
        threadPoolProperties = {
                // 线程池核心线程数
                @HystrixProperty(name = "coreSize", value = "3"),
                // 队列最大长度
                @HystrixProperty(name = "maxQueueSize", value = "5"),
                // 排队线程数量阈值，默认为5，达到时拒绝，如果配置了该选项，队列的大小是该队列
                @HystrixProperty(name = "queueSizeRejectionThreshold", value = "7")
        })
public String paymentCircuitBreakerThread(@PathVariable("id") Integer id){
    int second = 500;
    try {
        // 休眠500毫秒
        TimeUnit.MILLISECONDS.sleep(second);
    } catch (InterruptedException e) {
//            e.printStackTrace();
    }
    // 异常
//        int n = 10/0;
    String result = "线程池：" + Thread.currentThread().getName()
            + "，paymentCircuitBreakerThreadPool，ID == " + id
            + "，耗时" + second + "毫秒";
    return result;
}

public String paymentCircuitBreaker_Thread(@PathVariable("id") Integer id){
    return " paymentCircuitBreaker_Thread 服务限流，ID == " + id;
}

　　2、在controller中调用该方法

// 线程
@GetMapping(value = "/payment/hystrix/thread/{id}")
public String paymentCircuitBreakerThreadPool(@PathVariable("id") Integer id) {
    String result = paymentService.paymentCircuitBreakerThread(id);
    log.info("result===" + result);
    return result;
}

　　3、重启项目，使用JMeter进行并发测试，测试url地址：http://localhost:8008/payment/hystrix/thread/1

　　　　测试发现，有一部分请求调用了fallback方法，一部分正常响应

　　　　

信号量方式　　

　　使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数 器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。

　　与线程池隔离最大不同在于执行依赖代码的线程依然是请求线程

　　提示：信号量的大小可以动态调整, 线程池大小不可以

　　信号量方式案例

　　1、使用上一章项目工程，在服务端项目的业务类Service中编写如下方法：

// 服务限流
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_Semaphore",
        // 属性设置参考：HystrixCommandProperties
        commandProperties = {
                // 隔离策略，有THREAD和SEMAPHORE
                // THREAD - 它在单独的线程上执行，并发请求受线程池中的线程数量的限制（默认）
                // SEMAPHORE - 它在调用线程上执行，并发请求受到信号量计数的限制
                @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"),
                // 设置在使用时允许到HystrixCommand.run（）方法的最大请求数。默认值：10 ，SEMAPHORE模式有效
                @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="1")

        })
public String paymentCircuitBreakerSemaphore(@PathVariable("id") Integer id){
    int second = 500;
    try {
        // 休眠500毫秒
        TimeUnit.MILLISECONDS.sleep(second);
    } catch (InterruptedException e) {
//            e.printStackTrace();
    }
    // 异常
//        int n = 10/0;
    String result = "线程池：" + Thread.currentThread().getName()
            + "，paymentCircuitBreaker_Semaphore，ID == " + id
            + "，耗时" + second + "毫秒";
    return result;
}

public String paymentCircuitBreaker_Semaphore(@PathVariable("id") Integer id){
    return " paymentCircuitBreaker_Semaphore 服务限流，ID == " + id;
}

　　2、在controller中调用该方法

// 信号量
@GetMapping(value = "/payment/hystrix/semaphore/{id}")
public String paymentCircuitBreakerLimit(@PathVariable("id") Integer id) {
    String result = paymentService.paymentCircuitBreakerSemaphore(id);
    log.info("result===" + result);
    return result;
}

　　3、重启项目，使用JMeter进行并发测试，测试url地址：http://localhost:8008/payment/hystrix/semaphore/1

　　　　测试发现，有一部分请求调用了fallback方法，一部分正常响应