Azure Container Apps部署.NET长运行BackgroundService服务失败问题

该问题本质是预览版 Azure Container Apps 针对无网络入口的长驻Worker类服务的默认探测规则、自动扩缩容规则触发了服务停止信号，导致ExecuteAsync方法传入的stoppingToken被提前取消，和代码本身的基础逻辑无关。

1. 调整 Azure Container Apps 配置 #

• 关闭不必要的Ingress入口：Worker服务不需要对外提供HTTP服务，明确在配置中将Ingress设置为Disabled，避免平台默认执行HTTP健康探测失败杀死容器
• 调整自动扩缩容规则：将最小实例数设置为1，关闭缩放到0的配置，避免平台因无流量判定服务闲置主动发送停止信号
• 调整健康探测阈值：如果需要保留探测，可将启动探测的初始延迟调整为至少30秒，失败阈值调整为10以上，给服务足够的启动时间
• 检查容器的资源配额配置，确保CPU、内存配额满足服务运行的最低要求，避免因资源超限被平台强制杀死

2. 调整代码适配平台规则 #

不要直接使用await Task.Delay(Timeout.Infinite, stoppingToken);的无限等待写法，替换为循环短间隔等待，同时可添加心跳日志让平台识别进程处于正常运行状态，示例代码如下：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    // 启动时打印日志，明确告知平台服务已启动
    Console.WriteLine("Worker service started successfully");
    
    while (!stoppingToken.IsCancellationRequested)
    {
        // 此处插入业务逻辑代码
        // 每1秒检查一次停止信号，替代无限等待
        await Task.Delay(1000, stoppingToken);
    }
    
    // 停止时打印日志，方便排查问题
    Console.WriteLine("Worker service is stopping");
}

同时要确保程序入口使用阻塞式的运行方法，比如Host.Run()而非Host.RunAsync()直接返回，避免主进程提前退出。

3. 辅助排查方案 #

• 在Dockerfile中明确指定工作目录、入口进程，避免出现PID1进程不是.NET程序的情况
• 开启Container Apps的日志功能，查看容器启动阶段的系统日志，确认触发停止信号的具体原因

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