當主機離線時，如何在 Java 中重試 RestTemplate HTTP 請求

1. 概述

當 HTTP 請求因主機暫時離線或無法存取而失敗時，通常重試請求比立即終止請求更可靠。這種稱為retry邏輯,技術有助於提高應用程式的彈性和可靠性，尤其是在處理不穩定的網路或遠端服務時。

在 Java 中， Spring 框架的[RestTemplate](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html)是一個廣泛使用的 RESTful 用戶端。然而，預設情況下， RestTemplate不會在遇到諸如SocketTimeoutException或UnknownHostException等失敗情況時自動重試請求。

在本教程中，我們將探討如何以簡潔且可重複使用的方式實作RestTemplate請求的自動重試。為了簡單起見，我們將使用 Spring Boot。目標是建立一個小型重試機制，以便在主機離線或暫時不可用時自動重試 HTTP 請求。

2. 理解問題

當主機離線或無法存取時， RestTemplate通常會拋出ResourceAccessException例外。此異常封裝了更底層的異常，例如ConnectException或UnknownHostException 。如果沒有重試邏輯，我們的應用程式會在第一次嘗試時立即失敗。

我們先來了解一下嘗試連接到離線主機時會發生什麼：

RestTemplate restTemplate = new RestTemplate();

 String url = "http://localhost:8090/api/data";



 try {

 String response = restTemplate.getForObject(url, String.class);

 } catch (ResourceAccessException e) {

 // This will be thrown when host is offline

 System.out.println("Host is unreachable: " + e.getMessage());

 }

如果連接埠 8090 上的主機未執行，上述程式碼將立即失敗。為了提高應用程式的容錯性，我們需要實作重試機制。

3. 手動重試實現

最直接的方法是使用循環手動實現重試邏輯。這樣我們就可以完全控制重試行為，包括嘗試次數和重試間隔。

在深入建立自訂重試機制之前，至關重要的是要建立一個健壯且可重複使用的 HTTP 用戶端，我們的重試邏輯將依賴它。在大多數 Spring Boot 應用程式中，這通常透過RestTemplate bean 來實現。透過正確配置，我們可以在重試邏輯生效之前控制連接行為，例如逾時和請求處理。

以下配置類別定義了一個RestTemplate bean，它作為整個應用程式中可靠 REST 呼叫的基礎：

public class RestTemplateConfig {



 @Bean

 public RestTemplate restTemplate() {

 HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();

 factory.setConnectTimeout(5000);

 factory.setConnectionRequestTimeout(5000);



 return new RestTemplate(factory);

 }

 }

3.1 基本重試邏輯

在引入任何框架之前，我們先來了解如何使用純 Java 實作簡單的重試機制。以下是一個簡單的實現，它會重試固定次數，每次重試之間有一定的延遲：

public class RestTemplateRetryService {



 private RestTemplate restTemplate = new RestTemplate();

 private int maxRetries = 3;

 private long retryDelay = 2000;



 public String makeRequestWithRetry(String url) {

 int attempt = 0;

 while (attempt < maxRetries) {

 try {

 return restTemplate.getForObject(url, String.class);

 } catch (ResourceAccessException e) {

 attempt++;

 if (attempt >= maxRetries) {

 throw new RuntimeException(

 "Failed after " + maxRetries + " attempts", e);

 }

 try {

 Thread.sleep(retryDelay);

 } catch (InterruptedException ie) {

 Thread.currentThread().interrupt();

 throw new RuntimeException("Retry interrupted", ie);

 }

 }

 }

 throw new RuntimeException("Unexpected error in retry logic");

 }

 }

此實作最多會嘗試三次請求，每次嘗試之間間隔兩秒。如果所有嘗試都失敗，則會拋出一個包含原始原因的RuntimeException ，以便於偵錯。

3.2 測試重試邏輯

我們可以透過模擬主機離線場景來測試這種行為。現在，讓我們驗證重試機制在主機離線時是否真的會觸發多次嘗試。以下 JUnit 測試會檢查異常處理和預期延遲：

@Test

 void whenHostOffline_thenRetriesAndFails() {

 RestTemplateRetryService service = new RestTemplateRetryService();

 String offlineUrl = "http://localhost:9999/api/data";



 long startTime = System.currentTimeMillis();



 assertThrows(RuntimeException.class, () -> {

 service.makeRequestWithRetry(offlineUrl);

 });



 long duration = System.currentTimeMillis() - startTime;

 assertTrue(duration >= 4000); // Should take at least 4 seconds (2 retries * 2 seconds)

 }

此測試透過確保總執行時間至少為四秒來驗證重試機制是否正常運作，這表示重試按預期延遲進行。

