如何在Spring Cloud Gateway 2中针对IOExceptions配置重试？

Hey, great question! The good news is yes—you absolutely can configure the Retry GatewayFilter in Spring Cloud Gateway 2 to retry on IO exceptions like connection resets. Let me walk you through how to set this up:

1. Know the Defaults First #

The Retry filter handles some retry scenarios out of the box, but it doesn't explicitly target all IO exceptions by default. To get it to trigger retries for connection resets and similar issues, you'll need to explicitly list the exception types you want to act on.

2. Configuration via YAML #

You can set this up directly in your gateway's application.yml file. Here's an example:

spring:
  cloud:
    gateway:
      routes:
        - id: example_route
          uri: http://your-target-service
          predicates:
            - Path=/api/**
          filters:
            - name: Retry
              args:
                retries: 3
                statuses: BAD_GATEWAY, SERVICE_UNAVAILABLE
                exceptions: java.net.SocketException, java.net.ConnectException

In this config, we're adding SocketException (which covers connection reset errors) and ConnectException to the list of exceptions that trigger a retry. We also keep the HTTP status codes you might already care about, like BAD_GATEWAY and SERVICE_UNAVAILABLE.

3. Configuration via Java Code #

If you prefer using Java-based configuration, you can build the Retry filter programmatically:

import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.cloud.gateway.filter.factory.RetryGatewayFilterFactory;
import java.net.ConnectException;
import java.net.SocketException;
import org.springframework.http.HttpStatus;

@Configuration
public class GatewayRetryConfig {

    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
        RetryGatewayFilterFactory.Config retryConfig = new RetryGatewayFilterFactory.Config();
        
        // Set number of retry attempts
        retryConfig.setRetries(3);
        
        // Add HTTP status codes to trigger retry
        retryConfig.addStatuses(HttpStatus.BAD_GATEWAY, HttpStatus.SERVICE_UNAVAILABLE);
        
        // Add IO exceptions to trigger retry
        retryConfig.addExceptions(SocketException.class, ConnectException.class);

        return builder.routes()
                .route("example_route", r -> r.path("/api/**")
                        .filters(f -> f.retry(retryConfig))
                        .uri("http://your-target-service"))
                .build();
    }
}

This code achieves the same result as the YAML setup: it tells the retry filter to retry requests when either the specified HTTP status codes are returned, or when a connection reset (SocketException) or connection failure (ConnectException) occurs.

Quick Tips #

• Target the right exceptions: Connection resets usually throw java.net.SocketException (often with the message "Connection reset by peer"), so including this class will cover those cases. You can add java.io.IOException if you want a broader catch for other IO-related errors.
• Tune retry counts: Don't set the retries value too high—you don't want to flood your target service with repeated requests if it's already having issues.
• Combine with other filters: You can pair this with other resilience filters (like CircuitBreaker) for even better service resilience.

内容的提问来源于stack exchange，提问作者Arkin