在微服務架構中，我們將系統拆分成了一個個的服務單元，各單元應用間通過服務註冊與訂閱的方式互相依賴。由於每個單元都在不同的程式中執行，依賴通過遠端呼叫的方式執行，這樣就有可能因為網路原因或是依賴服務自身問題出現呼叫故障或延遲，而這些問題會直接導致呼叫方的對外服務也出現延遲，若此時呼叫方的請求不斷增加，最後就會出現因等待出現故障的依賴方響應而形成任務積壓，執行緒資源無法釋放，最終導致自身服務的癱瘓，進一步甚至出現故障的蔓延最終導致整個系統的癱瘓。如果這樣的架構存在如此嚴重的隱患，那麼相較傳統架構就更加的不穩定。為了解決這樣的問題，因此產生了斷路器等一系列的服務保護機制。
針對上述問題，在Spring Cloud Hystrix中實現了執行緒隔離、斷路器等一系列的服務保護功能。它也是基於Netflix的開源框架 Hystrix實現的，該框架目標在於通過控制那些訪問遠端系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備了服務降級、服務熔斷、執行緒隔離、請求快取、請求合併以及服務監控等強大功能。
接下來，我們就從一個簡單示例開始對Spring Cloud Hystrix的學習與使用。
動手試一試
在開始使用Spring Cloud Hystrix實現斷路器之前，我們先拿之前實現的一些內容作為基礎，其中包括：
eureka-server工程：服務註冊中心，埠：1001 eureka-client工程：服務提供者，兩個例項啟動埠分別為2001 下面我們可以複製一下之前實現的一個服務消費者：eureka-consumer-ribbon，命名為eureka-consumer-ribbon-hystrix。下面我們開始對其進行改在：
第一步：pom.xml的dependencies節點中引入spring-cloud-starter-hystrix依賴：
org.springframework.cloud spring-cloud-starter-hystrix 第二步：在應用主類中使用@EnableCircuitBreaker或@EnableHystrix註解開啟Hystrix的使用：@EnableCircuitBreaker @EnableDiscoveryClient @SpringBootApplication public class Application {
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
public static void main(String[] args) {
new SpringApplicationBuilder(Application.class).web(true).run(args);
}
複製程式碼} 注意：這裡我們還可以使用Spring Cloud應用中的@SpringCloudApplication註解來修飾應用主類，該註解的具體定義如下所示。我們可以看到該註解中包含了上我們所引用的三個註解，這也意味著一個Spring Cloud標準應用應包含服務發現以及斷路器。
@Target({ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public @interface SpringCloudApplication { } 第三步：改造服務消費方式，新增ConsumerService類，然後將在Controller中的邏輯遷移過去。最後，在為具體執行邏輯的函式上增加@HystrixCommand註解來指定服務降級方法，比如：
@RestController public class DcController {
@Autowired
ConsumerService consumerService;
@GetMapping("/consumer")
public String dc() {
return consumerService.consumer();
}
class ConsumerService {
@Autowired
RestTemplate restTemplate;
@HystrixCommand(fallbackMethod = "fallback")
public String consumer() {
return restTemplate.getForObject("http://eureka-client/dc", String.class);
}
public String fallback() {
return "fallback";
}
}
複製程式碼} 下面我們來驗證一下上面Hystrix帶來的一些基礎功能。我們先把涉及的服務都啟動起來，然後訪問localhost:2101/consumer，此時可以獲取正常的返回，比如：Services: [eureka-consumer-ribbon-hystrix, eureka-client]。
為了觸發服務降級邏輯，我們可以將服務提供者eureka-client的邏輯加一些延遲，比如：
@GetMapping("/dc") public String dc() throws InterruptedException { Thread.sleep(5000L); String services = "Services: " + discoveryClient.getServices(); System.out.println(services); return services; }
重啟eureka-client之後，再嘗試訪問localhost:2101/consumer，此時我們將獲得的返回結果為：fallback。我們從eureka-client的控制檯中，可以看到服務提供方輸出了原本要返回的結果，但是由於返回前延遲了5秒，而服務消費方觸發了服務請求超時異常，服務消費者就通過HystrixCommand註解中指定的降級邏輯進行執行，因此該請求的結果返回了fallback。這樣的機制，對自身服務起到了基礎的保護，同時還為異常情況提供了自動的服務降級切換機制。
原始碼來源：http://minglisoft.cn/honghu/technology.html