Azure服务总线主题触发器函数：Polly重试与[ExponentialBackoffRetry]属性的替代可行性及方案选型

首先直接给结论：完全可以用Polly来替代原生的[ExponentialBackoffRetry]属性，至于哪种方案更贴合你的需求，取决于你对重试逻辑的复杂度要求，下面我详细拆解两种方案的差异和适用场景：

一、原生[ExponentialBackoffRetry]的优缺点 #

你当前代码用的就是这个内置属性，它是Azure Functions Runtime提供的原生重试机制，特点非常鲜明：

优势 #

• 配置极简：只需要在函数头部加一行属性声明，不用写额外业务代码，上手快、维护成本低
• Runtime托管：重试逻辑由Functions Runtime负责，函数执行抛出异常后，Runtime会自动按你配置的指数退避规则重新触发函数，不用关心重试调度细节
• Service Bus集成友好：重试次数会和Service Bus消息的DeliveryCount关联，达到最大重试次数后，消息会自动进入死信队列（前提是你配置了Service Bus的MaxDeliveryCount）

局限性 #

• 灵活性不足：只能针对所有未捕获的异常重试，没法区分特定异常类型（比如只对数据库连接异常重试，对参数验证错误直接放弃）
• 缺少自定义钩子：没法在重试前后添加自定义逻辑（比如记录重试次数、打印详细重试日志，或者重试前做资源清理）
• 重试上下文有限：没法在重试过程中传递或修改上下文信息，只能依赖Runtime的默认行为

二、Polly重试的优缺点 #

Polly是.NET生态里成熟的容错库，提供了极其灵活的重试、熔断、超时等策略，用来替代原生重试完全可行：

优势 #

• 极致灵活：可以针对特定异常（甚至特定异常的错误码）、特定返回值触发重试，比如只对HttpRequestException或SqlException重试，对参数验证失败的ValidationException直接终止
• 自定义钩子丰富：可以通过OnRetry、OnRetryAsync添加重试前后逻辑，比如每次重试时记录「第N次重试，等待X秒」的日志，或者重试前重置资源状态
• 组合策略能力：可以和Polly的其他策略（超时、熔断、舱壁隔离）结合，构建更健壮的容错逻辑，比如重试时同时设置超时时间，避免单个重试卡住太久
• 完全可控：重试逻辑在函数内部执行，你可以完全掌控重试的触发条件、等待时间、终止条件

局限性 #

• 需要额外代码：相比原生属性，要写更多代码配置策略，对团队成员的Polly熟悉度有一定要求
• 和Functions Runtime集成弱：Polly的重试是函数内部逻辑，Runtime只会认为这是一次函数执行，不会更新Service Bus消息的DeliveryCount（除非最终函数抛出异常触发Runtime重试），需要注意避免双重重试（同时开启Polly和原生重试）

三、哪种方案更符合你的需求？ #

• 如果需求只是简单的指数退避重试，对所有异常都重试：优先选[ExponentialBackoffRetry]，它足够简单，不用额外引入依赖，维护成本低
• 如果需求更复杂：比如只对特定异常重试、需要自定义重试日志、要结合其他容错策略，那Polly是更好的选择，它能满足几乎所有定制化需求

四、Polly替代的示例代码 #

如果决定用Polly，可以把重试逻辑包裹在_processor.ProcessAsync外面，参考示例：

[FunctionName(nameof(CardGroupEventSubscriber))]
// 注意：如果用Polly内部重试，建议移除原生的[ExponentialBackoffRetry]属性，避免双重重试
public async Task RunAsync([ServiceBusTrigger("%ServiceBusConfigOptions:TopicEventTypeName%", "%ServiceBusConfigOptions:TopicEventTypeSubscription%", Connection = "ServiceBusConfigOptions:ConnectionString")] string sbMsg)
{
    try
    {
        var message = sbMsg.AsPoco<CardGroupEvent>();
        _logger.LogInformation("{class} - {method} - {RequestId} - Start", nameof(CardGroupEventSubscriber), nameof(CardGroupEventSubscriber.RunAsync), message.RequestID);
        _logger.LogInformation($"Started processing message {message.AsJson()} with {nameof(CardGroupEventSubscriber)}");
        
        var validationResult = new CardGroupEventValidator().Validate(message);
        if (validationResult.IsValid)
        {
            // 配置Polly指数退避策略：最多5次重试，初始等待4秒，最大等待1分钟
            var retryPolicy = Policy
                .Handle<Exception>() // 可改成你需要的特定异常，比如typeof(HttpRequestException)
                .WaitAndRetryAsync(
                    retryCount: 5,
                    sleepDurationProvider: retryAttempt => 
                    {
                        // 计算等待时间：第1次4s，第2次8s...直到最大60s
                        var waitTime = TimeSpan.FromSeconds(4 * Math.Pow(2, retryAttempt - 1));
                        return waitTime > TimeSpan.FromMinutes(1) ? TimeSpan.FromMinutes(1) : waitTime;
                    },
                    onRetryAsync: (exception, waitTime, retryCount, context) =>
                    {
                        // 自定义重试日志
                        _logger.LogWarning($"第{retryCount}次重试处理消息 {message.RequestID}，等待{waitTime.TotalSeconds}秒，异常：{exception.Message}");
                        return Task.CompletedTask;
                    }
                );

            // 用Polly策略包裹处理逻辑
            await retryPolicy.ExecuteAsync(async () =>
            {
                await _processor.ProcessAsync(message);
            });
        }
    }
    catch (Exception ex)
    {
        _logger.LogError($"Unable to process card group event {sbMsg.AsJson()} with {nameof(CardGroupEventSubscriber)}, ExceptionMessage:{ex.Message}, StackTrace: {ex.StackTrace}");
        throw;
    }
}

额外注意点 #

不管用哪种方案，都要和Service Bus配置配合：

• 设置合适的MaxDeliveryCount：避免消息无限重试，达到次数后进入死信队列
• 如果用Polly，建议关闭原生的[ExponentialBackoffRetry]，否则会出现「Polly内部重试+Runtime重试」的双重重试，导致重试次数远超预期

内容的提问来源于stack exchange，提问作者Rakesh Kumar