###服務降級 在之前eureka-consumer的基礎上 新增依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
複製程式碼Application 新增註解@EnableCircuitBreaker或者@EnableHystrix 或者只需要一個註解@SpringCloudApplication
service
@Service
public class DemoService {
@Autowired
RestTemplate restTemplate;
@HystrixCommand(fallbackMethod = "fallback")
public String hello(){
try {
//Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return restTemplate.getForObject("http://eureka-client/hello",String.class);
}
public String fallback(){
return "fallback";
}
}
複製程式碼controller
@GetMapping("/hello")
public String hello2(){
return demoService.hello();
}
複製程式碼這樣便實現了服務降級，將service中的Thread.sleep(5000)註釋去掉，便可以模擬請求超時，系統便會呼叫fallback方法。
###依賴隔離
“艙壁模式”對於熟悉Docker的讀者一定不陌生，Docker通過“艙壁模式”實現程式的隔離，使得容器與容器之間不會互相影響。而Hystrix則使用該模式實現執行緒池的隔離，它會為每一個Hystrix命令建立一個獨立的執行緒池，這樣就算某個在Hystrix命令包裝下的依賴服務出現延遲過高的情況，也只是對該依賴服務的呼叫產生影響，而不會拖慢其他的服務。
通過對依賴服務的執行緒池隔離實現，可以帶來如下優勢：
- 應用自身得到完全的保護，不會受不可控的依賴服務影響。即便給依賴服務分配的執行緒池被填滿，也不會影響應用自身的額其餘部分。
- 可以有效的降低接入新服務的風險。如果新服務接入後執行不穩定或存在問題，完全不會影響到應用其他的請求。
- 當依賴的服務從失效恢復正常後，它的執行緒池會被清理並且能夠馬上恢復健康的服務，相比之下容器級別的清理恢復速度要慢得多。
- 當依賴的服務出現配置錯誤的時候，執行緒池會快速的反應出此問題（通過失敗次數、延遲、超時、拒絕等指標的增加情況）。同時，我們可以在不影響應用功能的情況下通過實時的動態屬性重新整理（後續會通過Spring Cloud Config與Spring Cloud Bus的聯合使用來介紹）來處理它。
- 當依賴的服務因實現機制調整等原因造成其效能出現很大變化的時候，此時執行緒池的監控指標資訊會反映出這樣的變化。同時，我們也可以通過實時動態重新整理自身應用對依賴服務的閾值進行調整以適應依賴方的改變。
- 除了上面通過執行緒池隔離服務發揮的優點之外，每個專有執行緒池都提供了內建的併發實現，可以利用它為同步的依賴服務構建非同步的訪問。
總之，通過對依賴服務實現執行緒池隔離，讓我們的應用更加健壯，不會因為個別依賴服務出現問題而引起非相關服務的異常。同時，也使得我們的應用變得更加靈活，可以在不停止服務的情況下，配合動態配置重新整理實現效能配置上的調整。
###斷路器
當我們把服務提供者eureka-client中加入了模擬的時間延遲之後，在服務消費端的服務降級邏輯因為hystrix命令呼叫依賴服務超時，觸發了降級邏輯，但是即使這樣，受限於Hystrix超時時間的問題，我們的呼叫依然很有可能產生堆積。
這個時候斷路器就會發揮作用，那麼斷路器是在什麼情況下開始起作用呢？這裡涉及到斷路器的三個重要引數：快照時間窗、請求總數下限、錯誤百分比下限。這個引數的作用分別是：
- 快照時間窗：斷路器確定是否開啟需要統計一些請求和錯誤資料，而統計的時間範圍就是快照時間窗，預設為最近的10秒。
- 請求總數下限：在快照時間窗內，必須滿足請求總數下限才有資格根據熔斷。預設為20，意味著在10秒內，如果該hystrix命令的呼叫此時不足20次，即時所有的請求都超時或其他原因失敗，斷路器都不會開啟。
- 錯誤百分比下限：當請求總數在快照時間窗內超過了下限，比如發生了30次呼叫，如果在這30次呼叫中，有16次發生了超時異常，也就是超過50%的錯誤百分比，在預設設定50%下限情況下，這時候就會將斷路器開啟。
那麼當斷路器開啟之後會發生什麼呢？我們先來說說斷路器未開啟之前，對於之前那個示例的情況就是每個請求都會在當hystrix超時之後返回fallback，每個請求時間延遲就是近似hystrix的超時時間，如果設定為5秒，那麼每個請求就都要延遲5秒才會返回。當熔斷器在10秒內發現請求總數超過20，並且錯誤百分比超過50%，這個時候熔斷器開啟。開啟之後，再有請求呼叫的時候，將不會呼叫主邏輯，而是直接呼叫降級邏輯，這個時候就不會等待5秒之後才返回fallback。通過斷路器，實現了自動地發現錯誤並將降級邏輯切換為主邏輯，減少響應延遲的效果。
在斷路器開啟之後，處理邏輯並沒有結束，我們的降級邏輯已經被成了主邏輯，那麼原來的主邏輯要如何恢復呢？對於這一問題，hystrix也為我們實現了自動恢復功能。當斷路器開啟，對主邏輯進行熔斷之後，hystrix會啟動一個休眠時間窗，在這個時間窗內，降級邏輯是臨時的成為主邏輯，當休眠時間窗到期，斷路器將進入半開狀態，釋放一次請求到原來的主邏輯上，如果此次請求正常返回，那麼斷路器將繼續閉合，主邏輯恢復，如果這次請求依然有問題，斷路器繼續進入開啟狀態，休眠時間窗重新計時。
通過上面的一系列機制，hystrix的斷路器實現了對依賴資源故障的埠、對降級策略的自動切換以及對主邏輯的自動恢復機制。這使得我們的微服務在依賴外部服務或資源的時候得到了非常好的保護，同時對於一些具備降級邏輯的業務需求可以實現自動化的切換與恢復，相比於設定開關由監控和運維來進行切換的傳統實現方式顯得更為智慧和高效。
我們使用了@HystrixCommand來將某個函式包裝成了Hystrix命令，這裡除了定義服務降級之外，Hystrix框架就會自動的為這個函式實現呼叫的隔離。所以，依賴隔離、服務降級在使用時候都是一體化實現的，這樣利用Hystrix來實現服務容錯保護在程式設計模型上就非常方便的，並且考慮更為全面。除了依賴隔離、服務降級之外，還有一個重要元素：斷路器。這三個重要利器構成了Hystrix實現服務容錯保護的強力組合拳。