知識庫 / Spring / Spring Boot RSS 訂閱

@Test
public void testTimeLimiter() {
    EXTERNAL_SERVICE.stubFor(WireMock.get("/api/external").willReturn(ok()));
    ResponseEntity<String> response = restTemplate.getForEntity("/api/time-limiter", String.class);

    assertThat(response.getStatusCode()).isEqualTo(HttpStatus.REQUEST_TIMEOUT);
    EXTERNAL_SERVICE.verify(1, getRequestedFor(urlEqualTo("/api/external")));
}

正如預期的那樣，由於下游 API 調用設置為超過五秒完成，因此我們觀察到該 API 調用超時。

6. 隔板（Bulkhead）

隔板模式限制了對外部服務的併發最大調用次數。

我們首先添加帶有 /api/bulkhead API 端點以及 @Bulkhead 註解：

@GetMapping("/bulkhead")
@Bulkhead(name="bulkheadApi")
public String bulkheadApi() {
    return externalAPICaller.callApi();
}

接下來，我們將通過在 application.properties文件中定義配置來控制 bulkhead 功能：

resilience4j.bulkhead.metrics.enabled=true
resilience4j.bulkhead.instances.bulkheadApi.max-concurrent-calls=3
resilience4j.bulkhead.instances.bulkheadApi.max-wait-duration=1

通過此項，我們希望限制同時進行的調用數量為三個，因此每個線程最多等待 1ms，如果 bulkhead 已滿。之後，請求將被用 BulkheadFullException 異常拒絕。我們還將添加異常處理程序，以便返回有意義的 HTTP 狀態碼給客户端：

@ExceptionHandler({ BulkheadFullException.class })
@ResponseStatus(HttpStatus.BANDWIDTH_LIMIT_EXCEEDED)
public void handleBulkheadFullException() {
}

最後，我們將通過並行調用五個請求來測試 bulkhead 行為：

@Test
void testBulkhead() throws Exception {
  EXTERNAL_SERVICE.stubFor(WireMock.get("/api/external")
      .willReturn(ok()));
  Map<Integer, Integer> responseStatusCount = new ConcurrentHashMap<>();
  ExecutorService executorService = Executors.newFixedThreadPool(5);
  CountDownLatch latch = new CountDownLatch(5);

  IntStream.rangeClosed(1, 5)
      .forEach(i -> executorService.execute(() -> {
          ResponseEntity response = restTemplate.getForEntity("/api/bulkhead", String.class);
          int statusCode = response.getStatusCodeValue();
          responseStatusCount.merge(statusCode, 1, Integer::sum);
          latch.countDown();
      }));
  latch.await();
  executorService.shutdown();

  assertEquals(2, responseStatusCount.keySet().size());
  LOGGER.info("Response statuses: " + responseStatusCount.keySet());
  assertTrue(responseStatusCount.containsKey(BANDWIDTH_LIMIT_EXCEEDED.value()));
  assertTrue(responseStatusCount.containsKey(OK.value()));
  EXTERNAL_SERVICE.verify(3, getRequestedFor(urlEqualTo("/api/external")));
}

我們可以看到，只有三個請求成功，其餘請求則被拒絕，並返回 BANDWIDTH_LIMIT_EXCEEDED HTTP 狀態碼。

7. 速率限制器

速率限制器模式限制對資源的請求速率。

我們首先添加帶有 /api/rate-limiter API 端點和 @RateLimiter 註解：

@GetMapping("/rate-limiter")
@RateLimiter(name = "rateLimiterApi")
public String rateLimitApi() {
    return externalAPICaller.callApi();
}

接下來，我們將定義限速器在 application.properties文件中配置：

resilience4j.ratelimiter.metrics.enabled=true
resilience4j.ratelimiter.instances.rateLimiterApi.register-health-indicator=true
resilience4j.ratelimiter.instances.rateLimiterApi.limit-for-period=5
resilience4j.ratelimiter.instances.rateLimiterApi.limit-refresh-period=60s
resilience4j.ratelimiter.instances.rateLimiterApi.timeout-duration=0s
resilience4j.ratelimiter.instances.rateLimiterApi.allow-health-indicator-to-fail=true
resilience4j.ratelimiter.instances.rateLimiterApi.subscribe-for-events=true
resilience4j.ratelimiter.instances.rateLimiterApi.event-consumer-buffer-size=50

