[TOC] # 簡介 在client端配置 ~~~ <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> ~~~ Hystrix為每個依賴服務調用分配一個小的線程池，如果線程池已滿調用將被立即拒絕，默認不采用排隊，加速失敗 判定時間。 用戶的請求將不再直接訪問服務，而是通過線程池中的空閑線程來訪問服務，如果線程池已滿，或者請求超時， 則會進行降級處理，什么是服務降級？ > 服務降級：優先保證核心服務，而非核心服務不可用或弱可用。 用戶的請求故障時，不會被阻塞，更不會無休止的等待或者看到系統崩潰，至少可以看到一個執行結果（例如返回 友好的提示信息）。 服務降級雖然會導致請求失敗，但是不會導致阻塞，而且最多會影響這個依賴服務對應的線程池中的資源，對其它 服務沒有響應。 觸發Hystix服務降級的情況： * 線程池已滿 * 請求超時 # 模式 **資源隔離** ? ? ? ?貨船為了進行防止漏水和火災的擴散,會將貨倉分隔為多個，這種資源隔離減少風險的方式被稱為：Bulkheads(艙壁隔離模式)。 ? ? ? ?Hystrix將同樣的模式運用到了服務調用者上，在一個高度服務化的系統中，一個業務邏輯通常會依賴多個服務，比如：商品詳情展示服務會依賴商品服務，價格服務，商品評論服務。調用三個依賴服務會共享商品詳情服務的線程池。如果其中的商品評論服務不可用，就會出現線程池里所有線程都因等待響應而被阻塞，從而造成服務雪崩。Hystrix通過將每個依賴服務分配獨立的線程池進行資源隔離，從而避免服務雪崩。 **熔斷器模式** 熔斷器模式定義了熔斷器開關相互轉換的邏輯。 ? ? ? ?服務的健康狀況 = 請求失敗數 / 請求總數。熔斷器開關由關閉到打開的狀態轉換是通過當前服務健康狀況和設定閾值比較決定的。 ? ? ? ?當熔斷器開關關閉時，請求被允許通過熔斷器。 如果當前健康狀況高于設定閾值，開關繼續保持關閉。如果當前健康狀況低于設定閾值，開關則切換為打開狀態。當熔斷器開關打開時，請求被禁止通過。當熔斷器開關處于打開狀態，經過一段時間后，熔斷器會自動進入半開狀態，這時熔斷器只允許一個請求通過。當該請求調用成功時，熔斷器恢復到關閉狀態。若該請求失敗，熔斷器繼續保持打開狀態，接下來的請求被禁止通過。 ? ? ? ?熔斷器的開關能保證服務調用者在調用異常服務時，快速返回結果，避免大量的同步等待，并且熔斷器能在一段時間后繼續偵測請求執行結果，提供恢復服務調用的可能。  狀態機有三種狀態 * closed: 關閉狀態(斷路器關閉),所有請求都正常訪問 * open: 打開狀態(斷路器打開),所有請求都會被降級.會對請求情況計數,當一定時間內失敗請求百分比達到閾值,則觸發熔斷,斷路器會完全關閉.默認失敗比例的閾值是50%.請求次數最少不低于20次. * Half open: 半開狀態,closed狀態不是永久的,關閉后會進入休眠時間(默認是5s).隨后斷路器會自動進入半開狀態,此時會釋放部分請求通過,若這些請求都是健康的,則會完全打開斷路器,否則繼續保持關閉,再次進行休眠計時 **命令模式** Hystrix使用命令模式（繼承HystrixCommand類）來包裹具體的服務調用邏輯（run方法），并在命令模式中添加了服務調用失敗后的降級邏輯（getFallback）。 同時在Command的構造方法中可以定義當前服務線程池和熔斷器的相關參數。因此在使用了Command模式構建了服務對象之后，服務便擁有了熔斷器和線程池的功能。 # client配置 有了SpringCloudApplication注解就不用配置其他了 ~~~ //@EnableCircuitBreaker @SpringCloudApplication public class ConsumerApplication { ~~~ # Fallback client調用放,HystrixCommand注解,里面配置失敗時調用的方法. 要求queryByIdFallback和這個原來方法的返回值要一樣 ~~~ @GetMapping("/{id}") @HystrixCommand(fallbackMethod = "queryByIdFallback") //失敗時調用里面的 public String queryById(@PathVariable("id") Long id) { //------------------ } ~~~ ~~~ public String queryByIdFallback(Long id) { return "不好意思,服務器太擁擠"; } ~~~ 上面配置是單個的,如果你想配置局部的,那要寫在類上 ~~~ @RestController @DefaultProperties(defaultFallback = "defaultFallback") @RequestMapping("consumer") public class ConsumerController { @GetMapping("/{id}") @HystrixCommand //不寫走默認 public String queryById(@PathVariable("id") Long id) { //--- } } ~~~ ~~~ //必須是空參的,因為你寫參數,那和其他的不一定對應上 public String defaultFallback() { return "不好意思,服務器太擁擠"; } ~~~ ## 設置超時時間 局部配置 ~~~ //2s超時 @GetMapping("/{id}") @HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") }) public String queryById(@PathVariable("id") Long id) { ~~~ 全局配置,配置文件這個可以不用在局部加注解了 可以指定全局,也可以指定某個服務的名稱. 當然你也可以把user-serivce改為某個方法的名稱 ~~~ hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 2000 user-serivce: execution: isolation: thread: timeoutInMilliseconds: 2000 ~~~ # 熔斷 ~~~ @GetMapping("/{id}") @HystrixCommand(commandProperties = { //請求量,達到多少次統計一下,觸發熔斷的最小請求次數,默認20 @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"), //休眠時間窗,毫秒,默認5000 @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "100000"), //錯誤百分比,默認50% @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60"), }) public String queryById(@PathVariable("id") Long id) { if (id % 2 == 0) { throw new RuntimeException("---"); } ~~~ # 異常處理 ## 異常類型 Hystrix 的異常處理中，有5種出錯的情況下會被 fallback 所截獲，從而觸發 fallback，這些情況是： * FAILURE：執行失敗，拋出異常。 * TIMEOUT：執行超時。 * SHORT_CIRCUITED：斷路器打開。 * THREAD_POOL_REJECTED：線程池拒絕。 * SEMAPHORE_REJECTED：信號量拒絕。 有一種類型的異常是不會觸發 fallback 且不會被計數進入熔斷的，它是 BAD_REQUEST，會拋出 HystrixBadRequestException，這種異常一般對應的是由非法參數或者一些非系統異常引起的，對于這類異常可以根據響應創建對應的異常進行異常封裝或者直接處理。 如果使用@HystrixCommand注解，則只需要在降級函數中增加Throwable??e對象的定義 ~~~ @HystrixCommand(fallbackMethod="helloBackMethodFirst",ignoreExceptions=HystrixBadRequestException.class) ~~~ ## 獲取觸發異常 **注解方式** ~~~ @HystrixCommand(fallbackMethod = "fallback") User getUserById(String id) { throw new RuntimeException("getUserById command failed"); } User fallback(String id, Throwable throwable) { return new User("def", "def"); } ~~~ 這里定義了一個主邏輯函數`getUserById`，主邏輯中會主動拋出一個異常，從而觸發該主邏輯的降級函數`fallback`。重點看`fallback`函數中的最后一個傳參`Throwable throwable`。通過這樣的簡單定義，開發人員就可以很方便的獲取觸發降級邏輯的異常信息，用作日志記錄或者其它復雜的業務邏輯了。 **繼承方式** 在使用繼承方式的時候通過`getFailedExecutionException`方法就可以獲取到觸發降級的異常信息了。 ~~~ public static class UserCommand extends HystrixCommand<User> { protected UserCommand() { s uper(HystrixCommandGroupKey.Factory.asKey("UserCommand")); } @Override protected User run() throws Exception { throw new RuntimeException("getUserById command failed"); } @Override protected User getFallback() { System.out.println(getFailedExecutionException().getMessage()); return new User("def", "def"); } } ~~~