跳至主要內容

微服务治理全景：熔断、限流、降级、隔离

郑天祺2026/6/27大约 13 分钟分布式微服务SentinelResilience4j分布式高可用

微服务治理全景：熔断、限流、降级、隔离

微服务治理全景：熔断、限流、降级、隔离是分布式系统中的核心话题，它涉及数据一致性、可用性和分区容错等关键挑战。
本文深入分析了微服务治理全景：熔断、限流、降级、隔离的原理和解决方案，帮助你构建可靠的分布式系统。

考虑一个典型的微服务调用链：

用户请求 → 网关 → 订单服务 → 库存服务 → 仓储服务

如果仓储服务突然变慢（比如数据库锁表）：

  1. 仓储服务的线程池被占满，响应变慢
  2. 库存服务调用仓储服务的请求超时，线程堆积
  3. 库存服务的线程池也被占满
  4. 订单服务调用库存服务也超时
  5. 最终整个调用链全部瘫痪

这就是雪崩效应——一个节点的故障逐级放大，拖垮整个系统。

1.2 四大治理手段

手段作用类比
熔断快速失败，不再调用故障服务电路保险丝，过载自动断开
限流控制请求速率，防止过载高速公路收费站限流
降级返回兜底响应，保证核心功能餐厅没菜了推荐替代品
隔离资源隔离，故障不扩散船舱隔板，一个进水不沉船

二、熔断（Circuit Breaker）

2.1 熔断器状态机

         失败率达到阈值
  Closed ──────────────→ Open
  (正常)                  (熔断)
    ↑                       │
    │ 半开探测成功           │ 等待超时
    │                       ↓
    └────── Half-Open ←─────┘
             (半开)
  • Closed（关闭）：正常放行请求，统计失败率
  • Open（打开）：直接拒绝请求，不调用下游
  • Half-Open（半开）：放行少量请求探测，成功则恢复，失败则继续熔断

2.2 Resilience4j 熔断实战

Resilience4j 是 Spring 官方推荐的熔断组件，取代了停止维护的 Hystrix。

Maven 依赖：

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot3</artifactId>
    <version>2.2.0</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

配置（application.yml）：

resilience4j:
  circuitbreaker:
    instances:
      inventoryService:
        registerHealthIndicator: true
        slidingWindowType: COUNT_BASED        # 滑动窗口类型：COUNT_BASED / TIME_BASED
        slidingWindowSize: 100                 # 窗口大小：最近 100 次请求
        minimumNumberOfCalls: 20               # 至少 20 次请求才开始计算
        failureRateThreshold: 50               # 失败率阈值：50%
        slowCallRateThreshold: 80              # 慢调用比例阈值：80%
        slowCallDurationThreshold: 3s          # 慢调用判定：超过 3s
        waitDurationInOpenState: 30s           # 熔断持续时间：30s
        permittedNumberOfCallsInHalfOpenState: 10  # 半开状态放行 10 个请求
        automaticTransitionFromOpenToHalfOpenEnabled: true  # 自动从 Open 到 Half-Open

代码使用：

@Service
public class OrderService {

    @CircuitBreaker(name = "inventoryService", fallbackMethod = "fallbackGetStock")
    public StockInfo getStock(String productId) {
        // 调用库存服务
        return inventoryClient.getStock(productId);
    }

    // 降级方法：签名要和原方法一致（多一个 Exception 参数）
    private StockInfo fallbackGetStock(String productId, Exception e) {
        // 返回缓存或默认值
        log.warn("库存服务熔断，返回缓存数据, productId={}", productId, e);
        return cacheManager.getStockFromCache(productId)
            .orElse(new StockInfo(productId, 0, "unknown"));
    }
}

2.3 Sentinel 熔断实战

Sentinel 是阿里开源的流量治理组件，功能比 Resilience4j 更丰富。

Maven 依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
    <version>2023.0.1.0</version>
</dependency>

配置：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080    # Sentinel 控制台地址
        port: 8719                    # 与控制台通信端口
      eager: true                     # 立即初始化

代码方式定义熔断规则：

@Configuration
public class SentinelRuleConfig {

