Azure带Timer Trigger的Web Job在部分部署环境未执行函数

你猜的没错，共享同一存储账户是导致问题的核心原因。Azure Web Jobs的Timer Trigger依赖Azure存储账户的Blob租约机制实现分布式锁，目的是防止多个实例（哪怕是不同App Service环境）重复执行定时任务。当三个环境指向同一个存储账户时，只有第一个抢到租约的Web Job会执行逻辑，另外两个虽然触发了，但因为拿不到租约，会直接跳过执行步骤，所以看不到可执行文件的运行日志。

下面是确保每个环境Web Job独立执行的配置步骤：

1. 为每个环境分配独立的Azure存储账户 #

• 给三个App Service环境分别创建专属的存储账户（或至少使用不同的存储容器），彻底避免租约冲突。
• 在每个环境的App Service应用设置中，更新AzureWebJobsStorage连接字符串，指向对应环境的专属存储账户。

2. 配置自定义锁前缀（可选，若想复用存储账户） #

如果不想新增存储账户，可以通过设置锁前缀让每个环境的租约相互隔离：

• 在.NET Core项目中，修改Timer Trigger的配置，添加自定义前缀：

  var config = new JobHostConfiguration();
  config.TimerJobs.LockPrefix = "Dev-"; // 每个环境用唯一前缀，比如Staging-、Prod-
  var host = new JobHost(config);
  host.RunAndBlock();
  

• 或者在host.json中配置：

  {
    "timer": {
      "lockPrefix": "Dev-"
    }
  }
  

• 确保每个环境的前缀唯一，这样不同环境的Web Job会使用不同的Blob租约，互不干扰。

3. 验证App Service的Web Jobs基础配置 #

• 检查另外两个环境的Web Jobs是否设置为连续运行（Timer Trigger必须用连续运行模式），避免因模式错误导致执行异常。
• 确认每个环境的Web Job文件部署完整，可执行文件权限正常（在Kudu中查看site/wwwroot/App_Data/Jobs/Continuous/[你的作业名称]下的文件是否齐全）。

4. 关于Timer Job手动触发的说明 #

Timer Trigger类型的Web Job确实无法通过门户直接手动触发，若需要测试逻辑，可以临时修改代码添加一个手动触发的函数，或者在本地运行调试，也可以通过Azure CLI命令触发：

az webjob continuous trigger --resource-group <资源组名> --webapp-name <应用服务名> --name <作业名> --triggered

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