SpringCloud熔斷機制之斷路器的示例分析

這篇文章主要介紹Spring Cloud熔斷機制之斷路器的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)提供從項目策劃、軟件開發(fā)，軟件安全維護、網(wǎng)站優(yōu)化(SEO)、網(wǎng)站分析、效果評估等整套的建站服務(wù)，主營業(yè)務(wù)為網(wǎng)站設(shè)計、成都網(wǎng)站設(shè)計，重慶App定制開發(fā)以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。創(chuàng)新互聯(lián)深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

斷路器（Curcuit Breaker）模式

在分布式環(huán)境下，特別是微服務(wù)結(jié)構(gòu)的分布式系統(tǒng)中， 一個軟件系統(tǒng)調(diào)用另外一個遠程系統(tǒng)是非常普遍的。這種遠程調(diào)用的被調(diào)用方可能是另外一個進程，或者是跨網(wǎng)路的另外一臺主機, 這種遠程的調(diào)用和進程的內(nèi)部調(diào)用最大的區(qū)別是，遠程調(diào)用可能會失敗，或者掛起而沒有任何回應(yīng)，直到超時。更壞的情況是， 如果有多個調(diào)用者對同一個掛起的服務(wù)進行調(diào)用，那么就很有可能的是一個服務(wù)的超時等待迅速蔓延到整個分布式系統(tǒng)，引起連鎖反應(yīng)， 從而消耗掉整個分布式系統(tǒng)大量資源。最終可能導(dǎo)致系統(tǒng)癱瘓。

斷路器（Circuit Breaker）模式就是為了防止在分布式系統(tǒng)中出現(xiàn)這種瀑布似的連鎖反應(yīng)導(dǎo)致的災(zāi)難。

一旦某個電器出問題，為了防止災(zāi)難，電路的保險絲就會熔斷。斷路器類似于電路的保險絲， 實現(xiàn)思路非常簡單，可以將需要保護的遠程服務(wù)嗲用封裝起來，在內(nèi)部監(jiān)聽失敗次數(shù)， 一旦失敗次數(shù)達到某閥值后，所有后續(xù)對該服務(wù)的調(diào)用，斷路器截獲后都直接返回錯誤到調(diào)用方，而不會繼續(xù)調(diào)用已經(jīng)出問題的服務(wù)， 從而達到保護調(diào)用方的目的, 整個系統(tǒng)也就不會出現(xiàn)因為超時而產(chǎn)生的瀑布式連鎖反應(yīng)。

1. 基本模式

上圖是斷路器（Curcuit Breaker）的結(jié)構(gòu)，它有兩個基本狀態(tài)（close和open）和一個基本trip動作：

close狀態(tài)下， client向supplier發(fā)起的服務(wù)請求， 直接無阻礙通過斷路器， supplier的返回值接直接由斷路器交回給client.

open狀態(tài)下，client向supplier發(fā)起的服務(wù)請求后，斷路器不會將請求轉(zhuǎn)到supplier, 而是直接返回client, client和supplier之間的通路是斷的

trip: 在close狀態(tài)下，如果supplier持續(xù)超時報錯， 達到規(guī)定的閥值后，斷路器就發(fā)生trip, 之后斷路器狀態(tài)就會從close進入open.

 2. 擴展模式

基本的斷路器模式下，保證了斷路器在open狀態(tài)時，保護supplier不會被調(diào)用， 但我們還需要額外的措施可以在supplier恢復(fù)服務(wù)后，可以重置斷路器。一種可行的辦法是斷路器定期探測supplier的服務(wù)是否恢復(fù)， 一但恢復(fù)， 就將狀態(tài)設(shè)置成close。斷路器進行重試時的狀態(tài)為半開（half-open）狀態(tài)。

3. 斷路器的使用場合：

一個supplier一般很穩(wěn)定，如果一旦故障發(fā)生后， 檢查和恢復(fù)需要的時間比較長，通常無法短時間內(nèi)快速修復(fù)的，那么這種服務(wù)比較適合采用斷路器模式。否則很可能導(dǎo)致ping-pong效應(yīng)。

3. 斷路器不適合的場合：

 為了防止一個應(yīng)用程序試圖調(diào)用一個遠程服務(wù)或訪問共享資源，如果該操作是極有可能失敗， 這種模式可能不適合。

對于處理中的應(yīng)用程序訪問本地專用資源，例如在存儲器內(nèi)數(shù)據(jù)結(jié)構(gòu)。在這種環(huán)境下通常也不適合，使用斷路器只會增加系統(tǒng)開銷。

下面直接介紹Spring Cloud的斷路器如何使用。

SpringCloud Netflix實現(xiàn)了斷路器庫的名字叫Hystrix. 在微服務(wù)架構(gòu)下，通常會有多個層次的服務(wù)調(diào)用.下面是微服架構(gòu)下, 瀏覽器端通過API訪問后臺微服務(wù)的一個示意圖：

一個微服務(wù)的超時失敗可能導(dǎo)致瀑布式連鎖反映，下圖中，Hystrix通過自主反饋實現(xiàn)的斷路器，防止了這種情況發(fā)生。