    @PostConstruct
    public void initRules() {
        // 熔断规则：慢调用比例
        DegradeRule slowCallRule = new DegradeRule("getStock")
            .setGrade(CircuitBreakerStrategy.SLOW_REQUEST_RATIO.getType())
            .setCount(500)              // 慢调用阈值：500ms
            .setSlowRatioThreshold(0.8) // 慢调用比例阈值：80%
            .setMinRequestAmount(5)     // 最小请求数
            .setStatIntervalMs(10000)   // 统计窗口：10s
            .setTimeWindow(30);         // 熔断时长：30s

        // 熔断规则：异常比例
        DegradeRule exceptionRule = new DegradeRule("getStock")
            .setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType())
            .setCount(0.5)              // 异常比例阈值：50%
            .setMinRequestAmount(10)
            .setStatIntervalMs(10000)
            .setTimeWindow(30);

        DegradeRuleManager.loadRules(Arrays.asList(slowCallRule, exceptionRule));
    }
}

Sentinel 注解方式：

@Service
public class OrderService {

    @SentinelResource(value = "getStock", 
                       blockHandler = "blockHandler",
                       fallback = "fallbackHandler")
    public StockInfo getStock(String productId) {
        return inventoryClient.getStock(productId);
    }

    // 限流/熔断时调用
    public StockInfo blockHandler(String productId, BlockException ex) {
        return new StockInfo(productId, 0, "blocked");
    }

    // 业务异常时调用
    public StockInfo fallbackHandler(String productId, Throwable e) {
        return new StockInfo(productId, 0, "error");
    }
}

2.4 熔断策略对比

策略说明适用场景
异常比例异常数/总请求数 > 阈值下游服务报错
慢调用比例慢调用数/总请求数 > 阈值下游服务变慢
异常数异常总数 > 阈值快速失败检测

避坑：慢调用比例需要同时设置 count 和 slowRatioThreshold

  • count=500ms：超过 500ms 算慢调用
  • slowRatioThreshold=0.8：80% 的请求是慢调用才熔断
  • 两个条件同时满足才触发

三、限流（Rate Limiting）

3.1 限流算法

1. 固定窗口算法

|----窗口1----|----窗口2----|
  100个请求      100个请求

简单但有临界问题：窗口切换瞬间可能放过 2 倍流量。

2. 滑动窗口算法

|--当前窗口--|
  ↕ 滑动
|---统计区间---|

解决了临界问题，Sentinel 默认使用此算法。

3. 令牌桶算法

[令牌桶] → 以固定速率放令牌
  ↓
请求 → 取令牌 → 有令牌则通过，无则拒绝

允许突发流量（桶里攒了令牌），Resilience4j 默认使用。

4. 漏桶算法

请求 → [漏桶] → 以固定速率流出
       ↓
     溢出则丢弃

平滑流量，不允许突发。

3.2 Sentinel 限流实战

@PostConstruct
public void initFlowRules() {
    // QPS 限流
    FlowRule qpsRule = new FlowRule("createOrder")
        .setGrade(RuleConstant.FLOW_GRADE_QPS)
        .setCount(100);     // 每秒最多 100 个请求

    // 线程数限流
    FlowRule threadRule = new FlowRule("createOrder")
        .setGrade(RuleConstant.FLOW_GRADE_THREAD)
        .setCount(50);      // 最多 50 个并发线程

    // 关联限流：写接口限流时，保护读接口
    FlowRule relationRule = new FlowRule("queryOrder")
        .setGrade(RuleConstant.FLOW_GRADE_QPS)
        .setCount(200)
        .setStrategy(RuleConstant.LIMIT_RELATION)
        .setRefResource("createOrder");  // 当 createOrder QPS 高时，限制 queryOrder

    // 链路限流：只限制从某个入口来的调用
    FlowRule chainRule = new FlowRule("queryOrder")
        .setGrade(RuleConstant.FLOW_GRADE_QPS)
        .setCount(50)
        .setStrategy(RuleConstant.LIMIT_CHAIN)
        .setRefResource("orderGateway");  // 只限制从 orderGateway 调用 queryOrder

    FlowRuleManager.loadRules(Arrays.asList(qpsRule, threadRule));
}

流控效果：

// 快速失败：超出限制直接拒绝
FlowRule fastFail = new FlowRule("api")
    .setGrade(RuleConstant.FLOW_GRADE_QPS)
    .setCount(100)
    .setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT);  // 快速失败

