Spring Cloud断路器Resilience4j配置

resilience4j比hystrix更优的原因在于其轻量级设计、反应式友好、模块化结构及持续活跃的社区维护。1. resilience4j默认使用信号量隔离，避免线程池管理开销，更适合高并发和反应式框架；2. 提供断路器、限流器、舱壁、重试、超时等多种独立策略，配置灵活；3. 与micrometer、prometheus等集成实现强大监控能力；4. 社区活跃，持续更新适配现代云原生架构，而hystrix已停止更新。

Spring Cloud中，Resilience4j作为断路器组件，其配置核心在于定义各种容错策略的实例，如断路器本身、舱壁、限流器、重试和超时，通常通过application.yml或Java代码进行，并无缝集成到Spring Cloud Gateway或OpenFeign等组件中。

解决方案

配置Resilience4j首先需要引入相应的Spring Cloud Starter依赖。对于核心的断路器功能，通常是spring-cloud-starter-circuitbreaker-resilience4j。

在application.yml中，你可以定义多个断路器实例的配置，或者一个默认配置：

spring:
  cloud:
    circuitbreaker:
      resilience4j:
        circuitbreaker:
          configs:
            default: # 默认配置，所有未指定名称的断路器都将使用此配置
              failureRateThreshold: 50 # 故障率阈值，达到此值断路器将打开
              waitDurationInOpenState: 5s # 断路器打开状态持续时间
              slidingWindowType: COUNT_BASED # 滑动窗口类型：基于计数或基于时间
              slidingWindowSize: 100 # 滑动窗口大小，用于计算故障率
              minimumNumberOfCalls: 20 # 在计算故障率前，至少需要多少次调用
              permittedNumberOfCallsInHalfOpenState: 10 # 半开状态下允许的调用次数
              automaticTransitionFromOpenToHalfOpenEnabled: true # 是否自动从打开状态转换为半开状态
            myServiceCircuitBreaker: # 特定服务的断路器配置
              failureRateThreshold: 60
              waitDurationInOpenState: 10s
              slidingWindowType: TIME_BASED
              slidingWindowSize: 60s # 60秒内的调用
              minimumNumberOfCalls: 10
          instances:
            myService: # 引用上面定义的myServiceCircuitBreaker配置
              baseConfig: myServiceCircuitBreaker
            anotherService: # 使用默认配置
              baseConfig: default
        timelimiter:
          configs:
            default:
              timeoutDuration: 2s # 默认超时时间
          instances:
            myService:
              baseConfig: default
        retry:
          configs:
            default:
              maxAttempts: 3 # 默认重试次数
              waitDuration: 1s # 每次重试的等待时间
              retryExceptions:
                - java.io.IOException
          instances:
            myService:
              baseConfig: default
        ratelimiter:
          configs:
            default:
              limitForPeriod: 10 # 每个时间周期内允许的最大请求数
              limitRefreshPeriod: 1s # 刷新时间周期
              timeoutDuration: 0s # 获取许可的等待时间，0s表示不等待
          instances:
            myService:
              baseConfig: default
        bulkhead:
          configs:
            default:
              maxConcurrentCalls: 10 # 最大并发调用数
              maxWaitDuration: 0s # 获取许可的最大等待时间
          instances:
            myService:
              baseConfig: default

在代码中，你可以通过@CircuitBreaker、@Retry、@RateLimiter、@TimeLimiter、@Bulkhead等注解将这些策略应用到方法上，并指定name属性来引用配置的实例名。同时，别忘了提供一个fallbackMethod来处理降级逻辑。

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.stereotype.Service;

@Service
public class MyBackendService {

    @CircuitBreaker(name = "myService", fallbackMethod = "fallbackForMyService")
    public String callExternalService() {
        // 模拟外部服务调用
        if (Math.random() > 0.7) {
            throw new RuntimeException("External service failed!");
        }
        return "Success from external service!";
    }