圖中的服務(wù)B因為某些原因失敗，變得不可用，所有對服務(wù)B的調(diào)用都會超時。當對B的調(diào)用失敗達到一個特定的閥值(5秒之內(nèi)發(fā)生20次失敗是Hystrix定義的缺省值), 鏈路就會被處于open狀態(tài)， 之后所有所有對服務(wù)B的調(diào)用都不會被執(zhí)行， 取而代之的是由斷路器提供的一個表示鏈路open的Fallback消息. Hystrix提供了相應(yīng)機制，可以讓開發(fā)者定義這個Fallbak消息.

open的鏈路阻斷了瀑布式錯誤， 可以讓被淹沒或者錯誤的服務(wù)有時間進行修復(fù)。這個fallback可以是另外一個Hystrix保護的調(diào)用, 靜態(tài)數(shù)據(jù)，或者合法的空值. Fallbacks可以組成鏈式結(jié)構(gòu)，所以，最底層調(diào)用其它業(yè)務(wù)服務(wù)的第一個Fallback返回靜態(tài)數(shù)據(jù).

下面，進入正題，在之前的兩HELLO WORLD服務(wù)集群中加入斷路器， 防止其中一個Hello world掛掉后， 導(dǎo)致系統(tǒng)發(fā)生連鎖超時失敗。

1. 在maven工程（前面章節(jié)中介紹的Ribbon或者Feign工程）的pom.xml中添加hystrix庫支持斷路器

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

2.在Ribbon應(yīng)用中使用斷路器

1). 在Spring Boot啟動類上添加@EnableCircuitBreaker注解

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceRibbonApplication {

  public static void main(String[] args) {
    SpringApplication.run(ServiceRibbonApplication.class, args);
  }

2). 用@HystrixCommand注解標注訪問服務(wù)的方法

@Service
public class HelloService {
  @Autowired RestTemplate restTemplate;

  @HystrixCommand(fallbackMethod = "serviceFailure")
  public String getHelloContent() {
    return restTemplate.getForObject("http://SERVICE-HELLOWORLD/",String.class);
  }

  public String serviceFailure() {
    return "hello world service is not available !";
  }
}

@HystrixCommand注解定義了一個斷路器，它封裝了getHelloContant()方法， 當它訪問的SERVICE-HELLOWORLD失敗達到閥值后，將不會再調(diào)用SERVICE-HELLOWORLD， 取而代之的是返回由fallbackMethod定義的方法serviceFailure（）。@HystrixCommand注解定義的fallbackMethod方法，需要特別注意的有兩點：

第一， fallbackMethod的返回值和參數(shù)類型需要和被@HystrixCommand注解的方法完全一致。否則會在運行時拋出異常。比如本例中，serviceFailure（）的返回值和getHelloContant()方法的返回值都是String。

第二， 當?shù)讓臃?wù)失敗后，fallbackMethod替換的不是整個被@HystrixCommand注解的方法（本例中的getHelloContant), 替換的只是通過restTemplate去訪問的具體服務(wù)。可以從中的system輸出看到， 即使失敗，控制臺輸出里面依然會有“call SERVICE-HELLOWORLD”。

啟動eureka服務(wù)，只啟動兩個Helloworld服務(wù)，然后中斷其中一個（模擬其中一個微服務(wù)掛起），訪問http://localhost:8901/然后刷新, 由于有負載均衡可以看到以下兩個頁面交替出現(xiàn)。可以看到第二個被掛起的服務(wù)，被定義在Ribbon應(yīng)該里面的錯誤處理方法替換了。

4. 在Feign應(yīng)用中使用斷路器

1）. Feign內(nèi)部已經(jīng)支持了斷路器，所以不需要想Ribbon方式一樣，在Spring Boot啟動類上加額外注解

2）. 用@FeignClient注解添加fallback類， 該類必須實現(xiàn)@FeignClient修飾的接口。

@FeignClient(name = "SERVICE-HELLOWORLD", fallback = HelloWorldServiceFailure.class)
 public interface HelloWorldService {
   @RequestMapping(value = "/", method = RequestMethod.GET)
   public String sayHello();
 }

3). 創(chuàng)建HelloWorldServiceFailure類， 必須實現(xiàn)被@FeignClient修飾的HelloWorldService接口。注意添加@Component或者@Service注解，在Spring容器中生成一個Bean

@Component
public class HelloWorldServiceFailure implements HelloWorldService {
  @Override
  public String sayHello() {
    System.out.println("hello world service is not available !");
    return "hello world service is not available !";
  }
}

4）. Spring Cloud之前的Brixton版本中，F(xiàn)eign是缺省是自動激活了斷路器的，但最近的Dalston版本已經(jīng)將缺省配置修改為禁止。

原因參見： https://github.com/spring-cloud/spring-cloud-netflix/issues/1277， 這一點要注意。所以要在Feign中使用斷路器， 必須在application.yml中添加如下配置：

feign:
  hystrix:
   enabled: true

5）. 啟動Feign應(yīng)用， 訪問http://localhost：8902/hello， 可以一看到和Ribbon一樣的效果。

以上是“Spring Cloud熔斷機制之斷路器的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

本文題目：SpringCloud熔斷機制之斷路器的示例分析
URL地址：http://m.kartarina.com/article8/jeccop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、云服務(wù)器、App開發(fā)、軟件開發(fā)、標簽優(yōu)化、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)