Polly项目中多级重试与熔断器策略的整合实践

引言

在分布式系统开发中，网络请求的稳定性至关重要。Polly作为.NET生态中广受欢迎的弹性策略库，提供了强大的重试和熔断机制。本文将深入探讨如何在一个HTTP客户端中整合多组不同状态码的重试策略，并与熔断器策略协同工作。

场景分析

假设我们需要处理三种不同类型的HTTP错误响应，每种都需要不同的重试策略：

1. 401 Unauthorized：需要每秒重试1次，共3次
2. 429 TooManyRequests：需要指数退避重试（1秒、2秒、4秒），共3次
3. 502 BadGateway/504 GatewayTimeout：需要每5秒重试1次，共3次

同时，我们希望这些错误都能触发同一个熔断器，当错误达到阈值时，系统能够自动熔断。

初始方案的问题

最初尝试的方案是为每种状态码创建独立的重试策略，然后与熔断器策略组合：

var retry1 = Policy<HttpResponseMessage>
    .HandleResult(r => r.StatusCode == HttpStatusCode.Unauthorized)
    .Or<BrokenCircuitException>()
    // 其他重试策略类似
    .WaitAndRetryAsync(...);

var circuitBreaker = Policy<HttpResponseMessage>
    .HandleResult(r => retryableStatusCodes.Contains(r.StatusCode))
    .CircuitBreakerAsync(...);

var strategy = Policy.WrapAsync(retry1, retry2, retry3, circuitBreaker);

这种实现存在几个关键问题：

1. 策略冲突：每个重试策略都处理BrokenCircuitException，导致熔断时多个重试策略会同时触发
2. 执行顺序混乱：策略链中后置的重试策略可能错误处理前置策略抛出的异常
3. 熔断效果不佳：重试策略在熔断期间仍会尝试执行，违背了熔断器的设计初衷

优化方案

1. 分离异常处理职责

首先，我们需要明确各策略的职责边界：

• 重试策略：只处理特定的HTTP状态码
• 熔断策略：处理所有可重试的状态码
• 熔断异常策略：专门处理BrokenCircuitException

// 重试策略不再处理BrokenCircuitException
var retry1 = Policy<HttpResponseMessage>
    .HandleResult(r => r.StatusCode == HttpStatusCode.Unauthorized)
    .WaitAndRetryAsync(...);

// 专门处理熔断异常的策略
var brokenCircuitRetry = Policy<HttpResponseMessage>
    .Handle<BrokenCircuitException>()
    .WaitAndRetryForeverAsync(
        _ => TimeSpan.FromSeconds(5), // 熔断持续时间的一半
        (ex, ts) => Console.WriteLine("等待熔断恢复..."));

2. 策略组合顺序

正确的策略组合顺序应该是：

1. 最外层：熔断异常重试策略
2. 中间层：各类HTTP状态码重试策略
3. 最内层：熔断器策略

var allRetries = Policy.WrapAsync(retry1, retry2, retry3);
var strategy = Policy.WrapAsync(brokenCircuitRetry, allRetries, circuitBreaker);

3. 熔断器配置

熔断器需要监控所有可重试的状态码：

var retryableStatusCodes = new[] {
    HttpStatusCode.Unauthorized,
    HttpStatusCode.TooManyRequests,
    HttpStatusCode.BadGateway,
    HttpStatusCode.GatewayTimeout
};

var circuitBreaker = Policy<HttpResponseMessage>
    .HandleResult(r => retryableStatusCodes.Contains(r.StatusCode))
    .CircuitBreakerAsync(
        handledEventsAllowedBeforeBreaking: 2,
        durationOfBreak: TimeSpan.FromSeconds(10),
        onBreak: (r, ts) => Console.WriteLine("熔断触发，停止请求10秒"),
        onReset: () => Console.WriteLine("熔断恢复"),
        onHalfOpen: () => Console.WriteLine("进入半开状态"));

实际应用示例

在ASP.NET Core中配置HTTP客户端：

builder.Services.AddHttpClient("MyClient", client => 
{
    client.BaseAddress = new Uri("http://localhost:6002");
})
.AddPolicyHandler((services, request) => 
{
    var retry1 = CreateRetryPolicy1();
    var retry2 = CreateRetryPolicy2();
    var retry3 = CreateRetryPolicy3();
    var circuitBreaker = CreateCircuitBreakerPolicy();
    var brokenCircuitRetry = CreateBrokenCircuitRetryPolicy();
    
    var allRetries = Policy.WrapAsync(retry1, retry2, retry3);
    return Policy.WrapAsync(brokenCircuitRetry, allRetries, circuitBreaker);
});

策略执行流程

1. 当请求返回401/429/502/504时：

   • 匹配对应的重试策略执行重试
   • 同时熔断器会计数，达到阈值后触发熔断

2. 当熔断器处于开启状态时：

   • 直接抛出BrokenCircuitException
   • 由专门的熔断异常策略捕获并等待
   • 不会触发HTTP状态码的重试策略

3. 熔断器进入半开状态后：

   • 允许少量请求通过测试
   • 成功则关闭熔断，失败则再次开启

最佳实践建议

1. 合理设置熔断阈值：根据系统负载和业务需求调整handledEventsAllowedBeforeBreaking
2. 熔断持续时间：通常设置为平均恢复时间的2-3倍
3. 熔断重试间隔：建议设置为熔断持续时间的一半
4. 监控与告警：实现熔断器的onBreak回调，记录日志并触发告警
5. 区分关键与非关键错误：某些错误可能不需要触发熔断

总结

通过合理设计Polly策略的组合与执行顺序，我们可以构建一个健壮的HTTP客户端，既能针对不同类型的错误实施差异化的重试策略，又能通过熔断机制防止级联故障。关键在于明确各策略的职责边界，避免策略间的意外干扰，从而确保系统在各种异常情况下的稳定运行。