// Warm Up：冷启动慢预热
FlowRule warmUp = new FlowRule("api")
    .setGrade(RuleConstant.FLOW_GRADE_QPS)
    .setCount(100)
    .setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_WARM_UP)
    .setWarmUpPeriodSec(30);  // 30 秒预热

// 排队等待：匀速通过
FlowRule queue = new FlowRule("api")
    .setGrade(RuleConstant.FLOW_GRADE_QPS)
    .setCount(100)
    .setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)
    .setMaxQueueingTimeMs(5000);  // 最多排队 5 秒

3.3 Resilience4j 限流实战

resilience4j:
  ratelimiter:
    instances:
      orderApi:
        limitForPeriod: 100          # 每个周期允许 100 个请求
        limitRefreshPeriod: 1s       # 周期：1 秒
        timeoutDuration: 0           # 超出限制不等待，直接拒绝
@Service
public class OrderService {

    @RateLimiter(name = "orderApi", fallbackMethod = "rateLimitFallback")
    public Order createOrder(OrderRequest request) {
        return orderRepository.save(request.toOrder());
    }

    private Order rateLimitFallback(OrderRequest request, RequestNotPermitted ex) {
        log.warn("订单接口限流，请稍后重试");
        throw new ServiceException("系统繁忙，请稍后重试");
    }
}

3.4 分布式限流（Redis + Lua）

单机限流在生产环境中往往不够，需要分布式限流：

@Component
public class RedisRateLimiter {

    private final StringRedisTemplate redisTemplate;

    // Lua 脚本：令牌桶算法
    private static final String LUA_SCRIPT = """
        local key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local rate = tonumber(ARGV[2])
        local now = tonumber(ARGV[3])
        local requested = tonumber(ARGV[4])
        
        local bucket = redis.call('hmget', key, 'tokens', 'timestamp')
        local tokens = tonumber(bucket[1]) or capacity
        local timestamp = tonumber(bucket[2]) or now
        
        -- 补充令牌
        local delta = math.max(0, now - timestamp) * rate
        tokens = math.min(capacity, tokens + delta)
        
        if tokens < requested then
            return 0  -- 拒绝
        end
        
        tokens = tokens - requested
        redis.call('hmset', key, 'tokens', tokens, 'timestamp', now)
        redis.call('expire', key, 3600)
        return 1  -- 通过
    """;

    public boolean tryAcquire(String key, int capacity, double rate, int permits) {
        Long result = redisTemplate.execute(
            new DefaultRedisScript<>(LUA_SCRIPT, Long.class),
            Collections.singletonList(key),
            String.valueOf(capacity),
            String.valueOf(rate),
            String.valueOf(System.currentTimeMillis()),
            String.valueOf(permits)
        );
        return result != null && result == 1;
    }
}

// 使用
@RestController
public class OrderController {

    @Autowired
    private RedisRateLimiter rateLimiter;

    @PostMapping("/order")
    public Result createOrder(@RequestBody OrderRequest request) {
        // 限流：1000 QPS
        if (!rateLimiter.tryAcquire("order:create", 1000, 1000.0, 1)) {
            return Result.fail("系统繁忙，请稍后重试");
        }
        return Result.ok(orderService.createOrder(request));
    }
}

四、降级（Fallback）

4.1 降级策略

策略说明示例
返回默认值返回预设的兜底数据库存查询失败返回 0
返回缓存返回上次成功的结果推荐服务挂了返回上次推荐
简化逻辑跳过非核心步骤不校验风控直接放行
异步化同步转异步处理短信通知改为 MQ 异步
人工降级开关控制，手动触发大促期间关闭评论功能

4.2 降级实现

基于 Resilience4j：

@Service
public class ProductService {

    @CircuitBreaker(name = "recommendService", fallbackMethod = "recommendFallback")
    @RateLimiter(name = "recommendService", fallbackMethod = "recommendFallback")
    public List<Product> recommend(String userId) {
        return recommendClient.getRecommendations(userId);
    }

    // 降级：返回缓存或热门商品
    private List<Product> recommendFallback(String userId, Exception e) {
        // 1. 尝试缓存
        List<Product> cached = redisTemplate.opsForList()
            .range("recommend:" + userId, 0, -1);
        if (cached != null && !cached.isEmpty()) {
            log.info("推荐降级：返回缓存数据");
            return cached;
        }
        
        // 2. 返回全局热门商品
        log.info("推荐降级：返回热门商品");
        return redisTemplate.opsForList().range("recommend:hot", 0, 9);
    }
}

