如何部署BackgroundService？Worker项目部署方案及IIS运行问题说明

1. 集成到ASP.NET Core项目（WebAPI/MVC等）部署到IIS #

这种方式已验证可行，仅需注意以下配置点即可正常运行：

• 必须将IIS对应应用池的闲置超时设置为0，同时禁用定期自动回收，避免后台服务随IIS进程回收被意外终止
• 所有需要权限访问的资源（比如数据库、本地文件、内网接口等），要确认IIS应用池的运行账号有对应访问权限，之前遇到的数据库集成验证问题就属于这类配置问题
• 服务注册代码参考如下，现有写法已经正确：

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        })
        .ConfigureServices((hostContext, services) =>
        {
            services.AddHostedService<Worker>();
        });

这种方案适合需要同时对外提供Web接口和运行后台任务的场景，不用单独维护多个部署单元。

2. 独立Worker Service项目部署为Windows服务 #

适合纯后台任务、不需要对外提供Web接口的场景，稳定性比IIS托管更高：

• 先给项目安装Microsoft.Extensions.Hosting.WindowsServices NuGet包
• 在CreateHostBuilder方法末尾追加.UseWindowsService()调用，适配Windows服务的生命周期管理
• 发布项目后，用Windows自带的sc命令、PowerShell的New-Service指令即可把发布后的可执行文件注册为系统服务，支持配置开机自启、独立运行账号，不受IIS策略限制。

3. 独立Worker Service项目部署为Linux Systemd服务 #

适合部署在Linux服务器环境的场景：

• 先给项目安装Microsoft.Extensions.Hosting.Systemd NuGet包
• 在CreateHostBuilder方法末尾追加.UseSystemd()调用，适配Linux Systemd的生命周期管理
• 发布后编写对应的.service配置文件放到/etc/systemd/system目录下，用systemctl指令即可管理服务的启动、停止、开机自启。

4. 容器化部署 #

适合需要跨环境部署、对一致性要求高的场景：

• 给Worker项目编写Dockerfile打包为Docker镜像
• 可根据实际需求部署到不同环境：
  • 单机Docker环境：设置容器重启策略为always即可实现开机自启
  • K8s、Docker Swarm等容器编排集群：可配置多副本、健康检查、自动扩缩容，满足高可用要求

5. 云托管服务部署 #

不需要自行维护服务器基础设施，可直接部署到各云厂商的托管服务：

• 支持直接上传发布包或者容器镜像部署
• 自带监控告警、自动扩缩容、负载均衡等能力，适合不想投入服务器运维成本的场景。

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