    public String fallbackForMyService(Throwable t) {
        System.out.println("Fallback triggered: " + t.getMessage());
        return "Fallback response due to service failure.";
    }
}

为什么选择Resilience4j？它比Hystrix好在哪里？

这是一个非常实际的问题，尤其对于那些从老项目迁移或在选型时犹豫不决的开发者而言。坦白说，Hystrix在它的时代确实是断路器领域的标杆，但技术总在进步，Resilience4j的出现，更像是为现代微服务架构量身定制的升级版。

我个人认为，Resilience4j最大的优势在于它的“轻量级”和“反应式友好”。Hystrix默认采用线程池隔离，虽然隔离性好，但引入了额外的线程管理开销和上下文切换成本，在高并发场景下，这可能成为性能瓶颈。而Resilience4j则不然，它默认采用信号量隔离（或称作计数器隔离），不强制创建新的线程池，这使得它与Netty、Reactor等反应式编程框架结合得天衣无缝，资源消耗更小，响应速度更快。

此外，Resilience4j提供了更细粒度的状态控制和事件发布。它不仅仅是一个断路器，更是一个全面的容错库，包含了断路器（CircuitBreaker）、限流器（RateLimiter）、舱壁（Bulkhead）、重试（Retry）和超时（TimeLimiter）等多种策略，每种策略都可以独立配置和使用。Hystrix虽然也有类似概念，但集成度不如Resilience4j这样清晰和模块化。

从维护和社区活跃度来看，Hystrix已经进入维护模式，而Resilience4j则持续活跃发展，不断有新的特性和改进。这意味着，选择Resilience4j，你是在投资一个更具未来潜力的技术栈。当然，Hystrix的Dashboard和Turbine在监控方面确实做得很好，但Resilience4j通过与Micrometer、Prometheus、Grafana的集成，也能提供同样强大甚至更灵活的监控能力。

总的来说，Resilience4j更符合现代云原生和反应式编程的趋势，它在性能、灵活性和模块化方面都超越了Hystrix，是构建健壮微服务系统的更优选择。

Resilience4j核心配置项解析与实践

Resilience4j的强大之处在于其丰富的配置项，它们允许你根据服务的特性和风险承受能力，精细地调整容错行为。理解并恰当地运用这些参数，是构建稳定系统的关键。

我们来深入看看几个核心配置：

断路器（CircuitBreaker）相关：

• failureRateThreshold：这是断路器最核心的参数之一。它定义了在滑动窗口内，当失败请求的百分比达到这个阈值时，断路器就会从CLOSED（关闭）状态转换为OPEN（打开）状态。比如，设置为50，意味着如果一半的请求都失败了，就该考虑断开了。
• waitDurationInOpenState：断路器进入OPEN状态后，会保持这个状态多长时间。这段时间内，所有请求都会直接被拒绝，不会尝试调用后端服务。这给服务一个喘息之机，避免雪崩效应。时间到了，它会自动进入HALF_OPEN（半开）状态。
• slidingWindowType 和 slidingWindowSize：
  • COUNT_BASED：基于调用次数的滑动窗口。slidingWindowSize表示在计算故障率时，会统计最近多少次调用。比如100次，就是看最近100次调用里有多少失败的。
  • TIME_BASED：基于时间的滑动窗口。slidingWindowSize表示在计算故障率时，会统计最近多少秒内的调用。比如60秒，就是看最近60秒内有多少失败的。 选择哪种类型取决于你的业务场景，对于请求量波动大的服务，基于时间可能更稳定。
• minimumNumberOfCalls：这是一个非常重要的参数，它决定了在滑动窗口内，至少需要多少次调用，断路器才开始计算故障率并决定是否打开。这避免了在请求量很小的时候，偶尔一两次失败就误判服务不可用。
• permittedNumberOfCallsInHalfOpenState：当断路器从OPEN状态转换为HALF_OPEN状态时，允许多少次请求通过去尝试后端服务。这些“试探性”的请求如果成功，断路器会回到CLOSED状态；如果失败，则会再次回到OPEN状态。
• automaticTransitionFromOpenToHalfOpenEnabled：如果设置为true，断路器在waitDurationInOpenState时间结束后，会自动从OPEN转为HALF_OPEN。这通常是推荐的做法，简化了管理。