3.3.指數退避策略

對於生產系統而言，指數退避通常是更優的選擇，因為它能降低故障服務的負載。在實際系統中，使用固定的重試延遲有時會對其他服務造成不必要的壓力。更好的方法是使用exponential backoff ，即每次故障後增加等待時間。這樣可以使系統更優雅地恢復，避免目標服務過載。

@Service

 public class ExponentialBackoffRetryService {



 private final RestTemplate restTemplate;

 private int maxRetries = 5;

 private long initialDelay = 1000;



 public ExponentialBackoffRetryService(RestTemplate restTemplate) {

 this.restTemplate = restTemplate;

 }



 public String makeRequestWithExponentialBackoff(String url) {

 int attempt = 0;

 while (attempt < maxRetries) {

 try {

 return restTemplate.getForObject(url, String.class);

 } catch (ResourceAccessException e) {

 attempt++;

 if (attempt >= maxRetries) {

 throw new RuntimeException(

 "Failed after " + maxRetries + " attempts", e);

 }

 long delay = initialDelay * (long) Math.pow(2, attempt - 1);

 try {

 Thread.sleep(delay);

 } catch (InterruptedException ie) {

 Thread.currentThread().interrupt();

 throw new RuntimeException("Retry interrupted", ie);

 }

 }

 }

 throw new RuntimeException("Unexpected error in retry logic");

 }



 public void setMaxRetries(int maxRetries) {

 this.maxRetries = maxRetries;

 }



 public void setInitialDelay(long initialDelay) {

 this.initialDelay = initialDelay;

 }

 }

指數退避演算法會在每次請求失敗後動態地將延遲時間加倍，從 1 秒開始，然後是 2 秒、4 秒、8 秒，依此類推。透過逐步增加等待時間，可以減輕遠端服務的重試壓力，使其有時間在下一次請求之前恢復。

3.4. 使用指數退避進行重試測試

為了驗證指數退避邏輯是否正確運行，我們可以測量主機不可達時的總執行時間。以下測試確保重試次數會隨著延遲的增加而增加，最終才會失敗：

@Test

 void whenHostOffline_thenRetriesWithExponentialBackoff() {

 service.setMaxRetries(4);

 service.setInitialDelay(500);



 String offlineUrl = "http://localhost:9999/api/data";

 long startTime = System.currentTimeMillis();



 assertThrows(RuntimeException.class, () -> {

 service.makeRequestWithExponentialBackoff(offlineUrl);

 });



 long duration = System.currentTimeMillis() - startTime;

 assertTrue(duration >= 3500);

 }

此測試透過檢查總耗時來驗證指數退避延遲是否正確應用。由於每次重試的等待時間都會逐漸延長，因此耗時超過 3.5 秒證實了多次重試和遞增的等待間隔如預期發生。

4. 使用 Spring Retry

Spring Retry簡化了重試機制，無需手動編寫循環、計數器和延遲。我們無需編寫重試邏輯，即可聲明式地將重試行為應用於任何方法。這使得程式碼更簡潔、更容易維護，也更容易測試。在使用這些特性之前，我們需要在專案中進行一些簡單的設定。

4.1 新增依賴項並啟用重試

在使用它之前，我們需要在pom.xml中新增所需的依賴項（ spring-retry和spring-aspects ）：

<dependency>

 <groupId>org.springframework.retry</groupId>

 <artifactId>spring-retry</artifactId>

 <version>2.0.12</version>

 </dependency>

 <dependency>

 <groupId>org.springframework</groupId>

 <artifactId>spring-aspects</artifactId>

 <version>7.0.0</version>

 </dependency>

新增完依賴項後，下一步是在 Spring Boot 應用程式中啟用重試功能。我們使用@EnableRetry註解來實現這一點，該註解會告訴 Spring 攔截方法呼叫並自動套用重試規則。這將會加入到RestTemplateConfig類別中的現有配置中：

@EnableRetry

 public class RestTemplateConfig {

 ....

 ....

 }

這種設定消除了手動重試循環的需要，使重試邏輯更清晰、更具聲明性，並且更容易在大型應用程式中維護。

4.2. 使用註解的聲明式重試

啟用重試支援後，我們現在可以使用@Retryable註解來標記特定方法，以便在發生某些異常時自動重試。這種方法非常適合服務調用，因為瞬態網路問題或主機不可用可能會導致間歇性故障：