基于配置开关的降级：

@Service
public class OrderService {

    @Value("${feature.comment.enabled:true}")
    private boolean commentEnabled;

    @Value("${feature.risk-check.enabled:true}")
    private boolean riskCheckEnabled;

    public OrderResult createOrder(OrderRequest request) {
        // 核心流程：必须执行
        Order order = orderRepository.save(request.toOrder());
        inventoryService.deduct(request.getProducts());
        
        // 非核心流程：可降级
        if (commentEnabled) {
            // 异步发送积分
            mqProducer.send("points-topic", new PointsEvent(order));
        }
        
        if (riskCheckEnabled) {
            riskCheckService.check(order);
        } else {
            log.info("风控检查已降级跳过");
        }
        
        return OrderResult.success(order);
    }
}

动态降级开关（基于 Nacos）：

@Configuration
@RefreshScope
public class FeatureConfig {

    @Value("${feature.comment.enabled:true}")
    private boolean commentEnabled;

    @Value("${feature.risk-check.enabled:true}")
    private boolean riskCheckEnabled;

    // Nacos 配置变更时自动刷新
}

@RestController
public class AdminController {

    @Autowired
    private FeatureConfig featureConfig;

    @PostMapping("/admin/feature/{name}/toggle")
    public Result toggleFeature(@PathVariable String name) {
        // 通过 Nacos API 动态修改配置
        nacosConfigService.publishConfig(
            "feature-" + name + ".properties",
            "DEFAULT_GROUP",
            "feature." + name + ".enabled=false"
        );
        return Result.ok();
    }
}

五、隔离（Isolation）

5.1 线程池隔离

每个服务调用使用独立的线程池，互不影响：

@Configuration
public class ThreadPoolConfig {

    @Bean("inventoryExecutor")
    public ThreadPoolTaskExecutor inventoryExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(20);
        executor.setMaxPoolSize(50);
        executor.setQueueCapacity(100);
        executor.setThreadNamePrefix("inventory-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }

    @Bean("paymentExecutor")
    public ThreadPoolTaskExecutor paymentExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(30);
        executor.setMaxPoolSize(80);
        executor.setQueueCapacity(200);
        executor.setThreadNamePrefix("payment-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
        executor.initialize();
        return executor;
    }
}

@Service
public class OrderService {

    @Autowired
    @Qualifier("inventoryExecutor")
    private ThreadPoolTaskExecutor inventoryExecutor;

    @Autowired
    @Qualifier("paymentExecutor")
    private ThreadPoolTaskExecutor paymentExecutor;

    public OrderResult createOrder(OrderRequest request) {
        // 库存扣减用独立线程池
        CompletableFuture<Void> inventoryFuture = CompletableFuture.runAsync(() -> {
            inventoryService.deduct(request.getProducts());
        }, inventoryExecutor);

        // 支付用独立线程池
        CompletableFuture<PaymentResult> paymentFuture = CompletableFuture.supplyAsync(() -> {
            return paymentService.pay(request.getPayment());
        }, paymentExecutor);

        // 等待所有完成
        CompletableFuture.allOf(inventoryFuture, paymentFuture).join();
        return OrderResult.success();
    }
}

5.2 信号量隔离

比线程池隔离更轻量，不切换线程：

// Resilience4j 信号量隔离
@Component
public class BulkheadConfig {

    @Bean
    public Bulkhead inventoryBulkhead() {
        BulkheadConfig config = BulkheadConfig.custom()
            .maxConcurrentCalls(50)       // 最大并发 50
            .maxWaitDuration(Duration.ofMillis(100))  // 获取许可最多等 100ms
            .build();
        return Bulkhead.of("inventory", config);
    }
}

@Service
public class OrderService {

    @Autowired
    private Bulkhead inventoryBulkhead;

    public StockInfo getStock(String productId) {
        return inventoryBulkhead.executeSupplier(() -> {
            return inventoryClient.getStock(productId);
        });
    }
}

5.3 线程池隔离 vs 信号量隔离

维度线程池隔离信号量隔离
开销大（线程切换）小（计数器）
异步支持不支持
超时控制支持需额外实现
适用场景外部服务调用内部方法调用

生产建议：

