【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方法，一部分正常響應