舱壁（Bulkhead）相关：

• maxConcurrentCalls：定义了后端服务允许的最大并发调用数。这就像给服务设置了一个“入口闸门”，超过这个数量的请求就会被排队或拒绝，防止服务被过载。
• maxWaitDuration：当并发调用数达到maxConcurrentCalls时，后续请求会进入等待队列。maxWaitDuration定义了请求在队列中等待的最大时间。如果等待超时，请求就会被拒绝。

限流器（RateLimiter）相关：

• limitForPeriod：在limitRefreshPeriod这个时间周期内，允许通过的最大请求数。
• limitRefreshPeriod：限流器刷新许可的时间周期。比如，limitForPeriod: 10和limitRefreshPeriod: 1s意味着每秒最多允许10个请求。
• timeoutDuration：当请求无法立即获得许可时，等待许可的最长时间。设置为0s通常表示不等待，立即拒绝。

重试（Retry）相关：

• maxAttempts：最大重试次数。
• waitDuration：每次重试之间等待的时间。
• retryExceptions/ignoreExceptions：可以指定哪些异常触发重试，哪些异常不触发重试。

这些参数组合起来，就像在给服务的心脏设置一个精密的节拍器和保护网。你需要根据服务的SLA、后端服务的稳定性、请求量模式等因素来调整它们。例如，对于一个对实时性要求不高但稳定性要求极高的服务，你可能会设置更长的waitDurationInOpenState和更低的failureRateThreshold；而对于一个瞬时流量巨大的服务，ratelimiter和bulkhead的配置就显得尤为重要。

天工大模型

中国首个对标ChatGPT的双千亿级大语言模型

下载

如何在Spring Cloud应用中集成Resilience4j？

将Resilience4j融入Spring Cloud应用，通常有几种主流方式，每种方式都有其适用场景，理解它们能帮助你更灵活地构建容错系统。

首先，确保你的pom.xml中包含了必要的依赖。对于Spring Cloud应用，最直接的就是：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-circuitbreaker-resilience4j</artifactId>
</dependency>
<!-- 如果你使用Spring Cloud Gateway -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!-- 如果你使用OpenFeign -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

1. 基于注解的方式（推荐用于业务服务层）：

这是最直观和常用的方式。你可以在需要容错的方法上直接添加Resilience4j提供的注解，如@CircuitBreaker、@Retry、@RateLimiter、@TimeLimiter、@Bulkhead。

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import io.github.resilience4j.retry.annotation.Retry;
import io.github.resilience4j.ratelimiter.annotation.RateLimiter;
import io.github.resilience4j.timelimiter.annotation.TimeLimiter;
import io.github.resilience4j.bulkhead.annotation.Bulkhead;
import org.springframework.stereotype.Service;

@Service
public class ProductService {

    // 使用断路器和重试
    @CircuitBreaker(name = "productService", fallbackMethod = "getProductFallback")
    @Retry(name = "productService")
    public String getProductDetails(String productId) {
        // 模拟调用外部库存服务
        if (Math.random() < 0.3) {
            throw new RuntimeException("Inventory service temporarily unavailable.");
        }
        return "Product " + productId + " details.";
    }