  • 调用外部服务（HTTP/RPC）→ 线程池隔离
  • 内部方法限流 → 信号量隔离
  • 混合使用，不同服务用不同的隔离策略

六、综合实战：高可用订单系统

6.1 完整示例

@Service
@Slf4j
public class OrderService {

    @Autowired
    private InventoryClient inventoryClient;
    @Autowired
    private PaymentClient paymentClient;
    @Autowired
    private CouponClient couponClient;
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    /**
     * 创建订单 - 综合应用熔断、限流、降级、隔离
     */
    @RateLimiter(name = "orderApi", fallbackMethod = "createOrderRateLimitFallback")
    @CircuitBreaker(name = "orderService", fallbackMethod = "createOrderFallback")
    @Bulkhead(name = "orderService", type = Bulkhead.Type.THREADPOOL)
    @TimeLimiter(name = "orderService")
    public CompletableFuture<OrderResult> createOrder(OrderRequest request) {
        return CompletableFuture.supplyAsync(() -> {
            // 1. 优惠券服务（可降级）
            CouponInfo coupon = getCouponSafe(request.getUserId(), request.getCouponId());
            
            // 2. 库存服务（必须成功，熔断保护）
            boolean stockOk = inventoryClient.deduct(request.getProducts());
            if (!stockOk) {
                throw new ServiceException("库存不足");
            }
            
            // 3. 支付服务（必须成功，熔断保护）
            PaymentResult payment = paymentClient.pay(request.getPayment());
            
            // 4. 构建订单
            Order order = Order.builder()
                .userId(request.getUserId())
                .products(request.getProducts())
                .coupon(coupon)
                .paymentId(payment.getPaymentId())
                .status(OrderStatus.PAID)
                .build();
            orderRepository.save(order);
            
            return OrderResult.success(order);
        });
    }

    /**
     * 优惠券安全获取：失败不影响下单
     */
    @CircuitBreaker(name = "couponService", fallbackMethod = "couponFallback")
    public CouponInfo getCouponSafe(Long userId, String couponId) {
        return couponClient.getCoupon(userId, couponId);
    }

    private CouponInfo couponFallback(Long userId, String couponId, Exception e) {
        log.warn("优惠券服务不可用，跳过优惠券, userId={}", userId);
        return CouponInfo.empty();  // 不使用优惠券
    }

    /**
     * 限流降级
     */
    private CompletableFuture<OrderResult> createOrderRateLimitFallback(OrderRequest req, Exception e) {
        return CompletableFuture.completedFuture(
            OrderResult.fail("SYSTEM_BUSY", "系统繁忙，请稍后重试")
        );
    }

    /**
     * 熔断降级
     */
    private CompletableFuture<OrderResult> createOrderFallback(OrderRequest req, Exception e) {
        log.error("订单创建熔断降级", e);
        return CompletableFuture.completedFuture(
            OrderResult.fail("SERVICE_UNAVAILABLE", "服务暂时不可用，请稍后重试")
        );
    }
}

6.2 完整配置

resilience4j:
  circuitbreaker:
    instances:
      orderService:
        registerHealthIndicator: true
        slidingWindowSize: 50
        minimumNumberOfCalls: 10
        failureRateThreshold: 50
        waitDurationInOpenState: 30s
        permittedNumberOfCallsInHalfOpenState: 5
      couponService:
        slidingWindowSize: 30
        failureRateThreshold: 60
        waitDurationInOpenState: 15s
  ratelimiter:
    instances:
      orderApi:
        limitForPeriod: 200
        limitRefreshPeriod: 1s
  bulkhead:
    instances:
      orderService:
        maxConcurrentCalls: 50
        maxWaitDuration: 100ms
  timelimiter:
    instances:
      orderService:
        timeoutDuration: 10s
        cancelRunningFuture: true

七、监控与告警

7.1 暴露指标到 Prometheus

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  health:
    circuitbreakers:
      enabled: true
  metrics:
    tags:
      application: order-service

7.2 Grafana 监控面板

关键指标：

