0

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

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

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

  1. Azure WebJobs（或 Workers？）是否适合在此数量上进行后台处理，并且能够相应地进行扩展？

  2. 对于此类卷，哪个 Azure 网站层最适合（比较http://azure.microsoft.com/en-us/pricing/details/app-service/）？还是只有云或虚拟机才能以这种规模工作？

任何建议或提示表示赞赏。

4

1 回答 1

1

  1. 是的，Azure WebJobs 是一个理想的解决方案。Azure WebJobs 将随着您的 Web 应用程序（以前称为网站）进行扩展。因此，如果您增加 Web 应用程序实例，您也将增加您的 Web 作业实例。有办法防止这种情况，但这是默认行为。您还可以设置自动缩放以根据您指定的 CPU 或其他性能规则自动缩放您的 Web 应用程序。
    通过将 Web 作业部署到与部署 WFE 的 Web 应用程序不同的 Web 应用程序，也可以独立于 Web 前端 (WFE) 扩展 Web 作业。这样做的好处是不占用 WFE 正在使用的机器资源（CPU、RAM），同时让您可以灵活地将 Web 作业实例扩展到适当的级别。不说这是你应该做的。您将不得不进行一些负载测试，以确定此策略是否适合您的情况（或必要）。

  2. 您应该至少考虑您的 Web 应用程序的基本层。如果您需要，这将允许您横向扩展至 3 个实例，并且还可以消除免费和共享计划所具有的 CPU 和网络 I/O 限制。

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

在此处输入图像描述

于 2015-04-22T21:48:33.157 回答