前言在微服務架構中，我們將系統拆分成了一個個的服務單元，各單元應用間通過服務註冊與發現的方式互相依賴。 由於每個單元都在不同的進程中運行，依賴通過遠程調用的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現調用故障或延遲， 而這些問題會直接導致調用方的對外服務也出現延遲，若此時調用方的請求不 ...
前言
在微服務架構中，我們將系統拆分成了一個個的服務單元，各單元應用間通過服務註冊與發現的方式互相依賴。
由於每個單元都在不同的進程中運行，依賴通過遠程調用的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現調用故障或延遲，
而這些問題會直接導致調用方的對外服務也出現延遲，若此時調用方的請求不斷增加，最後就會出現因等待出現故障的依賴方響應而形成任務積壓，線程資源無法釋放，最終導致自身服務的癱瘓，
進一步甚至出現故障的蔓延最終導致整個系統的癱瘓。如果這樣的架構存在如此嚴重的隱患，那麼相較傳統架構就更加的不穩定。
為瞭解決這樣的問題，因此產生了斷路器等一系列的服務保護機制。
為了使得故障隔離，Hystrix提供的解決方案我們需要關註一下幾個部分：
- 艙壁隔離（線程隔離）
- 超時控制
- 服務降級
- 熔斷機制
1.倉壁隔離
“艙壁模式”對於熟悉Docker的讀者一定不陌生，Docker通過“艙壁模式”實現進程的隔離，使得容器與容器之間不會互相影響。
而Hystrix則使用該模式實現線程池的隔離，它會為每一個Hystrix命令創建一個獨立的線程池，這樣就算某個在Hystrix命令包裝下的依賴服務出現延遲過高的情況，也只是對該依賴服務的調用產生影響，而不會拖慢其他的服務。
如何使用？
我們使用@HystrixCommand來將某個函數包裝成了Hystrix命令，Hystrix框架就會自動的為這個函數實現調用的隔離。
Spring Cloud構建微服務架構：服務容錯保護（Hystrix依賴隔離）
2.超時控制和服務降級
如果服務提供方延遲了自己設置的超時限制，而服務消費方觸發了服務請求超時異常，服務消費者就通過HystrixCommand註解中指定的降級邏輯進行執行，
因此該請求的結果返回了fallback。這樣的機制，對自身服務起到了基礎的保護，同時還為異常情況提供了自動的服務降級切換機制。
Spring Cloud構建微服務架構：服務容錯保護（Hystrix服務降級）
@Repository @DefaultProperties(groupKey="userDao", //命令執行超時時間，預設1000ms commandProperties={@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="5000")}, threadPoolProperties={@HystrixProperty(name="coreSize",value="10") ,@HystrixProperty(name="maxQueueSize",value="1000")}, threadPoolKey="userDao" ) public class UserDao{ public User getUserByTokenFb(String token){ return new User(); } /** * 調用鑒權服務 * @param token * @return */ @HystrixCommand(fallbackMethod="getUserByTokenFb") public User getUserByToken(String token) { String url = "http://" + userServiceName + "/user/get?token=" + token; ResponseEntity<RestResponse<User>> responseEntity = rest.get(url, new ParameterizedTypeReference<RestResponse<User>>() {}); RestResponse<User> response = responseEntity.getBody(); if (response == null || response.getCode() != 0) { return null; } return response.getResult(); } }
3.熔斷機制
“斷路器”本身是一種開關裝置，用於在電路上保護線路過載，當線路中有電器發生短路時，“斷路器”能夠及時的切斷故障電路，防止發生過載、發熱、甚至起火等嚴重後果。
在分散式架構中，斷路器模式的作用也是類似的，當某個服務單元發生故障（類似用電器發生短路）之後，通過斷路器的故障監控（類似熔斷保險絲），直接切斷原來的主邏輯調用。
那麼當斷路器打開之後會發生什麼呢？我們先來說說斷路器未打開之前，對於之前那個示例的情況就是每個請求都會在當hystrix超時之後返回fallback，每個請求時間延遲就是近似hystrix的超時時間，
如果設置為5秒，那麼每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發現請求總數超過20，並且錯誤百分比超過50%，這個時候熔斷器打開。
打開之後，再有請求調用的時候，將不會調用主邏輯，而是直接調用降級邏輯，這個時候就不會等待5秒之後才返回fallback。
通過斷路器，實現了自動地發現錯誤並將降級邏輯切換為主邏輯，減少響應延遲的效果。
附上一張終極原理圖：
Spring Cloud構建微服務架構：服務容錯保護（Hystrix斷路器）
註：一些配置
要使用hystrix需要在pom文件中添加下麵兩個依賴：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
<version>1.4.4.RELEASE</version>
</dependency>
服務消費者application.properties
#命令執行超時時間，預設1000ms hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000 hystrix.threadpool.default.coreSize=5 hystrix.threadpool.default.maxQueueSize=1 #錯誤比率閥值，如果錯誤率>=該值，circuit會被打開，並短路所有請求觸發fallback。預設50 hystrix.command.default.circuitBreaker.errorThresholdPercentage=10 #休眠時間窗 hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=100000 #必須要配置這個暴露監控埠，這樣才能hystrix dashboard查看監控信息 management.endpoints.web.exposure.include=*
這是做的全局預設配置，如果在某個服務級別上單獨配置,使用@DefaultProperties在類級別上做配置：
@DefaultProperties(groupKey="userDao", //命令執行超時時間，預設1000ms commandProperties={@HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value="5000")}, threadPoolProperties={@HystrixProperty(name="coreSize",value="10") ,@HystrixProperty(name="maxQueueSize",value="1000")}, threadPoolKey="userDao" )
另外後還需要加註解@HystrixCommand做方法級別的命令控制，預設使用類級別的參數。
另外這是一篇經典好文，對於理解熔斷器的機制非常有幫助！
防雪崩利器：熔斷器 Hystrix 的原理與使用
對於監控的狀態信息可以通過Hystrix提供的dashboard來直觀顯示，可安裝這篇文章進行操作
