如何在Azure Functions中使用Retry pattern实现错误重试策略？

针对你在任务调度器里调用Proxy URL报错需要配置重试的场景，Azure Functions里的重试实现主要分两类，你可以根据自己的错误判断粒度需求选择：

一、内置宿主级重试策略 #

这种是Functions运行时原生提供的能力，不需要在业务代码里嵌入重试逻辑，配置完成后运行时会自动在函数执行失败时按规则重试，适合不需要区分具体错误类型、只要执行失败就重试的通用场景。
目前支持两种重试模式：

• 固定延迟重试：每次重试的时间间隔固定，适合Proxy临时网络波动、短时间限流的场景
• 指数退避重试：重试间隔逐次拉长，适合Proxy服务端过载的场景，避免高频重试加剧下游压力

配置方式直接在函数的配置文件中添加重试段即可，示例如下：
固定延迟重试配置：

{
  "retry": {
    "strategy": "fixedDelay",
    "maxRetryCount": 5,
    "delayInterval": "00:00:03"
  }
}

指数退避重试配置：

{
  "retry": {
    "strategy": "exponentialBackoff",
    "maxRetryCount": 5,
    "minimumInterval": "00:00:01",
    "maximumInterval": "00:01:00"
  }
}

注意：内置重试的触发条件是函数抛出未捕获的异常、或函数执行进程异常退出。如果你在业务代码里catch了Proxy返回的错误但没有向外抛出，内置重试不会触发。

二、自定义代码实现重试（Proxy场景推荐） #

如果需要精准判断Proxy返回的错误类型，比如只对超时、5xx服务错误、429限流错误重试，对400参数错误、401鉴权错误、404资源不存在这类确定无法通过重试解决的错误直接返回，优先用自定义代码实现重试，可控性最高。
实现时遵循几个规则即可：

• 先明确可重试的错误范围：仅对瞬时故障类错误重试，业务逻辑类错误直接透传返回
• 采用「指数退避+随机抖动」的间隔策略，不要用固定极短间隔重试，避免给Proxy造成流量冲击
• 提前设置最大重试次数、总执行时长阈值，不要无限重试，避免超出Azure Function的执行超时限制
• 非幂等的调度任务必须搭配幂等校验，避免重试导致任务重复执行

以C#函数调用Proxy的重试逻辑为例，参考代码如下：

// 全局单例HttpClient，避免端口耗尽
private static readonly HttpClient _httpClient = new HttpClient();
private const int MaxRetryTimes = 4;

public async Task<string> RequestProxyWithRetry(string proxyUrl, HttpContent reqContent)
{
    for (int retryCount = 0; retryCount < MaxRetryTimes; retryCount++)
    {
        try
        {
            var resp = await _httpClient.PostAsync(proxyUrl, reqContent);
            if (resp.IsSuccessStatusCode)
            {
                return await resp.Content.ReadAsStringAsync();
            }
            // 非可重试状态码直接抛错，不进入重试
            int statusCode = (int)resp.StatusCode;
            if (!IsRetriableError(statusCode))
            {
                throw new InvalidOperationException($"Proxy返回非可重试错误，状态码：{statusCode}");
            }
            // 最后一次重试仍失败直接抛错
            if (retryCount == MaxRetryTimes - 1)
            {
                throw new InvalidOperationException($"调用Proxy达到最大重试次数，最终错误码：{statusCode}");
            }
        }
        catch (HttpRequestException ex)
        {
            // 网络连接类错误（超时、DNS解析失败、连接重置）纳入重试范围
            if (retryCount == MaxRetryTimes - 1)
            {
                throw new InvalidOperationException("调用Proxy网络异常，达到最大重试次数", ex);
            }
        }
        // 计算指数退避间隔+随机抖动，避免多实例同时重试造成惊群
        var delay = TimeSpan.FromSeconds(Math.Pow(2, retryCount)) 
                    + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 1000));
        await Task.Delay(delay);
    }
    return default;
}

// 定义可重试的状态码范围
private bool IsRetriableError(int statusCode)
{
    return statusCode == 429 || statusCode >= 500;
}

三、常见踩坑 #

• 不要同时开启内置重试和自定义代码重试，两种机制会叠加重试次数，比如内置配置5次重试、代码写4次重试，极端情况会触发20次重复调用，很容易打挂下游Proxy
• 重试总时长不要超过当前函数配置的超时阈值，消费计划下函数默认超时5分钟，专用计划可按需调整，否则重试到一半会被运行时强制终止
• 不要用小于1秒的固定间隔重试，Proxy过载时高频重试只会放大故障，甚至触发Proxy的限流封禁

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