通過這種配置，我們希望限制API調用速率為每分鐘5個請求，且不進行等待。當達到允許的速率閾值後，請求將被拒絕，並拋出RequestNotPermitted異常。因此，我們將定義一個處理程序在ApiExceptionHandler類中，將其轉換為有意義的HTTP狀態響應代碼：

@ExceptionHandler({ RequestNotPermitted.class })
@ResponseStatus(HttpStatus.TOO_MANY_REQUESTS)
public void handleRequestNotPermitted() {
}

最後，我們將使用 50 個請求測試我們的限速 API 端點：

@Test
public void testRatelimiter() {
    EXTERNAL_SERVICE.stubFor(WireMock.get("/api/external")
      .willReturn(ok()));
    Map<Integer, Integer> responseStatusCount = new ConcurrentHashMap<>();

    IntStream.rangeClosed(1, 50)
      .parallel()
      .forEach(i -> {
          ResponseEntity<String> response = restTemplate.getForEntity("/api/rate-limiter", String.class);
          int statusCode = response.getStatusCodeValue();
          responseStatusCount.put(statusCode, responseStatusCount.getOrDefault(statusCode, 0) + 1);
      });

    assertEquals(2, responseStatusCount.keySet().size());
    assertTrue(responseStatusCount.containsKey(TOO_MANY_REQUESTS.value()));
    assertTrue(responseStatusCount.containsKey(OK.value()));
    EXTERNAL_SERVICE.verify(5, getRequestedFor(urlEqualTo("/api/external")));
}

正如預期的那樣，僅有五個請求成功，而其餘所有請求均以 TOO_MANY_REQUESTS HTTP 狀態碼失敗。

8. Actuator 端點

我們配置了應用程序支持 Actuator 端點，用於監控目的。通過這些端點，我們可以利用一種或多種配置的容錯模式來確定應用程序隨時間的變化情況。

首先，我們可以通過向 /actuator 端點發送 GET 請求來查找所有暴露的端點：

http://localhost:8080/actuator/
{
    "_links" : {
        "self" : {...},
        "bulkheads" : {...},
        "circuitbreakers" : {...},
        "ratelimiters" : {...},
        ...
    }
}

我們能看到一個包含諸如 隔板、斷路器、請求限制器 等字段的 JSON 響應。每個字段都提供特定信息，具體取決於其與容錯模式的關聯。

接下來，我們將查看與重試模式相關的字段：

"retries": {
  "href": "http://localhost:8080/actuator/retries",
  "templated": false
},
"retryevents": {
  "href": "http://localhost:8080/actuator/retryevents",
  "templated": false
},
"retryevents-name": {
  "href": "http://localhost:8080/actuator/retryevents/{name}",
  "templated": true
},
"retryevents-name-eventType": {
  "href": "http://localhost:8080/actuator/retryevents/{name}/{eventType}",
  "templated": true
}

接下來，我們可以檢查應用程序以查看重試實例的列表：

http://localhost:8080/actuator/retries
{
    "retries" : [ "retryApi" ]
}

正如預期的那樣，我們可以看到 retryApi 實例在配置的重試實例列表中。

最後，我們將通過瀏覽器向 /api/retry API 端點發出 GET 請求，並通過 /actuator/retryevents 端點觀察重試事件：

{
    "retryEvents": [
    {
        "retryName": "retryApi",
        "type": "RETRY",
        "creationTime": "2022-10-16T10:46:31.950822+05:30[Asia/Kolkata]",
        "errorMessage": "...",
        "numberOfAttempts": 1
    },
    {
        "retryName": "retryApi",
        "type": "RETRY",
        "creationTime": "2022-10-16T10:46:32.965661+05:30[Asia/Kolkata]",
        "errorMessage": "...",
        "numberOfAttempts": 2
    },
    {
        "retryName": "retryApi",
        "type": "ERROR",
        "creationTime": "2022-10-16T10:46:33.978801+05:30[Asia/Kolkata]",
        "errorMessage": "...",
        "numberOfAttempts": 3
    }
  ]
}

由於下游服務不可用，我們可以看到三次重試嘗試，每次嘗試之間間隔時間為 1s。 就像我們配置的那樣。

9. 結論

在本文中，我們學習瞭如何在 Sprint Boot 應用程序中使用 Resilience4j 庫。此外，我們重點關注了多種容錯模式，例如斷路器、速率限制器、時間限制器、隔離艙和重試。