WebJobs 实例运行规则与单实例配置指南

在 Azure App Service 中，WebJobs 的运行实例数由 WebJob 类型和配置决定，而非应用实例数。了解这些规则可避免重复执行，确保任务在合适实例上运行。本文基于官方文档和实验，梳理不同 WebJob 类型的默认行为，并给出将连续 WebJob 限制为单实例的具体方法。

1. WebJob 类型与默认行为

App Service 支持三种主要 WebJob 类型：

连续 WebJob（Continuous）
默认在应用的所有实例上持续运行，适用于轮询队列、后台监控等常驻任务。
（来源：微软文档《WebJobs 概览》）
触发 WebJob（Triggered）
包括手动触发和定时触发。每次触发由平台选择一个实例执行，不会在所有实例上同时运行。
（来源：微软文档《WebJobs 概览》）
定时 WebJob（Scheduled）
属于触发 WebJob 的一种，通过 NCRONTAB 表达式定义触发时间，同样遵循单实例执行的默认行为。

假设应用扩展到 3 个实例，不同类型的 WebJob 表现如下：

WebJob 类型	默认行为	3 实例环境下的稳定状态
连续（多实例）	每个实例都启动一份任务	3 份任务进程持续运行
连续（单实例）	配置 `is_singleton: true` 后只在一个实例运行	1 份任务进程持续运行
手动触发	每次触发选择一个实例执行	点击一次 Run，启动 1 份执行
定时触发	每个触发点由一个实例执行	每次触发启动 1 份执行，不是 3 份

实验记录：cnblogs 上的测试使用同一 PowerShell 脚本，在 3 实例环境中分别部署四种 WebJob，验证了上述行为（来源：cnblogs《App Service WebJobs 多实例实验：谁在运行，什么时候运行？》）。

注意：对于触发 WebJob，“一个实例”并不意味着固定在同一台机器。下次触发、实例替换或单实例连续任务接管后，执行实例可能发生变化。平台也不承诺手动触发会依次轮询 A、B、C，因此连续点击几次却一直落在 A 上，并不违反上述规则。

如果连续任务不能在多个实例上重复执行（例如写入共享资源），可通过以下任一方式将其限制为单实例：

在 WebJob 文件夹根目录添加或更新 settings.job，内容如下：

{
  "is_singleton": true
}

对于定时 WebJob，可同时指定调度表达式：

{
  "schedule": "0 */5 * * * *",
  "is_singleton": true
}

来源：微软文档说明“可以将 WebJob 限制为单个实例”，并提供了 settings.job 的示例。

在 Azure 门户的应用设置中添加：

该设置会使连续 WebJob 仅在单个实例上运行。

来源：微软文档《WebJobs 概观》提到可以使用 WEBJOBS_RUN_ONCE 设置来限制单实例运行。

以下步骤可用于自行验证多实例行为：

准备一个 PowerShell 脚本，输出当前实例 ID、UTC 时间和运行批次。示例脚本见 cnblogs 实验文章。
将脚本打包为四个 ZIP 文件：continuous-multi.zip、continuous-single.zip、manual.zip、scheduled.zip。
在 Azure 门户中为同一 App Service 创建四个 WebJob，分别上传对应的 ZIP，并设置类型为连续（多实例）、连续（单实例）、手动触发、定时触发。
确保应用扩展到至少 3 个实例。
触发各 WebJob 并查看 Kudu 日志，记录每次执行的实例 ID。

提示：实验中连续单实例 WebJob 需要在 settings.job 中配置 is_singleton: true，否则默认仍为多实例。

免费/共享定价层：多实例运行选项仅适用于基本、标准和高级定价层（来源：微软文档《使用 WebJobs 执行后台工作》）。
始终开启（Always On）：对于定时或连续 WebJob，建议启用“始终开启”以保证调度不因应用闲置而超时。
触发 WebJob 的重叠：默认情况下，若上一次运行尚未完成，新的触发可能会在同实例上并行启动。如需串行执行，可在 settings.job 中设置 is_singleton: true（来源：微软文档 Q&A）。

参考资料

通过理解 WebJob 的实例选择机制，你可以精确控制后台任务的执行位置，避免重复处理，提升应用可靠性。