我有一个Azure托管的MVC Web App，用户可以通过按下按钮请求生成报告 . 此报告是一个计算密集型，长时间运行的过程，我只想在晚上运行 . 我有使用Queue Triggered WebJobs处理后台任务的经验;但是，这项工作需要比我的Web App Service计划更多的资源，我不想在我的Web App旁边运行这个计算过程 . 我希望我可以为每个请求写一个队列消息，然后每晚检查一下这个队列，看它是否有任何消息 . 如果是，则创建/启动具有足够功率/内存的新工作者角色实例来处理作业，处理队列消息，然后关闭/解除分配工作人员以防止持续收费 .
我无法找到在启动Worker Role之前检查队列的最佳方法，并且只有在有工作要做的时才创建/启动Worker，因为这将是一个大的实例我希望最小化正常运行时间以降低成本 .
3 回答
您可以使用创建一个使用TimerTrigger的触发WebJob，该TimerTrigger设置为每天早上2:00唤醒一次 . 然后，TimerTrigger触发的方法可以查看队列以查看是否存在消息 . 如果存在一条或多条消息，则启动实际出列并处理消息的辅助角色 .
您可以使用队列触发器编写Web作业，以便在新消息弹出到队列时自动触发 . 然后，您可以将Web作业托管在自己的App Service Plan中，与Web App分开，因此它拥有自己专用的资源 .
既然您提到要降低成本，我实际上建议您使用Azure功能 . Azure功能也可以使用队列触发器进行设置，还可以使用“消耗计划”定价选项仅在运行Azure功能时为其付费 .
这是一个概述Azure功能定价如何工作的链接：
好吧，Rob的评论让我进入了服务管理库，然后将我带到Azure自动化和Runbook . 我认为这最终将成为解决方案 . 我可以使用PowerShell cmdlet创建Runbook，它将查看存储队列，如果找到任何消息，它可以创建/部署Worker Role的新实例，该实例将在启动时查看队列并开始处理任何消息 . 棘手的部分看起来正在关闭 Worker 角色 . 我发现的自毁/自杀 Cloud 服务示例似乎只是杀死了多个实例，但不是最后一个实例 . 因为我只有一个实例在运行，所以我认为我不能让它自行杀死并使其进入未分配状态 . 我认为解决方案是再次使用Runbook . 让Worker Role将“已完成”消息写入另一个队列，并使预定的Runbook每隔x分钟观察一次该队列 . 如果找到消息，请停止并取消分配辅助角色 . 鉴于函数有一个硬运行时间限制，我不能使用它 . Cloud 服务为我提供了比WebJobs / Web App Service计划更多的资源选择（更精细的VM类型） .