使用SpringBoot實現(xiàn)微服務超時重試模式的示例
使用resilience4j的庫和Spring Boot設計高彈性的微服務。
微服務本質上是分布式的。當您使用分布式系統(tǒng)時,請始終記住這一第一法則- 網絡中可能發(fā)生任何事情。處理任何此類意外故障可能很難解決。故障可能是任何東西-應用程序,硬件或網絡等。
系統(tǒng)從故障中恢復并保持正常運行的能力使系統(tǒng)更具 彈性。它還避免了下游服務的任何級聯(lián)故障。
重試模式:
在微服務體系結構中,當有多個服務(A,B,C和D)時,一個服務(A)可能依賴于另一服務(B),而另一服務(B)又可能依賴于C,依此類推。有時由于某些問題,服務D可能無法按預期響應。服務D可能引發(fā)了某些異常,例如內存不足 錯誤或內部服務器錯誤。此類異常被級聯(lián)到下游服務,這可能導致不良的用戶體驗,如下所示。

有時,當google.com對我們不起作用時,我們只是不放棄。我們假設頁面下次可以正常工作,并且大多數(shù)情況下都會刷新頁面,因此只需刷新頁面即可。間歇性網絡問題非常普遍。在微服務領域,我們可能正在運行同一服務D的多個實例,以實現(xiàn)高可用性和負載平衡。如果其中一個實例可能有問題,并且無法正確響應我們的請求,則如果我們重試該請求,則負載均衡器可以將請求發(fā)送到運行狀況良好的節(jié)點并正確獲得響應。因此,使用“重試”選項,我們有更多機會獲得正確的響應。

讓我們考慮這個簡單的應用程序來解釋此重試模式。

- 如上所述,我們有多個微服務
- 產品服務充當產品目錄并負責提供產品信息
- 產品服務取決于評級服務。
- 評分服務維護產品評論和評分。 由于擁有大量數(shù)據(jù)而速度慢是眾所周知的。
- 每當我們查看產品詳細信息時,產品服務就會將請求發(fā)送到評分服務,以獲取該產品的評論。
- 我們還有其他服務,例如帳戶服務,訂單服務和付款服務等,與本文的討論無關。
- 產品服務是一項核心服務,沒有它,用戶將無法啟動訂單工作流程。
設置:
<dependency> <groupId>io.github.resilience4j</groupId> <artifactId>resilience4j-spring-boot2</artifactId> <version>1.6.1</version> </dependency>
產品服務負責根據(jù)用戶搜索條件提供產品列表。它是即使在關鍵負載下也應該啟動和響應的核心服務之一。如果下降,將嚴重影響收入。由于此服務取決于評級服務,因此我們不希望任何網絡問題或評級服務不可用性影響此產品服務。這就是使用 resilience4j 庫的目的。
- 我首先為resilience4j創(chuàng)建一個配置, 如下所示。在這里,我們將超時明確設置為3秒。我們可以在特定的超時時間內添加多個服務。
- 我們可以有多種服務配置,如下所示。
- 對于ratingService,我們將最多進行3次重試,延遲5秒。
- retryExceptions:這些是我們將重試的異常。這是一個數(shù)組字段。您可以配置多個例外。
- ignoreExceptions:有些異常我們可能不想重試。例如,一個錯誤的請求就是一個錯誤的請求。重試沒有意義。因此,我們忽略了這一點。
resilience4j.retry: instances: ratingService: maxRetryAttempts: 3 waitDuration: 5s retryExceptions: - org.springframework.web.client.HttpServerErrorException ignoreExceptions: - org.springframework.web.client.HttpClientErrorException someOtherService: maxRetryAttempts: 3 waitDuration: 10s retryExceptions: - org.springframework.web.client.HttpServerErrorException - java.io.IOException
代碼:
@Service
public class RatingServiceClient {
private final RestTemplate restTemplate = new RestTemplate();
@Value("${rating.service.endpoint}")
private String ratingService;
@Retry(name = "ratingService", fallbackMethod = "getDefault")
public CompletionStage<ProductRatingDto> getProductRatingDto(int productId){
Supplier<ProductRatingDto> supplier = () ->
this.restTemplate.getForEntity(this.ratingService + productId, ProductRatingDto.class)
.getBody();
return CompletableFuture.supplyAsync(supplier);
}
private CompletionStage<ProductRatingDto> getDefault(int productId, HttpClientErrorException throwable){
return CompletableFuture.supplyAsync(() -> ProductRatingDto.of(0, Collections.emptyList()));
}
}
代碼解釋:
- @Retry表示resilience4j將對該方法執(zhí)行應用重試邏輯。
- name = ratingService 表示 resilience4j 將使用yaml中的ratingService配置。
- 當main方法由于某種原因失敗時,將使用fallbackMethod。
總結
重試模式 是用于設計彈性微服務的最簡單的微服務 設計模式之一。引入重試可以解決與網絡相關的問題。
源代碼可 在此處獲得。
超時模式源碼可在此處獲得。
以上就是使用SpringBoot實現(xiàn)微服務超時重試模式的示例的詳細內容,更多關于SpringBoot實現(xiàn)微服務超時的資料請關注腳本之家其它相關文章!
相關文章
Mybatis使用useGeneratedKeys獲取自增主鍵
這篇文章主要為大家介紹了Mybatis使用useGeneratedKeys獲取自增主鍵示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-01-01
使用mybatis切片實現(xiàn)數(shù)據(jù)權限控制的操作流程
數(shù)據(jù)權限控制需要對查詢出的數(shù)據(jù)進行篩選,對業(yè)務入侵最少的方式就是利用mybatis或者數(shù)據(jù)庫連接池的切片對已有業(yè)務的sql進行修改,本文給大家介紹了使用mybatis切片實現(xiàn)數(shù)據(jù)權限控制的操作流程,需要的朋友可以參考下2024-07-07
java如何發(fā)送get請求獲取數(shù)據(jù)(附代碼)
這篇文章主要給大家介紹了關于java如何發(fā)送get請求獲取數(shù)據(jù)的相關資料,Java中的GET請求方法是HTTP協(xié)議中的一種請求方式,用于向服務器請求獲取資源,需要的朋友可以參考下2023-10-10

