###服務降級 在之前eureka-consumer的基礎上 添加依賴

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-hystrix</artifactId></dependency> 復制代碼

Application 添加注解@EnableCircuitBreaker或者@EnableHystrix 或者只需要一個注解@SpringCloudApplication

service

@Servicepublic class DemoService {@AutowiredRestTemplate 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實現服務容錯保護的強力組合拳。

總結

以上是生活随笔為你收集整理的springcloud微服务实战 学习笔记五 Hystrix服务降级 Hystrix依赖隔离 断路器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。