Polly 策略组合中识别拒绝来源的技术实现

在分布式系统开发中，限流和并发控制是保障系统稳定性的重要手段。Polly作为.NET生态中广泛使用的弹性策略库，其V8版本引入了全新的策略组合机制。本文将深入探讨如何在使用Polly组合多种限流策略时，准确识别请求被拒绝的具体原因。

策略组合的典型场景

在实际应用中，开发者经常需要组合多种策略来保护系统。例如，一个典型的API调用场景可能同时需要：

• 并发控制：限制同时进行的请求数量
• 速率限制：控制每秒/每天的请求量

当请求被拒绝时，系统需要根据不同的拒绝原因采取不同的处理方式：

• 如果是速率限制导致的拒绝，可以读取RetryAfter延迟时间后重试
• 如果是并发限制导致的拒绝，可能需要直接返回错误给调用方

现有方案的局限性

在Polly V8中，所有限流策略拒绝请求时都会抛出RateLimiterRejectedException异常。这带来了一个识别问题：我们无法直接从异常中判断是哪种策略导致了拒绝。

开发者通常采用两种变通方案：

1. 检查RetryAfter属性是否为null来推断是否是并发限制
2. 通过复杂的策略包装和异常处理机制来识别来源

这两种方案都存在明显缺陷：第一种依赖于实现细节，第二种过于复杂且难以维护。

Polly 8.5.0的改进方案

Polly团队在8.5.0版本中引入了TelemetrySource属性，完美解决了这一问题。该属性包含三个关键信息：

• 管道名称(PipelineName)
• 管道实例名称(PipelineInstanceName)
• 策略名称(StrategyName)

开发者现在可以这样配置策略：

var pipeline = new ResiliencePipelineBuilder()
    .AddRateLimiter(new RateLimiterStrategyOptions {
        Name = "ConcurrencyLimiter",
        RateLimiter = /*...*/
    })
    .AddRateLimiter(new RateLimiterStrategyOptions {
        Name = "RequestRateLimiter",
        RateLimiter = /*...*/
    })
    .Build();

然后在异常处理中精确识别拒绝来源：

try {
    await pipeline.ExecuteAsync(/*...*/);
}
catch (RateLimiterRejectedException ex) {
    if (ex.TelemetrySource.StrategyName == "ConcurrencyLimiter") {
        // 处理并发限制
    }
    else if (ex.TelemetrySource.StrategyName == "RequestRateLimiter") {
        // 处理速率限制
    }
}

策略顺序的最佳实践

虽然Polly的策略执行顺序理论上不影响功能，但在实际应用中，建议将并发限制放在外层，速率限制放在内层。这种排列更符合大多数场景的逻辑：

1. 首先检查系统是否有足够的处理能力(并发控制)
2. 然后检查是否超过调用频率限制(速率控制)

总结

Polly 8.5.0通过引入TelemetrySource属性，为策略组合提供了更精细的控制能力。这一改进使得开发者能够：

• 更精确地识别请求被拒绝的原因
• 根据不同的拒绝原因采取针对性的处理措施
• 构建更健壮、更易维护的弹性策略组合

对于需要组合多种限流策略的.NET应用，这一特性将显著提升系统的可观测性和可维护性。