SpringCloud總結：Hystrix

Spring Cloud Hystrix也是spring團隊對netflix的Hystrix的封裝，主要提供了服務熔斷和降級，同時還兼顧了限流的功能.

Hystrix的最核心功能是服務熔斷，那麼爲什麼需要服務熔斷呢？

在微服務架構下，往往一個前端的請求對應了後端的多個服務，而且有時服務的調用鏈會很深（這也是微服務架構單來的一個副作用），服務與服務之間的依賴錯綜複雜，如果某一個服務不可用，可能會導致所有的服務癱瘓，造成服務的雪崩，而Hystrix可以將出現問題的服務從調用鏈中剔除，但是剔除以後，用戶的請求怎麼辦呢？就需要服務降級來處理，不能說直接把有問題的服務剔除了保證了服務不會出現雪崩，但是給用戶拋了一個異常回去，所以Hystrix還提供了兩種服務降級策略：

fallback method
fallback factory

下面我們來看一下Hystrix的總體的執行邏輯

首先明確一下Hystrix的隔離策略，Hystrix提供了兩種隔離策略，一種是線程隔離，一種是信號量隔離，線程隔離策略簡單理解，就是將用戶請求線程和服務調用線程分離，採用線程池+Future的方式，而信號量隔離實際上是用用戶請求線程來進行服務調用，信號量個人理解就是一個限流工具，它規定了同一時刻能夠通過的請求數量，一般都是使用線程隔離策略，原因在於，這種策略可以利用多線程加快處理速度，另外還能夠進行更加精細的控制，例如配置服務調用的超時時間等，可以通過如下的參數來修改隔離策略

hystrix.command.default.execution.isolation.strategy=thread
hystrix.command.default.execution.isolation.strategy=semaphore

對於這兩種策略，根據他們的特點可以總結一下他們適用的場景，對於線程隔離，由於採用多線程技術，所以執行效率會比較高，同時利用線程池的特點支持超時機制，一般在高併發場景下都會適用線程隔離策略，但也會造成一定的線程上下文切換的開銷

信號量隔離的最大特點的一個用戶線程懟到底，所以不支持超時機制，比較適合併發量不大的並且服務提供者能夠快速返回的場景。

下面羅列一下常見的配置項

#配置隔離策略
hystrix.command.default.execution.isolation.strategy=thread/semaphore
#信號量隔離級別下的信號量個數
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=10
#線程隔離級別下開啓調用超時功能
hystrix.command.default.execution.timeout.enabled=true/false
#指定服務調用線程執行的超時時間
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=
#是否開啓中斷，也就是當服務調用線程執行超時後，是否還讓它繼續執行，true=中斷其執行
hystrix.command.default.execution.isolation.thread.interruptOnTimeout=true/false
#當服務調用線程被主動取消時，是否中斷其執行
hystrix.command.default.execution.isolation.thread.interruptOnCancel=true/false

#是否開啓熔斷器
hystrix.command.default.circuitBreaker.enabled=true/false
#當滑動窗口內的請求失敗率達到指定的閾值時開啓熔斷器
hystrix.command.default.circuitBreaker.errorThresholdPercentage=
#當滑動窗口內的請求數量達到閾值時，開啓熔斷器
hystrix.command.default.circuitBreaker.requestVolumeThreshold=n
#當熔斷器開啓後，在指定的時間後會嘗試檢查相關的指標數據，如果符合配置，則關閉熔斷器
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=

另外，關於線程池的配置我們是在@HystrixCommand註解中配置的，來看一個簡單的例子

@HystrixCommand(fallbackMethod = "error", commandProperties = {
            //線程隔離模式 or 信號量隔離模式
            @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
            //如果請求超過5秒沒有返回，則進入熔斷降級
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "5000"),
            //接口調用失敗次數如果超過10次，則進入熔斷降級
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10")
    },
        threadPoolProperties = {
            @HystrixProperty(name="coreSize", value = "10"),
                @HystrixProperty(name = "maxQueueSize", value = "10"),
                @HystrixProperty(name = "keepAliveTimeMinutes", value = "1000"),
                @HystrixProperty(name = "queueSizeRejectionThreshold", value = "10")
        }
    )

關於Hystrix源碼，由於底層大量使用了響應式編程，跟蹤起來非常麻煩，本人也沒有捋的很清楚，這裏簡單看一下它的基本實現原理。

按照spring boot的脾氣，想找到hystrix的初始化的邏輯，就應該看看spring.factories

從名字上看，可以看到有兩個可能有關的類，但是本人在HystrixAutoConfiguration中並沒有找到什麼有用的信息，卻在HystrixCircuitBreakerConfiguration這個類中找到了一點蛛絲馬跡，從名字上看，這個類的熔斷器的配置，點進去可以看到一個關於Aop的Aspect切面

是不是感覺很熟悉了，一句話解釋：對@HystrixCommand註解進行攔截，利用Spring Aop返回給IoC容器代理對象，對於具體的邏輯，我嘗試用語言來描述一下（對各種東拼西湊的信息的理解），再深入進去，Hystrix使用了Command設計模式和RxJava的響應式編程，非常難跟蹤，目前爲止還沒搞明白，所以只能到這裏了。