SpringCloud----ribbon重試機制和Hystrix熔斷器

1.重試機制Ribbonspring

1.1 概述: 服務B訪問集羣環境下的服務A,某一個服務A宕機,服務B將嘗試訪問其餘可使用的服務A.函數

1.2 實現步驟:學習

• 步驟一 : 修改pom.xml文件,添加劇試機制的依賴測試

<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>spa

•步驟二 : 修改yml文件,開啓cloud重試機制xml

spring:
cloud:
loadbalancer:
retry:
enabled: true #開啓重試機制

•步驟三 : 修改yml 文件,配置當前服務的重試參數ci

格式: {服務名稱}.ribbon.參數名 : 具體值io

service4:
ribbon:
ConnectTimeout: 250 # Ribbon的鏈接超時時間
ReadTimeout: 1000 # Ribbon的數據讀取超時時間
OkToRetryOnAllOperations: true # 是否對全部操做都進行重試
MaxAutoRetriesNextServer: 1 # 切換實例的重試次數
MaxAutoRetries: 1 # 對當前實例的重試次數

1.3運行測試 :table

當多個消息提供者關閉一個,不會請求返回異常,通過鏈接超時時間就會返回全部響應數據class

2.熔斷器Hystrix

2.1 概述:Hystrix是Netflix開源的一個延遲和容錯庫，用於隔離訪問遠程服務、第三方庫，防止出現級聯失敗。

2.2 功能: 當服務繁忙時，若是服務出現異常，不是粗暴的直接報錯，而是返回一個友好的提示，雖然拒絕了用戶的訪問，可是會返回一個結果。

2.3 實現步驟 :

• 步驟一 : 修改pom.xml文件,添加Hystrix的依賴

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

•步驟二 : 開啓熔斷(啓動類上加入@EnableHystrix註解)

@SpringBootApplication
@EnableEurekaClient
@EnableHystrix      //開啓熔斷器
public class ClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(ClientApplication.class,args);
    }
}

•步驟三 : 修改消費者

查找方法並在方法上添加註解聲明一個失敗時的回滾處理函數

@HystrixCommand(fallbackMethod = 「回滾函數的函數名」)

2.4 運行測試

請求超過一秒(默認1000毫秒)得不到響應,就回執行回滾處理函數,返回替代內容

3.ribbon和Hystrix相結合

3.1簡述:

若是熔斷和重試機制，都配置，是都生效？仍是某個生效？

經測試發現是熔斷生效，爲何？

實際執行後發現,沒有觸發重試機制,而是先觸發了熔斷,緣由是這兩種技術都採用的是默認時間1000毫秒,而這不是咱們想要的結果,咱們學習了這兩種技術,天然是想把它們融合到項目中,因此咱們採用的解決方案是 Ribbon的超時時間必定要小於Hystrix的超時時間.

3.2實現步驟:

咱們能夠經過

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

來設置Hystrix超時時間。(注意設置的值爲毫秒值)

hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMillisecond: 6000 # 設置hystrix的超時時間爲6000ms