从队列触发器启动Azure辅助角色

Question

我有一个Azure托管的MVC Web App，用户可以通过按下按钮来请求生成报告。此报告是一个计算密集型，长时间运行的过程，我只想在晚上运行。我有使用Queue Triggered WebJobs处理后台任务的经验;但是，这项工作将需要比我的Web App Service计划更多的资源，并且我不想在我的Web App旁边运行此计算过程。我希望我可以为每个请求写一个队列消息，然后每晚检查一下这个队列，看看它是否有任何消息。如果是，则创建/启动具有足够功率/内存的新工作者角色实例来处理作业，处理队列消息，然后关闭/解除分配工作人员以防止持续收费。

我无法找到在启动辅助角色之前检查队列的最佳方法，只有在有工作需要时才创建/启动工作程序，因为这将是一个大的实例我希望最小化正常运行时间来保持成本下来。

Answer 1

您可以使用创建一个触发的WebJob，它使用一个TimerTrigger，设置为每天凌晨2点（如凌晨2点）唤醒一次。然后，TimerTrigger触发的方法可以查看队列以查看是否存在消息。如果存在一条或多条消息，则启动实际出列并处理消息的辅助角色。

Answer 2

您可以使用队列触发器编写Web作业，以便在新消息弹出到队列时自动触发。然后，您可以将Web作业托管在自己的应用服务计划中，与Web应用程序分开，因此它拥有自己的专用资源。

由于您提到要降低成本，我实际上建议您使用Azure功能。 Azure功能也可以使用队列触发器进行设置，还有一个好处，即只有在使用＆＃34;消费计划＆＃34;运行时才支付Azure功能。定价选项。

这是一个概述Azure功能定价如何工作的链接：

  

https://buildazure.com/2016/10/11/how-azure-functions-pricing-works/

Answer 3

好吧，Rob的评论让我进入了服务管理库，然后将我带到Azure自动化和Runbook。我认为这最终将成为解决方案。我可以使用PowerShell cmdlet创建Runbook，它将查看存储队列，如果找到任何消息，它可以创建/部署Worker Role的新实例，该实例将在启动时查看队列并开始处理任何消息。棘手的部分看起来正在关闭工人角色。我发现的自毁/自杀云服务示例似乎只是杀死了多个实例，但不是最后一个实例。因为我只有一个实例在运行，所以我认为我不能让它自杀并使其进入未分配状态。我认为解决方案是再次使用Runbook。让Worker Role将“已完成”消息写入另一个队列，并使预定的Runbook每隔x分钟观察一次该队列。如果找到消息，请停止并取消分配辅助角色。鉴于函数有一个硬运行时间限制，我不能使用它。云服务为我提供了比WebJobs / Web App Service计划更多的资源选择（更精细的VM类型）。