第四篇：SpringCloud之熔斷器Hystrix
熔斷器
雪崩效應
在微服務架構中通常會有多個服務層呼叫，基礎服務的故障可能會導致級聯故障，進而造成整個系統不可用的情況，這種現象被稱為服務雪崩效應。服務雪崩效應是一種因“服務提供者”的不可用導致“服務消費者”的不可用,並將不可用逐漸放大的過程。
如果下圖所示：A作為服務提供者，B為A的服務消費者，C和D是B的服務消費者。A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
熔斷器（CircuitBreaker）
熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個呼叫快速失敗，不再訪問遠端伺服器，從而防止應用程式不斷地嘗試執行可能會失敗的操作，使得應用程式繼續執行而不用等待修正錯誤，或者浪費CPU時間去等到長時間的超時產生。熔斷器也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。
熔斷器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近呼叫發生錯誤的次數，然後決定使用允許操作繼續，或者立即返回錯誤。 熔斷器開關相互轉換的邏輯如下圖：
熔斷器就是保護服務高可用的最後一道防線。
Hystrix特性
1.斷路器機制
斷路器很好理解, 當Hystrix Command請求後端服務失敗數量超過一定比例(預設50%), 斷路器會切換到開路狀態(Open). 這時所有請求會直接失敗而不會發送到後端服務. 斷路器保持在開路狀態一段時間後(預設5秒), 自動切換到半開路狀態(HALF-OPEN). 這時會判斷下一次請求的返回情況, 如果請求成功, 斷路器切回閉路狀態(CLOSED), 否則重新切換到開路狀態(OPEN). Hystrix的斷路器就像我們家庭電路中的保險絲, 一旦後端服務不可用, 斷路器會直接切斷請求鏈, 避免傳送大量無效請求影響系統吞吐量, 並且斷路器有自我檢測並恢復的能力。
2.Fallback
Fallback相當於是降級操作. 對於查詢操作, 我們可以實現一個fallback方法, 當請求後端服務出現異常的時候, 可以使用fallback方法返回的值. fallback方法的返回值一般是設定的預設值或者來自快取.
3.資源隔離
在Hystrix中, 主要通過執行緒池來實現資源隔離. 通常在使用的時候我們會根據呼叫的遠端服務劃分出多個執行緒池. 例如呼叫產品服務的Command放入A執行緒池, 呼叫賬戶服務的Command放入B執行緒池. 這樣做的主要優點是執行環境被隔離開了. 這樣就算呼叫服務的程式碼存在bug或者由於其他原因導致自己所線上程池被耗盡時, 不會對系統的其他服務造成影響. 但是帶來的代價就是維護多個執行緒池會對系統帶來額外的效能開銷. 如果是對效能有嚴格要求而且確信自己呼叫服務的客戶端程式碼不會出問題的話, 可以使用Hystrix的訊號模式(Semaphores)來隔離資源.
服務提供
這一篇文章基於上一篇文章的工程，啟動sso-server，埠為8088; 啟動serviceA兩次，埠分別為8089、8090。
在ribbon使用斷路器
改造sso-ribbon 工程的程式碼，首先在父工程pom.xml檔案中加入spring-cloud-starter-hystrix的起步依賴：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
在程式的啟動類ServiceRibbonApplication 加@EnableHystrix註解開啟Hystrix：
@SpringBootApplication
@EnableEurekaClient
@EnableHystrix
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
@Bean
@LoadBalanced
RestTemplate restTemplate() {
return new RestTemplate();
}
}
改造HelloService類，在hiService方法上加上@HystrixCommand註解。該註解對該方法建立了熔斷器的功能，並指定了fallbackMethod熔斷方法，熔斷方法直接返回了一個字串，字串為"hello,"+name+",sorry,error!"，程式碼如下：
@Service
public class HelloService {
@Autowired
RestTemplate restTemplate;
@HystrixCommand(fallbackMethod = "helloError")
public String helloService(String name) {
return restTemplate.getForObject("http://SERVICEA/hello?name="+name,String.class);
}
public String helloError(String name) {
return "hello," + name + ",sorry,error!";
}
}
啟動：service-ribbon 工程，當我們訪問http://localhost:8091/hello?name=chenjay,瀏覽器顯示：
此時關閉 serviceA 工程，當我們再訪問http://localhost:8091/hello?name=chenjay，瀏覽器會顯示：
這就說明當 serviceA 工程不可用的時候，service-ribbon呼叫 serviceA的API介面時，會執行快速失敗，直接返回一組字串，而不是等待響應超時，這很好的控制了容器的執行緒阻塞。
Feign中使用斷路器
Feign是自帶斷路器的，在D版本的Sprin Cloud之後，它沒有預設開啟。需要在配置檔案中配置開啟它，在配置檔案加以下程式碼：
feign:
hystrix:
enabled: true
基於sso-feign工程進行改造，只需要在FeignClient的SchedualServiceHello 介面的註解中加上fallback的指定類就行了：
@FeignClient(value = "serviceA",fallback = SchedualServiceHelloHystric.class)
public interface SchedualServiceHello {
@GetMapping(value = "/hello")
String sayHiFromClientOne(@RequestParam(value = "name") String name);
}
SchedualServiceHelloHystric需要實現SchedualServiceHello介面，並注入到Ioc容器中，程式碼如下：
@Component
public class SchedualServiceHelloHystric implements SchedualServiceHello {
@Override
public String sayHiFromClientOne(String name) {
return "sorry "+name;
}
}
啟動：service-feign工程，當我們訪問http://localhost:8092/hello?name=chenjay,瀏覽器顯示：
此時關閉 serviceA 工程，當我們再訪問http://localhost:8092/hello?name=chenjay，瀏覽器會顯示：
這證明斷路器起到作用了。
原始碼下載：https://github.com/chenjary/SpringCloud/tree/master/springcloud-hystrix