ASP.Net Core+Kestrel Windows服务端口绑定自动重试的最佳实现方法

这个问题问得很到位！直接在Main里硬写重试逻辑确实显得和ASP.NET Core的框架设计格格不入，不够优雅。下面给你两种符合框架理念的实现方案，按推荐程度排序：

方案一：异步重试循环 + 框架原生日志 #

这种方案不需要引入额外依赖，完全利用ASP.NET Core自带的日志和异步编程模型，代码清晰且符合框架设计：

public static async Task Main(string[] args)
{
    // 先初始化日志工厂，确保启动失败时能记录日志
    var loggerFactory = LoggerFactory.Create(builder =>
    {
        builder.AddConsole();
        builder.AddEventLog(); // Windows服务下，日志会写入系统事件查看器
    });
    var logger = loggerFactory.CreateLogger<Program>();

    const int maxRetries = 10; // 可自定义最大重试次数，设为int.MaxValue可无限重试
    const int retryDelaySeconds = 60;
    int retryCount = 0;

    while (true)
    {
        try
        {
            var host = CreateHostBuilder(args).Build();
            await host.RunAsync(); // 用异步RunAsync替代同步Run，符合框架异步设计
            break; // 服务正常退出时跳出循环
        }
        // 精准捕获端口占用的IOException：通过HResult判断比字符串更可靠（不受系统语言影响）
        catch (IOException ex) when (ex.HResult == -2147024864) // 对应WSAEADDRINUSE错误码0x800700E2
        {
            retryCount++;
            if (retryCount > maxRetries)
            {
                logger.LogCritical(ex, "端口绑定失败，已达到最大重试次数（{MaxRetries}次），服务终止", maxRetries);
                throw;
            }

            logger.LogWarning(ex, "端口已被占用，将在 {DelaySeconds} 秒后进行第 {RetryCount} 次重试", 
                retryDelaySeconds, retryCount);
            await Task.Delay(TimeSpan.FromSeconds(retryDelaySeconds));
        }
        catch (Exception ex)
        {
            // 处理其他未预期的异常，记录日志后终止服务
            logger.LogCritical(ex, "服务启动发生未预期的致命异常，终止运行");
            throw;
        }
    }
}

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .UseWindowsService() // 标记为Windows服务
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseKestrel(options =>
            {
                options.ListenAnyIP(5000); // 替换为你的指定端口
            })
            .UseStartup<Startup>();
        });

方案优势： #

• 完全基于ASP.NET Core原生API，无额外依赖
• 精准的异常捕获：通过HResult判断端口占用，避免系统语言差异导致的判断失效
• 完善的日志记录：Windows服务场景下，日志会写入系统事件查看器，便于排查问题
• 可控制重试次数：既可以设置最大重试次数，也可以配置为无限重试

方案二：用Polly封装重试策略（更简洁灵活） #

如果你的项目已经在使用Polly（一款流行的.NET容错库），可以用它来封装重试逻辑，让代码更简洁，同时支持更复杂的重试规则（比如指数退避、熔断等）：

using Polly;
using Polly.Retry;

public static async Task Main(string[] args)
{
    var loggerFactory = LoggerFactory.Create(builder =>
    {
        builder.AddConsole();
        builder.AddEventLog();
    });
    var logger = loggerFactory.CreateLogger<Program>();

    // 定义重试策略：仅捕获端口占用异常，每隔60秒重试一次（无限重试）
    var retryPolicy = Policy
        .Handle<IOException>(ex => ex.HResult == -2147024864)
        .WaitAndRetryForeverAsync(retryAttempt => TimeSpan.FromSeconds(60), (ex, delay) =>
        {
            logger.LogWarning(ex, "端口已被占用，将在 {DelaySeconds} 秒后重试", delay.TotalSeconds);
        });

    // 用策略包裹Host启动逻辑
    await retryPolicy.ExecuteAsync(async () =>
    {
        var host = CreateHostBuilder(args).Build();
        await host.RunAsync();
    });
}

// CreateHostBuilder代码同方案一

方案优势： #

• 重试逻辑与业务逻辑分离，代码更简洁易读
• 支持丰富的容错规则：比如指数退避、最大重试次数、熔断等
• 符合SOLID原则，便于后续扩展和维护

为什么这种方式符合框架设计？ #

你担心在Main里处理重试不符合框架意图，但实际上：

• Host的启动本身就是应用的入口点，在这里处理启动失败的重试是合理的边界
• 我们没有修改ASP.NET Core框架的内部逻辑，只是在外部对Host的启动流程做了一层优雅的包装
• 完全遵循了框架的异步编程模型和日志规范

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