用于聚合的 Azure WebJobs答案

【问题标题】：Azure WebJobs for Aggregation用于聚合的 Azure WebJobs
【发布时间】：2015-04-22 09:26:27
【问题描述】：

我正在尝试找出一种解决方案，通过使用 Azure 队列和 WebJobs 来获取数据，以重复聚合数千个远程 XML 和 JSON 数据文件。

基本上，将在 Azure 网站/应用程序上调用某种类型的输入端点 URL（使用数据 URL 作为参数）。它应该触发一个 WebJobs 后台作业（或者它可以持续运行并定期检查队列是否有新工作），获取数据 URL，然后在完成时回调一个外部端点 URL。

现在主要关注的是数量及其性能/扩展/定价开销。每 10-60 分钟将获取大约 10,000 个 URL（大多数 URL 每 60 分钟获取一次）。对于这种重复性大批量后台作业的场景，我有几个问题：

Azure WebJobs（或 Workers？）是否适合在此数量上进行后台处理，并且能够相应地进行扩展？
对于此类卷，哪个 Azure 网站层最适合（比较 http://azure.microsoft.com/en-us/pricing/details/app-service/）？还是只有云或虚拟机才能在这种规模下工作？

感谢任何建议或提示。

【问题讨论】：

标签： azure azure-web-roles azure-webjobs azure-webjobssdk

【解决方案1】：

是的，Azure WebJobs 是解决此问题的理想解决方案。 Azure WebJobs 将随着您的 Web 应用程序（以前称为网站）进行扩展。因此，如果您增加 Web 应用程序实例，您也将增加您的 Web 作业实例。有办法防止这种情况，但这是默认行为。您还可以设置自动缩放以根据您指定的 CPU 或其他性能规则自动缩放您的 Web 应用程序。
通过将 Web 作业部署到与部署 WFE 的 Web 应用程序不同的 Web 应用程序，也可以独立于 Web 前端 (WFE) 扩展 Web 作业。这样做的好处是不占用 WFE 正在使用的机器资源（CPU、RAM），同时让您可以灵活地将 Web 作业实例扩展到适当的级别。不说这是你应该做的。您必须进行一些负载测试以确定此策略是否适合（或必要）适合您的情况。
您应该至少考虑您的 Web 应用程序的基本层。如果您需要，这将允许您横向扩展至 3 个实例，并且还可以消除免费和共享计划所具有的 CPU 和网络 I/O 限制。

至于队列，我绝对建议使用 WebJobs SDK 并让 JobHost（来自 SDK）为您调用您的网络作业功能，而不是轮询队列。这是一个非常巧妙的解决方案，让您不必编写基础架构代码来从队列中检索消息、管理消息可见性、删除消息等。对于这个工作示例和快速开始构建您的 Web 作业这样，请查看 Azure WebJobs SDK 队列 模板为您生成的示例代码。

【讨论】：

谢谢瑞克。关于您的建议的其他一些问题：（1）在定价页面上，它说（正如您也说过）基本层最多可以扩展到 3 个实例，实例也可以自动扩展Azure 基于 Web 应用程序的负载和流量，还是我们创建每个实例并分别部署到每个实例？
(2) 我假设为基本层列出的定价是每个实例（例如 B1 是每个实例约 56 美元，最多 3 个实例），所以如果应用程序自动扩展定价将自动增加吧？！
(3) 作为一个猜测（虽然我稍后会运行一些基准测试代码），您认为重复获取的吞吐量（例如可用的工作线程、每分钟的任务数等）是多少URLs（以 I/O 为中心的工作而不是以 CPU 为中心），考虑到一个 WebJob 在一个具有 1-2 个内核的实例上运行？
实例不会自动横向扩展。要自动缩放，您需要为您的 Web 应用程序配置自动缩放。这是解释这一点的文件。 azure.microsoft.com/en-us/documentation/articles/…。您引用的定价页面是按实例定价。