###服務(wù)降級 在之前eureka-consumer的基礎(chǔ)上 添加依賴

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

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";}} 復(fù)制代碼

controller

@GetMapping("/hello")public String hello2(){return demoService.hello();} 復(fù)制代碼

這樣便實現(xiàn)了服務(wù)降級，將service中的Thread.sleep(5000)注釋去掉，便可以模擬請求超時，系統(tǒng)便會調(diào)用fallback方法。

###依賴隔離

“艙壁模式”對于熟悉Docker的讀者一定不陌生，Docker通過“艙壁模式”實現(xiàn)進(jìn)程的隔離，使得容器與容器之間不會互相影響。而Hystrix則使用該模式實現(xiàn)線程池的隔離，它會為每一個Hystrix命令創(chuàng)建一個獨立的線程池，這樣就算某個在Hystrix命令包裝下的依賴服務(wù)出現(xiàn)延遲過高的情況，也只是對該依賴服務(wù)的調(diào)用產(chǎn)生影響，而不會拖慢其他的服務(wù)。

通過對依賴服務(wù)的線程池隔離實現(xiàn)，可以帶來如下優(yōu)勢：

• 應(yīng)用自身得到完全的保護(hù)，不會受不可控的依賴服務(wù)影響。即便給依賴服務(wù)分配的線程池被填滿，也不會影響應(yīng)用自身的額其余部分。
• 可以有效的降低接入新服務(wù)的風(fēng)險。如果新服務(wù)接入后運行不穩(wěn)定或存在問題，完全不會影響到應(yīng)用其他的請求。
• 當(dāng)依賴的服務(wù)從失效恢復(fù)正常后，它的線程池會被清理并且能夠馬上恢復(fù)健康的服務(wù)，相比之下容器級別的清理恢復(fù)速度要慢得多。
• 當(dāng)依賴的服務(wù)出現(xiàn)配置錯誤的時候，線程池會快速的反應(yīng)出此問題（通過失敗次數(shù)、延遲、超時、拒絕等指標(biāo)的增加情況）。同時，我們可以在不影響應(yīng)用功能的情況下通過實時的動態(tài)屬性刷新（后續(xù)會通過Spring Cloud Config與Spring Cloud Bus的聯(lián)合使用來介紹）來處理它。
• 當(dāng)依賴的服務(wù)因?qū)崿F(xiàn)機制調(diào)整等原因造成其性能出現(xiàn)很大變化的時候，此時線程池的監(jiān)控指標(biāo)信息會反映出這樣的變化。同時，我們也可以通過實時動態(tài)刷新自身應(yīng)用對依賴服務(wù)的閾值進(jìn)行調(diào)整以適應(yīng)依賴方的改變。
• 除了上面通過線程池隔離服務(wù)發(fā)揮的優(yōu)點之外，每個專有線程池都提供了內(nèi)置的并發(fā)實現(xiàn)，可以利用它為同步的依賴服務(wù)構(gòu)建異步的訪問。

總之，通過對依賴服務(wù)實現(xiàn)線程池隔離，讓我們的應(yīng)用更加健壯，不會因為個別依賴服務(wù)出現(xiàn)問題而引起非相關(guān)服務(wù)的異常。同時，也使得我們的應(yīng)用變得更加靈活，可以在不停止服務(wù)的情況下，配合動態(tài)配置刷新實現(xiàn)性能配置上的調(diào)整。

###斷路器

當(dāng)我們把服務(wù)提供者eureka-client中加入了模擬的時間延遲之后，在服務(wù)消費端的服務(wù)降級邏輯因為hystrix命令調(diào)用依賴服務(wù)超時，觸發(fā)了降級邏輯，但是即使這樣，受限于Hystrix超時時間的問題，我們的調(diào)用依然很有可能產(chǎn)生堆積。

這個時候斷路器就會發(fā)揮作用，那么斷路器是在什么情況下開始起作用呢？這里涉及到斷路器的三個重要參數(shù)：快照時間窗、請求總數(shù)下限、錯誤百分比下限。這個參數(shù)的作用分別是：