    // 使用限流器和舱壁
    @RateLimiter(name = "orderRateLimiter", fallbackMethod = "createOrderFallback")
    @Bulkhead(name = "orderBulkhead", type = Bulkhead.Type.SEMAPHORE, fallbackMethod = "createOrderFallback")
    public String createOrder(String userId, String productId) {
        // 模拟创建订单的复杂操作
        try {
            Thread.sleep(100); // 模拟耗时操作
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return "Order created for " + userId + " product " + productId;
    }

    // 超时控制
    @TimeLimiter(name = "longRunningTask", fallbackMethod = "longRunningTaskFallback")
    public CompletableFuture<String> performLongRunningTask() {
        return CompletableFuture.supplyAsync(() -> {
            try {
                Thread.sleep(3000); // 模拟一个耗时3秒的任务
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            return "Long task completed.";
        });
    }

    public String getProductFallback(String productId, Throwable t) {
        System.err.println("Fallback for getProductDetails. Reason: " + t.getMessage());
        return "Default product details due to failure.";
    }

    public String createOrderFallback(String userId, String productId, Throwable t) {
        System.err.println("Fallback for createOrder. Reason: " + t.getMessage());
        return "Order creation failed, please try again later.";
    }

    public CompletableFuture<String> longRunningTaskFallback(Throwable t) {
        System.err.println("Fallback for longRunningTask. Reason: " + t.getMessage());
        return CompletableFuture.completedFuture("Long task timed out.");
    }
}

注意，@TimeLimiter通常与CompletableFuture结合使用，因为它需要一个异步返回类型。

2. Spring Cloud Gateway集成：

对于API网关层，Resilience4j可以作为路由过滤器使用，为所有经过该路由的请求提供断路器保护。这在网关层面就能有效阻止故障向上游扩散。

在application.yml中配置Gateway路由：

spring:
  cloud:
    gateway:
      routes:
        - id: my_service_route
          uri: lb://MY-SERVICE # 假设你的服务注册在Eureka中，服务名为MY-SERVICE
          predicates:
            - Path=/my-service/**
          filters:
            - name: CircuitBreaker # 使用Resilience4j断路器过滤器
              args:
                name: myService # 引用你在circuitbreaker.instances中定义的实例名
                fallbackUri: forward:/fallback # 当断路器打开时，请求转发到这个URI

在你的应用中，你需要有一个/fallback的Controller来处理降级逻辑：

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class FallbackController {

    @RequestMapping("/fallback")
    public String fallback() {
        return "Service is currently unavailable. Please try again later.";
    }
}

3. Spring Cloud OpenFeign集成：

如果你使用OpenFeign进行服务间调用，Resilience4j可以无缝地集成进来，为Feign客户端的每次调用提供容错能力。

首先，确保application.yml中启用了Feign的断路器：

feign:
  circuitbreaker:
    enabled: true # 启用Feign的断路器功能

然后，在你的Feign客户端接口上定义fallback或fallbackFactory：

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;

@FeignClient(name = "user-service", fallback = UserServiceFallback.class) // 指定fallback类
public interface UserServiceFeignClient {

    @GetMapping("/users/{id}")
    String getUserById(Long id);
}

@Component
class UserServiceFallback implements UserServiceFeignClient {
    @Override
    public String getUserById(Long id) {
        System.err.println("Fallback for getUserById: User service is down or circuit is open.");
        return "Default User for ID: " + id; // 提供降级数据
    }
}

如果你需要根据不同的异常提供不同的降级逻辑，可以使用fallbackFactory，它能让你访问到触发降级的Throwable对象。

一些常见的挑战和注意事项：

• 配置名称匹配： 确保你在代码中（如@CircuitBreaker(name = "myService")）引用的名称与application.yml中instances下定义的名称完全匹配。
• Fallback方法签名： fallbackMethod的签名必须与原方法一致，或者在参数列表末尾多一个Throwable参数。
• 异步调用与@TimeLimiter： TimeLimiter通常用于异步方法，因为它是非阻塞的。如果你的方法是同步的，并希望控制执行时间，你可能需要手动包装成CompletableFuture。
• 监控是关键： 仅仅配置断路器是不够的。结合Spring Boot Actuator、Micrometer、Prometheus和Grafana，你可以实时监控断路器的状态、调用成功率、失败率等指标，这对于发现问题、调整配置至关重要。

集成Resilience4j并不复杂，关键在于理解其核心机制和配置参数，并根据你的应用场景选择合适的集成方式。通过合理的容错策略，你的微服务系统将变得更加健壮和可靠。