Resilience4j熔断器配置与状态机解析

微服务架构中，服务间调用的稳定性直接决定了整个系统的可用性。当某个下游服务出现故障时，如果不做熔断处理，调用方线程池会被阻塞请求占满，进而导致级联故障。Resilience4j是目前Spring Boot生态中替代Hystrix的主流熔断框架，它基于状态机模型实现熔断逻辑。

Spring Boot 3项目中引入Resilience4j：

<dependency>
  <groupId>io.github.resilience4j</groupId>
  <artifactId>resilience4j-spring-boot3</artifactId>
  <version>2.2.0</version>
</dependency>

application.yml中配置熔断器：

resilience4j:
  circuitbreaker:
    instances:
      orderService:
        sliding-window-type: COUNT_BASED
        sliding-window-size: 10
        failure-rate-threshold: 50
        slow-call-rate-threshold: 80
        slow-call-duration-threshold: 3s
        wait-duration-in-open-state: 30s
        permitted-number-of-calls-in-half-open-state: 3
        minimum-number-of-calls: 5
        automatic-transition-from-open-to-half-open-enabled: true

核心参数解读：sliding-window-size=10表示基于最近10次调用计算失败率；failure-rate-threshold=50表示失败率超过50%触发熔断；wait-duration-in-open-state=30s表示熔断开启后等待30秒进入半开状态；permitted-number-of-calls-in-half-open-state=3表示半开状态允许3次探测请求。状态转换流程为 Closed到Open到Half-Open到Closed/Open，其中Half-Open状态是判断下游是否恢复的关键窗口。

熔断降级与Fallback实现

配置好熔断器后，在业务代码中使用注解方式接入：

@Service
public class OrderService {

    @CircuitBreaker(name = "orderService", fallbackMethod = "getOrderFallback")
    @TimeLimiter(name = "orderService")
    public CompletableFuture<Order> getOrder(Long orderId) {
        return CompletableFuture.supplyAsync(() -> {
            return orderClient.fetchOrder(orderId);
        });
    }

    private CompletableFuture<Order> getOrderFallback(Long orderId, Exception e) {
        Order cached = cacheService.getCachedOrder(orderId);
        if (cached != null) {
            return CompletableFuture.completedFuture(cached);
        }
        Order fallback = new Order();
        fallback.setId(orderId);
        fallback.setStatus("SERVICE_UNAVAILABLE");
        return CompletableFuture.completedFuture(fallback);
    }
}

Fallback方法签名必须与原方法参数一致，并追加一个Throwable参数接收异常信息。降级策略根据业务场景选择：核心链路返回缓存数据保证基本可用，非核心链路直接返回空或默认值。不要在Fallback中再次调用可能熔断的服务，否则会产生递归调用。

分布式事务补偿机制设计

微服务拆分后，跨服务的数据一致性是后端开发中最复杂的难题。XA两阶段提交在跨服务场景下性能差且容易死锁，实际生产中更多采用补偿事务（Saga模式）。以订单创建流程为例，涉及订单服务创建订单、库存服务扣减库存、支付服务预授权三个步骤，任何一步失败都需要回滚已完成的前置操作。

补偿事务的核心设计：

@Service
public class OrderSaga {

    @Transactional
    public SagaDefinition<OrderState> createOrderSaga() {
        return step()
            .invokeParticipant(this::createOrder)
            .withCompensation(this::cancelOrder)
        .step()
            .invokeParticipant(this::reserveInventory)
            .withCompensation(this::releaseInventory)
        .step()
            .invokeParticipant(this::preAuthPayment)
            .withCompensation(this::cancelPayment)
        .build();
    }

    private void cancelOrder(OrderState state) {
        orderRepository.updateStatus(
            state.getOrderId(), "CANCELLED"
        );
        eventPublisher.publish(new OrderCancelledEvent(state.getOrderId()));
    }

    private void releaseInventory(OrderState state) {
        inventoryClient.release(
            state.getProductId(),
            state.getQuantity()
        );
    }
}

每个步骤定义正向操作和补偿操作。当第N步失败时，框架按N-1、N-2的顺序逆序执行补偿。补偿操作必须是幂等的——网络超时可能导致补偿指令重复执行，非幂等操作会造成数据不一致。实现幂等的简单方式是在数据库中记录补偿执行状态，执行前先查询是否已补偿过。

消息中间件实现最终一致性

补偿事务的协调指令通过消息中间件传递更为可靠。RocketMQ事务消息是Java后端常用的方案：

@Service
public class TransactionMessageProducer {

    @Autowired
    private RocketMQTemplate rocketMQTemplate;

    public void sendOrderCreatedEvent(Order order) {
        Message<String> message = MessageBuilder
            .withPayload(JSON.toJSONString(order))
            .setHeader("KEY", order.getId().toString())
            .build();

        rocketMQTemplate.sendMessageInTransaction(
            "order-created-topic",
            message,
            order
        );
    }

    @RocketMQTransactionListener
    class OrderTransactionListener implements RocketMQLocalTransactionListener {

        @Override
        public RocketMQLocalTransactionState executeLocalTransaction(
            Message msg, Object arg) {
            try {
                orderService.processOrder((Order) arg);
                return RocketMQLocalTransactionState.COMMIT;
            } catch (Exception e) {
                return RocketMQLocalTransactionState.ROLLBACK;
            }
        }

        @Override
        public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
            String orderId = (String) msg.getHeaders().get("KEY");
            Order order = orderRepository.findById(orderId);
            if (order != null && order.isProcessed()) {
                return RocketMQLocalTransactionState.COMMIT;
            }
            return RocketMQLocalTransactionState.ROLLBACK;
        }
    }
}

事务消息保证本地事务与消息发送的原子性：本地事务成功则消息必定投递，失败则消息不会投递。如果本地事务执行后未返回明确状态，Broker会定期回查checkLocalTransaction确认。这种机制比定时任务轮询更高效，也比直接双写（先DB再MQ）更可靠，因为消除了DB成功但MQ发送失败的数据不一致窗口。

熔断与补偿的协同策略

在实际微服务系统中，熔断和补偿需要协同工作。当补偿操作调用的服务也被熔断时，不能简单跳过。推荐的做法是：补偿操作独立配置熔断器，阈值更宽松（failure-rate-threshold设为80%），因为补偿是最后手段，应该尽可能执行成功；补偿失败时写入死信队列，由人工或定时任务异步重试。这种分层容错策略在高并发微服务架构中经过验证，能有效将级联故障的爆炸半径控制在单服务范围内。