• 快照時間窗：斷路器確定是否打開需要統(tǒng)計一些請求和錯誤數(shù)據(jù)，而統(tǒng)計的時間范圍就是快照時間窗，默認(rèn)為最近的10秒。
• 請求總數(shù)下限：在快照時間窗內(nèi)，必須滿足請求總數(shù)下限才有資格根據(jù)熔斷。默認(rèn)為20，意味著在10秒內(nèi)，如果該hystrix命令的調(diào)用此時不足20次，即時所有的請求都超時或其他原因失敗，斷路器都不會打開。
• 錯誤百分比下限：當(dāng)請求總數(shù)在快照時間窗內(nèi)超過了下限，比如發(fā)生了30次調(diào)用，如果在這30次調(diào)用中，有16次發(fā)生了超時異常，也就是超過50%的錯誤百分比，在默認(rèn)設(shè)定50%下限情況下，這時候就會將斷路器打開。

那么當(dāng)斷路器打開之后會發(fā)生什么呢？我們先來說說斷路器未打開之前，對于之前那個示例的情況就是每個請求都會在當(dāng)hystrix超時之后返回fallback，每個請求時間延遲就是近似hystrix的超時時間，如果設(shè)置為5秒，那么每個請求就都要延遲5秒才會返回。當(dāng)熔斷器在10秒內(nèi)發(fā)現(xiàn)請求總數(shù)超過20，并且錯誤百分比超過50%，這個時候熔斷器打開。打開之后，再有請求調(diào)用的時候，將不會調(diào)用主邏輯，而是直接調(diào)用降級邏輯，這個時候就不會等待5秒之后才返回fallback。通過斷路器，實現(xiàn)了自動地發(fā)現(xiàn)錯誤并將降級邏輯切換為主邏輯，減少響應(yīng)延遲的效果。

在斷路器打開之后，處理邏輯并沒有結(jié)束，我們的降級邏輯已經(jīng)被成了主邏輯，那么原來的主邏輯要如何恢復(fù)呢？對于這一問題，hystrix也為我們實現(xiàn)了自動恢復(fù)功能。當(dāng)斷路器打開，對主邏輯進(jìn)行熔斷之后，hystrix會啟動一個休眠時間窗，在這個時間窗內(nèi)，降級邏輯是臨時的成為主邏輯，當(dāng)休眠時間窗到期，斷路器將進(jìn)入半開狀態(tài)，釋放一次請求到原來的主邏輯上，如果此次請求正常返回，那么斷路器將繼續(xù)閉合，主邏輯恢復(fù)，如果這次請求依然有問題，斷路器繼續(xù)進(jìn)入打開狀態(tài)，休眠時間窗重新計時。

通過上面的一系列機制，hystrix的斷路器實現(xiàn)了對依賴資源故障的端口、對降級策略的自動切換以及對主邏輯的自動恢復(fù)機制。這使得我們的微服務(wù)在依賴外部服務(wù)或資源的時候得到了非常好的保護(hù)，同時對于一些具備降級邏輯的業(yè)務(wù)需求可以實現(xiàn)自動化的切換與恢復(fù)，相比于設(shè)置開關(guān)由監(jiān)控和運維來進(jìn)行切換的傳統(tǒng)實現(xiàn)方式顯得更為智能和高效。

我們使用了@HystrixCommand來將某個函數(shù)包裝成了Hystrix命令，這里除了定義服務(wù)降級之外，Hystrix框架就會自動的為這個函數(shù)實現(xiàn)調(diào)用的隔離。所以，依賴隔離、服務(wù)降級在使用時候都是一體化實現(xiàn)的，這樣利用Hystrix來實現(xiàn)服務(wù)容錯保護(hù)在編程模型上就非常方便的，并且考慮更為全面。除了依賴隔離、服務(wù)降級之外，還有一個重要元素：斷路器。這三個重要利器構(gòu)成了Hystrix實現(xiàn)服務(wù)容錯保護(hù)的強力組合拳。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。