@Service

 public class RestClientService {



 private final RestTemplate restTemplate;



 public RestClientService(RestTemplate restTemplate) {

 this.restTemplate = restTemplate;

 }



 @Retryable(

 retryFor = {ResourceAccessException.class},

 maxAttempts = 3,

 backoff = @Backoff(delay = 2000))

 public String fetchData(String url) {

 return restTemplate.getForObject(url, String.class);

 }



 @Recover

 public String recover(ResourceAccessException e, String url) {

 return "Fallback response after all retries failed for: " + url;

 }

 }

這種聲明式重試方法顯著簡化了程式碼，無需自訂重試循環或執行緒休眠。它對依賴外部系統的微服務或 API 非常有利，因為這些系統經常會出現臨時故障。

4.3. 測試 Spring Retry

@Retryable邏輯配置完成後，重要的是要確認它在實際網路問題發生時是否如預期運作。這裡，我們將模擬主機離線的情況，並驗證我們的服務在回退到恢復方法之前是否會重試配置的次數：

@SpringBootTest

 class RestClientServiceTest {



 @Autowired

 private RestClientService restClientService;



 @Test

 void whenHostOffline_thenRetriesAndRecovers() {

 String offlineUrl = "http://localhost:9999/api/data";



 String result = restClientService.fetchData(offlineUrl);



 assertTrue(result.contains("Fallback response"));

 assertTrue(result.contains(offlineUrl));

 }

 }

此測試驗證當主機離線時，服務會依照配置進行重試，並最終呼叫復原方法，傳回回退回應。

4.4 程序化配置

雖然像@Retryable這樣的註解很方便，但有些情況下需要更精細的控制，尤其是在不同元件需要不同的重試策略或需要動態調整重試設定時。在這種情況下，我們可以使用RetryTemplate以程式方式配置重試行為：

@Configuration

 public class RetryTemplateConfig {



 @Bean

 public RetryTemplate retryTemplate() {

 RetryTemplate retryTemplate = new RetryTemplate();



 FixedBackOffPolicy backOffPolicy = new FixedBackOffPolicy();

 backOffPolicy.setBackOffPeriod(2000);



 SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy();

 retryPolicy.setMaxAttempts(3);



 retryTemplate.setBackOffPolicy(backOffPolicy);

 retryTemplate.setRetryPolicy(retryPolicy);



 return retryTemplate;

 }

 }

這種顯式配置使我們能夠將重試邏輯集中在一個地方，並在多個服務中重複使用。接下來，我們可以將RestTemplate和上述RetryTemplate注入到RetryTemplateService服務類別中，以便優雅地處理瞬態故障：

@Service

 public class RetryTemplateService {



 private RestTemplate restTemplate;

 private RetryTemplate retryTemplate;



 public RetryTemplateService(RestTemplate restTemplate, RetryTemplate retryTemplate) {

 this.restTemplate = restTemplate;

 this.retryTemplate = retryTemplate;

 }



 public String fetchDataWithRetryTemplate(String url) {

 return retryTemplate.execute(context -> {

 return restTemplate.getForObject(url, String.class);

 }, context -> {

 return "Fallback response";

 });

 }

 }

這種方法比註解更靈活，因此非常適合需要在運行時動態建置或有條件地應用重試邏輯的情況。例如，我們可以根據 API 類型或環境配置調整重試次數或延遲時間。

4.5. 測試程序化配置

現在，讓我們測試一下我們的RetryTemplate配置是否真的能夠執行重試，並在目標服務不可用時觸發回退邏輯：

@Test

 void whenHostOffline_thenReturnsFallback() {

 String offlineUrl = "http://localhost:9999/api/data";



 long startTime = System.currentTimeMillis();

 String result = retryTemplateService.fetchDataWithRetryTemplate(offlineUrl);

 long duration = System.currentTimeMillis() - startTime;



 assertEquals("Fallback response", result);

 assertTrue(duration >= 4000);

 }

在此測試中，離線 URL 確保所有重試嘗試都會失敗，強制RetryTemplate在呼叫回退區塊之前完成所有三個配置的重試。

5. 結論

本文探討了主機離線時重試RestTemplate HTTP 請求的多種方法。我們研究了採用固定退避和指數退避策略的手動重試實現，以及使用 Spring Retry 的聲明式重試。

每種方法都有其優點，例如手動實作可以提供最大的控制權，而 Spring Retry 則提供了簡潔易用的優勢。具體選擇取決於應用程式的具體需求和複雜程度。

正確實現的重試邏輯能夠顯著提升分散式系統中應用程式的彈性。結合適當的超時和回退機制，這些模式有助於建立健壯的應用程序，使其能夠優雅地應對臨時網路故障和服務不可用情況。與往常一樣，這些範例的程式碼已發佈在 GitHub 上。

本作品係原創或者翻譯，採用《署名-非商業性使用-禁止演繹4.0國際》許可協議