  • resilience4j_circuitbreaker_state：熔断器状态（0=Closed, 1=Open, 2=Half-Open）
  • resilience4j_circuitbreaker_calls_total：调用次数（含成功/失败）
  • resilience4j_ratelimiter_available_permissions：剩余许可数
  • resilience4j_bulkhead_available_concurrent_calls：剩余并发数

7.3 告警规则

# Prometheus AlertManager
groups:
  - name: resilience
    rules:
      - alert: CircuitBreakerOpen
        expr: resilience4j_circuitbreaker_state{state="open"} == 1
        for: 1m
        annotations:
          summary: "熔断器打开: {{ $labels.instance }} - {{ $labels.name }}"
      
      - alert: RateLimiterNearlyExhausted
        expr: resilience4j_ratelimiter_available_permissions < 10
        for: 2m
        annotations:
          summary: "限流器即将耗尽: {{ $labels.name }}"

八、避坑指南

8.1 熔断配置常见错误

# ❌ 错误：minimumNumberOfCalls 太小，偶发失败就熔断
failureRateThreshold: 50
minimumNumberOfCalls: 2    # 2 次请求就判断，太激进

# ✅ 正确：积累足够样本再判断
failureRateThreshold: 50
minimumNumberOfCalls: 20   # 至少 20 次再判断

8.2 fallback 方法签名

// ❌ 错误：fallback 签名不匹配
@CircuitBreaker(name = "api", fallbackMethod = "fallback")
public String hello(String name) { ... }

private String fallback() { ... }  // 缺少 name 参数和 Exception 参数！

// ✅ 正确：fallback 必须和原方法参数一致 + Exception
private String fallback(String name, Exception e) { ... }

8.3 限流粒度

// ❌ 全局限流：大客户影响小客户
@RateLimiter(name = "globalApi")
public Result query(String userId) { ... }

// ✅ 按用户限流：每个用户独立计数
public Result query(String userId) {
    String key = "rate_limit:query:" + userId;
    if (!rateLimiter.tryAcquire(key, 100, 100.0, 1)) {
        return Result.fail("请求过于频繁");
    }
    return doQuery(userId);
}

九、面试要点总结

高频面试题

  1. 熔断器的三个状态是什么？

    • Closed：正常放行，统计失败率
    • Open：直接拒绝，不调用下游
    • Half-Open：放行少量请求探测是否恢复

  2. 熔断和降级的区别？

    • 熔断是被动触发（失败率达到阈值自动断开）
    • 降级可以是主动的（人工开关、配置切换）
    • 熔断通常会触发降级逻辑

  3. 常见的限流算法有哪些？

    • 固定窗口：简单但有临界问题
    • 滑动窗口：解决临界问题
    • 令牌桶：允许突发流量
    • 漏桶：严格匀速

  4. 线程池隔离和信号量隔离的区别？

    • 线程池隔离有独立线程，可超时控制，但开销大
    • 信号量隔离无额外线程，开销小，但不能异步
    • 外部调用用线程池，内部调用用信号量

  5. Sentinel 和 Resilience4j 怎么选？

    • Sentinel：功能全面，有控制台，适合阿里系技术栈
    • Resilience4j：轻量，函数式风格，Spring 官方推荐
    • 简单场景用 Resilience4j，复杂治理用 Sentinel

核心知识点速记

熔断 = 断路器三态（Closed/Open/Half-Open）
限流 = 四种算法（固定窗口/滑动窗口/令牌桶/漏桶）
降级 = 兜底策略（默认值/缓存/简化逻辑/异步化）
隔离 = 资源隔离（线程池/信号量）
Reconcile = 幂等 + 不阻塞 + RequeueAfter
雪崩效应 = 一个节点故障逐级放大
Sentinel = 阿里出品，有控制台
Resilience4j = Spring 官方推荐，函数式

总结

微服务治理的核心思想：假定一切都会失败，提前做好兜底。

  • 熔断保护你的服务不被下游拖死
  • 限流保护你的服务不被上游压垮
  • 降级保证核心功能在部分故障时仍可用
  • 隔离确保一个故障不会扩散到全局

实际落地建议：

  1. 先加监控，找到系统瓶颈
  2. 对核心接口加熔断 + 降级
  3. 对高流量入口加限流
  4. 对依赖外部服务的调用做隔离
  5. 持续调整参数，不要一成不变

治理不是一蹴而就的，而是根据实际运行情况不断优化的过程。

文档持续更新，欢迎打赏支持作者
Copyright © 2026 郑天祺