Java 中當主機離線時重試 RestTemplate HTTP 請求

1. 概述

當 HTTP 請求由於主機臨時離線或不可達而失敗時，嘗試重新發送請求比立即失敗更可靠。這種被稱為 重試機制 的技術，有助於提高應用程序的彈性與可靠性，尤其是在處理不穩定網絡或遠程服務時。

在 Java 中，Spring Framework 的 <a href="https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html">RestTemplate</a> 是進行 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 測試同時檢查了異常處理和預期的延遲：

// 驗證重試機制在主機離線時是否觸發多次嘗試
public class RetryLogicTest {

    @Test
    public void testRetryMechanismOffline() {
        // ... 你的測試代碼 ...
    }
}

@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 指數退避策略

對於生產系統，指數退避通常更可取，因為它能降低故障服務的負載。在實際系統中，使用固定重試延遲有時會給其他服務帶來不必要的壓力。更好的方法是使用指數退避，即每次失敗後等待時間增加。

這使得系統能夠更優雅地恢復，並避免使目標服務不堪重負：

@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;
    }
}

採用指數退避策略時，每次嘗試失敗後延遲會動態加倍，初始為一秒，然後為兩秒、四秒、八秒，以此類推。通過逐步增加等待時間，可以減輕對遠程服務的重試壓力，使其有時間在下一次請求之前恢復。

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. 使用註解進行聲明式重試

啓用重試支持後，我們可以使用  註解來標記特定方法，以便在某些異常發生時自動重試。這種方法非常適合於在瞬時網絡問題或主機不可用時可能導致間歇性故障的服務調用：

@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 則提供簡單性和易用性。選擇取決於應用程序的特定要求和複雜性。

正確實施的重試邏輯可以顯著提高分佈式系統中的應用程序彈性。結合適當的超時時間和回退機制，這些模式有助於創建能夠優雅地處理臨時網絡故障和服務不可用性的健壯應用程序。

知識庫 / HTTP Client-Side RSS 訂閱