Spring Cloud Alibaba Sentinel: Boot 3 Integration, Rule Persistence, and Failure Boundaries

Baseline: Spring Boot 3, Spring Cloud 202x.x, the matching Spring Cloud Alibaba BOM, Sentinel 1.8.x, and Nacos 2.x. Versions must be combined according to the official compatibility matrix.

1. What Sentinel Solves

Sentinel provides flow control, circuit breaking and degradation, system protection, and hotspot parameter rate limiting for resources. It addresses service overload and failure propagation—not data consistency, message reliability, or business retries.

A typical call chain:

HTTP / RPC / 方法调用
  -> Sentinel 资源入口
  -> Slot 链
  -> 规则检查
  -> 放行或 BlockException

2. Spring Boot 3 Integration

Use the Spring Cloud Alibaba BOM to manage dependencies; do not mix and match starter versions manually. Boot 3 uses the Jakarta namespace, and dependencies for older Boot 2 releases must not be mixed in.

spring:
  application:
    name: order-service
  cloud:
    sentinel:
      enabled: true
      eager: false
      transport:
        dashboard: <SENTINEL_DASHBOARD_HOST>:8719
        port: 8719

Refer to the current starter's configuration metadata for the actual property names. Both the Dashboard port and the client heartbeat port should be accessible only within an internal or otherwise protected network.

3. Protecting Business Resources

@SentinelResource(
    value = "order.create",
    blockHandler = "blocked",
    fallback = "fallback")
public Order create(CreateOrderCommand command) {
    return service.create(command);
}

public Order blocked(CreateOrderCommand command, BlockException ex) {
    throw new TooManyRequestsException();
}

public Order fallback(CreateOrderCommand command, Throwable ex) {
    throw new ServiceUnavailableException(ex);
}

The blockHandler handles Sentinel rate-limiting or degradation exceptions, while fallback handles exceptions that occur during business execution. Do not turn every exception into a “rate limit” error, or you will mask the actual failure.

4. Rule Persistence

If rules exist only in the Dashboard's memory, they may be lost after the client restarts. In production, persist flow control, degradation, hotspot, and system rules in an external data source such as Nacos, and explicitly configure the namespace, group, dataId, authentication, and rollback strategy.

Rule changes require auditing, canary releases, and version control. The Dashboard is not, by itself, a complete configuration-management system for production.

5. Web and Feign Adapters

Resource naming and interceptors for Spring MVC, WebFlux, RestTemplate, and Feign are handled by their respective adapter modules. After enabling an adapter, verify that:

• URLs are normalized so that each ID does not create a separate resource;
• The HTTP method is included in the resource name;
• BlockException returns the correct status code;
• Feign retries and Sentinel fallback handling do not cause side effects to be executed more than once.

6. Production Boundaries

Pin all dependency and image versions; secure the Dashboard and Actuator; restrict permissions for rule changes; and monitor block counts, rejection counts, exception rates, RT, thread pools, and downstream connection pools. Sentinel cannot replace timeouts, connection-pool limits, idempotency, or business-level degradation.

When reading the source code, use the actual dependency version as the source of truth. The auto-configuration entry point may have migrated from spring.factories to AutoConfiguration.imports, so class names and initialization order should not be carried over unchanged across versions.