后台作业

许多类型的应用程序需要独立于用户界面（UI）运行的后台任务。 示例包括批处理作业、密集型处理任务和长时间运行的进程，例如工作流。 无需用户交互即可执行后台作业-应用程序可以启动作业，然后继续处理来自用户的交互式请求。 这有助于最大程度地减少应用程序 UI 上的负载，从而提高可用性并减少交互式响应时间。

例如，如果应用程序需要生成用户上传的图像的缩略图，则可以将其作为后台作业执行此作，并在完成时将缩略图保存到存储中，而无需用户等待该过程完成。 同样，下订单的用户可以启动处理订单的后台工作流，而 UI 允许用户继续浏览 Web 应用。 后台作业完成后，它可以更新存储的订单数据，并向确认订单的用户发送电子邮件。

考虑是否将任务实现为后台作业时，主要条件是任务是否可以在没有用户交互的情况下运行，而无需 UI 等待作业完成。 要求用户或 UI 在完成时等待的任务可能不适合作为后台作业。

后台作业的类型

后台作业通常包含以下类型的一个或多个作业：

• CPU 密集型作业，例如数学计算或结构模型分析。
• I/O 密集型作业，例如执行一系列存储事务或索引文件。
• 批处理作业，例如夜间数据更新或有计划的处理。
• 长时间运行的工作流，例如订单履行或预配服务和系统。
• 将任务移交给更安全的位置进行处理的敏感数据处理。 例如，您可能不想在 web 应用程序中处理敏感数据。 相反，您可以使用 Gatekeeper 模式等模式，将数据转移到能够访问受保护的存储的已隔离后台进程。

触发器

可通过多种不同的方式启动后台作业。 它们分为以下类别之一：

• 事件驱动的触发器。 任务是响应某个事件而启动的，这通常是由用户的某个操作或工作流中的一个步骤引发的。
• 调度驱动触发器。 基于计时器按计划调用任务。 这可能是定期计划，或者指定在以后某时刻运行的一次性调用。

事件驱动的触发器

事件驱动的调用使用触发器启动后台任务。 使用事件驱动触发器的示例包括：

• UI 或另一个作业将消息放入队列。 该消息包含有关已执行动作的数据，例如用户下订单。 后台任务将侦听此队列，并检测新消息是否已到达。 它会读取消息，并将其中的数据用作后台作业的输入。 此模式称为 基于消息的异步通信。
• UI 或其他作业保存或更新存储中的值。 后台任务监视存储并检测更改。 它读取数据并将其用作后台作业的输入。
• UI 或其他作业向终结点发出请求，例如 HTTPS URI 或作为 Web 服务公开的 API。 它传递用于完成后台任务所需的数据，作为请求的一部分。 终结点或 Web 服务调用后台任务，将数据用作其输入。

适用于事件驱动调用的任务的典型示例包括图像处理、工作流、向远程服务发送信息、发送电子邮件以及在多租户应用程序中预配新用户。

时间表驱动的触发器

计划驱动的调用使用计时器启动后台任务。 使用计划驱动触发器的示例包括：

• 在应用程序本地运行的计时器或作为应用程序操作系统一部分的计时器定期调用后台任务。
• 在不同应用程序中运行的计时器（例如 Azure 逻辑应用）定期向 API 或 Web 服务发送请求。 API 或 Web 服务调用后台任务。
• 单独的进程或应用程序启动一个计时器，该计时器会导致在指定的时间延迟后或在特定时间调用后台任务一次。

适用于计划驱动调用的任务的典型示例包括批处理例程（例如根据用户最近的行为更新相关产品列表）、常规数据处理任务（例如更新索引或生成累积结果）、每日报表的数据分析、数据保留清理和数据一致性检查。

如果使用必须作为单个实例运行的计划驱动任务，请注意以下事项：

• 如果正在运行计划程序（例如使用 Windows 计划任务的虚拟机）的计算实例进行缩放，将有多个正在运行的计划程序实例。 这些操作可能会启动任务的多个实例。 有关此内容的详细信息，请阅读这篇关于幂等性的博客文章。
• 如果任务运行的时间超过计划程序事件之间的时间段，则计划程序可能会在前一个任务仍在运行期间启动该任务的另一个实例。

返回结果

后台作业在单独的进程中（甚至位于单独的位置）与调用后台任务的 UI 或进程异步执行。 理想情况下，后台任务是“一次触发，无需管理”操作，其执行进度不会影响 UI 或调用进程。 这意味着调用过程不会等待任务完成。 因此，它无法自动检测任务何时结束。

如果需要后台任务与调用任务通信以指示进度或完成，则必须为此实现机制。 一些示例包括：

• 将状态指示器值写入 UI 或调用方任务可访问的存储，以便在需要时监视或检查此值。 后台任务必须返回到调用方的其他数据可以放置在同一存储中。
• 建立供 UI 或调用方监听的回复队列。 后台任务可将消息发送到指示状态和完成情况的队列。 后台任务需要返回给调用方的数据可以放入消息中。 如果使用 Azure 服务总线，可以使用 ReplyTo 和 CorrelationId 属性来实现此功能。
• 把后台任务中的 API 或终结点公开，使 UI 或调用方可以访问，以获取状态信息。 后台任务必须返回给调用方的数据，应包含在响应中。
• 让后台任务通过 API 回调 UI 或调用方，以指示预定义时间点或完成时的状态。 这可能是通过本地引发的事件或通过发布和订阅机制引发的。 后台任务必须返回给调用方的数据可以包含在请求或事件负载中。

托管环境

可以使用一系列不同的 Azure 平台服务来托管后台任务：

• Azure Web 应用和 Web 作业。 可以使用 WebJobs 根据 Web 应用上下文中的一系列不同类型的脚本或可执行程序执行自定义作业。
• Azure Functions。 可以将函数用于运行时间不长的后台作业。 另一个用例是，如果工作负荷已托管在应用服务计划中，并且未充分利用。
• Azure 虚拟机。 如果你有 Windows 服务或想要使用 Windows 任务计划程序，则通常会在专用虚拟机中托管后台任务。
• Azure Batch。 Batch 是一种平台服务，用于计划要在托管虚拟机集合上运行的计算密集型工作。 它可以自动缩放计算资源。
• Azure Kubernetes 服务（AKS）。 Azure Kubernetes 服务为 Azure 上的 Kubernetes 提供托管环境。
• Azure 容器应用。 Azure Container Apps 使你能够基于容器构建无服务器微服务。

以下部分更详细地介绍了这些选项，并包括有助于选择相应选项的注意事项。

Azure Web 应用和 Web 作业

可以使用 Azure WebJobs 作为 Azure Web 应用中的后台任务执行自定义作业。 WebJobs 作为连续进程在 Web 应用的上下文中运行。 WebJobs 也会在响应 Azure Logic Apps 的触发事件或外部因素（例如存储 Blob 和消息队列的变更）时运行。 作业可以按需启动和停止，并正常关闭。 如果连续运行的 WebJob 失败，它将自动重启。 重试和错误操作是可配置的。

配置 Web 作业时：

• 如果希望作业响应事件驱动的触发器，则应将其配置为 连续运行。 脚本或程序存储在名为 site/wwwroot/app_data/jobs/continuous 的文件夹中。
• 如果希望作业响应计划驱动的触发器，则应将其配置为 按计划运行。 脚本或程序存储在名为 site/wwwroot/app_data/jobs/triggered 的文件夹中。
• 如果在配置作业时选择 “按需运行 ”选项，则启动作业时，它将执行与 “按计划运行” 选项相同的代码。

Azure WebJobs 在 Web 应用的沙盒中运行。 这意味着他们可以访问环境变量，并与 Web 应用共享信息，例如连接字符串。 作业有权访问运行该作业的计算机的唯一标识符。 名为 AzureWebJobsStorage 的连接字符串提供对应用程序数据的 Azure 存储队列、Blob 和表的访问权限，以及访问用于消息传递和通信的服务总线。 名为 AzureWebJobsDashboard 的连接字符串提供对作业作日志文件的访问权限。

Azure WebJobs 具有以下特征：

• 安全性：WebJobs 受 Web 应用的部署凭据的保护。
• 支持的文件类型：可以使用命令脚本（）、批处理文件.bat（）、PowerShell 脚本（.cmd）、Bash shell 脚本（.ps1）、PHP 脚本（.sh.php）、Python 脚本（.py）、JavaScript 代码（.js）和可执行程序（.exe.jar等）来定义 WebJobs。
• 部署：可以使用 Azure 门户、 Visual Studio、 Azure WebJobs SDK 或直接将它们复制到以下位置来部署脚本和可执行文件：
  • 对于触发的执行：site/wwwroot/app_data/jobs/triggered/{job name}
  • 对于连续执行：site/wwwroot/app_data/jobs/continuous/{job name}
• 日志记录：Console.Out 被视为（标记为）INFO。 Console.Error 被视为 ERROR。 可以使用 Azure 门户访问监视和诊断信息。 可以直接从站点下载日志文件。 它们保存在以下位置：
  • 对于触发的执行：Vfs/data/jobs/triggered/jobName
  • 对于连续执行：Vfs/data/jobs/continuous/jobName
• 配置：可以使用门户、REST API 和 PowerShell 配置 WebJobs。 可以使用与作业脚本相同的根目录中名为 settings.job 的配置文件来提供作业的配置信息。 例如：
  • { "stopping_wait_time": 60 }
  • { "is_singleton": true }

注意事项

• 默认情况下，WebJobs 使用 Web 应用进行缩放。 但是，可以将作业配置为在单个实例上运行，方法是将 is_singleton 配置属性设置为 true。 对于不希望扩展或以多实例同步运行的任务，例如重新编制索引、数据分析和类似的任务，单实例 WebJobs 非常适用。
• 为了尽量减少作业对 Web 应用性能的影响，请考虑在新应用服务计划中创建一个空的 Azure Web 应用实例来托管长时间运行的或资源密集型的 Web 作业。

Azure Functions（Azure 功能服务）

类似于 WebJobs 的选项是 Azure Functions。 此服务是无服务器服务，最适合短时间内运行的事件驱动触发器。 当配置为在设置时间运行时，函数还可用于通过计时器触发器运行计划作业。

对于大型长时间运行的任务，不建议使用 Azure Functions，因为它们可能会导致意外超时问题。 但是，根据托管计划，可考虑将其用于日程安排驱动的触发器。

注意事项

如果后台任务预期在短时间内运行以响应事件，请考虑在消耗计划中运行该任务。 执行时间可配置为最长时间。 运行时间更长的函数成本更高。 此外，消耗更多内存的 CPU 密集型作业可能更昂贵。 如果您在任务中将其他触发器用于服务，则这些触发器将单独计费。

如果你有许多时间短但预计持续运行的任务，则高级计划更合适。 此计划更昂贵，因为它需要更多的内存和 CPU。 好处是可以使用虚拟网络集成等功能。

如果工作负荷已在其中运行，则专用计划最适合后台作业。 如果 VM 使用率不足，则可以在同一 VM 上运行 VM 并共享计算成本。

有关详细信息，请参阅以下文章：

• Azure Functions 主机选项
• Azure Functions 的计时器触发器

Azure 虚拟机

后台任务可能以阻止其部署到 Azure Web 应用的方式实现，或者这些选项可能不方便。 典型示例包括 Windows 服务和第三方实用工具和可执行程序。 另一个示例可能是为与托管应用程序不同的执行环境编写的程序。 例如，它可能是你想要从 Windows 或 .NET 应用程序执行的 Unix 或 Linux 程序。 可以从 Azure 虚拟机的一系列作系统中进行选择，并在该虚拟机上运行服务或可执行文件。

若要帮助你选择何时使用虚拟机，请参阅 Azure 应用服务、云服务和虚拟机比较。 有关虚拟机选项的信息，请参阅 Azure 中 Windows 虚拟机的大小。 有关可用于虚拟机的作系统和预生成映像的详细信息，请参阅 Azure 虚拟机市场。

若要在单独的虚拟机中启动后台任务，有一系列选项：

• 可以通过向任务公开的终结点发送请求，直接从应用程序执行任务。 这会传入任务所需的任何数据。 此终结点将调用该任务。
• 可以使用所选作系统中可用的计划程序或计时器将任务配置为按计划运行。 例如，在 Windows 上，可以使用 Windows 任务计划程序来执行脚本和任务。 或者，如果已在虚拟机上安装 SQL Server，则可以使用 SQL Server 代理执行脚本和任务。
• 可以使用 Azure 逻辑应用将消息添加到任务侦听的队列，或通过向任务公开的 API 发送请求来启动任务。

请参阅前面的“ 触发器” 部分，详细了解如何启动后台任务。

注意事项

在决定是否在 Azure 虚拟机中部署后台任务时，请考虑以下几点：

• 在单独的 Azure 虚拟机中托管后台任务可提供灵活性，并允许精确控制启动、执行、计划和资源分配。 但是，如果必须部署虚拟机来运行后台任务，则会增加运行时成本。
• 没有用于监视 Azure 门户中的任务的工具，也没有针对失败任务的自动重启功能，尽管可以使用 Azure 资源管理器 Cmdlet 监视虚拟机的基本状态和管理它。 但是，没有用于控制计算节点中的进程和线程的设施。 通常，在使用虚拟机时，需要额外花费精力来实现一种机制，该机制用于从任务中的监测工具以及虚拟机中的操作系统收集数据。 一种可能合适的解决方案是使用 适用于 Azure 的 System Center Management Pack。
• 可以考虑创建通过 HTTP 终结点公开的监视探测。 这些探测的代码可以执行运行状况检查、收集作信息和统计信息，或整理错误信息并将其返回到管理应用程序。 有关详细信息，请参阅运行状况终结点监视模式。

有关详细信息，请参见:

• 虚拟机
• Azure 虚拟机常见问题解答

Azure 批处理

如果需要跨数十、数百或数千个 VM 运行大型并行高性能计算（HPC）工作负荷，请考虑 Azure Batch 。

Batch 服务预配 VM、将任务分配给 VM、运行任务并监视进度。 Batch 可以自动横向扩展 VM 以响应工作负荷。 Batch 还提供作业调度功能。 Azure Batch 支持 Linux 和 Windows VM。

注意事项

Batch 在固有并行的工作负载上运行良好。 它还可以在结束时执行减少步骤的并行计算，或者针对需要在节点之间传递消息的并行任务运行 消息传递接口（MPI）应用程序 。

Azure Batch 作业在节点池（VM）上运行。 一种方法是仅在需要时分配池并在作业完成后将其删除。 这会最大化利用率，因为节点不处于空闲状态，但作业必须等待分配节点。 或者，可以提前创建池。 此方法可最大程度地减少作业启动所需的时间，但可能会导致节点处于空闲状态。 有关详细信息，请参阅 池和计算节点生存期。

有关详细信息，请参见:

• 什么是 Azure Batch？
• 使用 Batch 开发大规模并行计算解决方案
• 适用于大规模计算工作负荷的 Batch 和 HPC 解决方案

Azure Kubernetes 服务

Azure Kubernetes 服务（AKS）管理托管的 Kubernetes 环境，以便轻松部署和管理容器化应用程序。

容器可用于运行后台作业。 一些优势包括：

• 容器支持高密度托管。 可以在容器中隔离后台任务，同时在每个 VM 中放置多个容器。
• 容器业务流程协调程序处理内部负载均衡、配置内部网络和其他配置任务。
• 可以根据需要启动和停止容器。
• Azure 容器注册表允许在 Azure 边界内注册容器。 这附带了安全性、隐私和邻近性优势。

注意事项

• 需要了解如何使用容器业务流程协调程序。 根据 DevOps 团队的技能集，这可能不是问题。

有关详细信息，请参见:

• Azure 中的容器概述

• 专用 Docker 容器注册表简介

Azure 容器应用 (Azure Container Apps)

Azure Container Apps 使你能够基于容器构建无服务器微服务。 Container Apps 的独特功能包括：

• 针对运行常规用途容器进行了优化，特别是对于跨部署在容器中的多个微服务的应用程序。
• 由 Kubernetes 和开源技术（如 Dapr、Kubernetes 事件驱动自动伸缩（KEDA）以及 envoy）驱动。
• 支持具有 服务发现 和 流量拆分等功能的 Kubernetes 样式应用和微服务。
• 通过支持基于流量的缩放并从队列等事件源拉取数据（包括缩放为零）来启用事件驱动型应用程序体系结构。
• 支持长时间运行的进程，并且可以运行 后台任务。

注意事项

Azure Container Apps 不提供对基础 Kubernetes API 的直接访问。 如果需要访问 Kubernetes API 和控制平面，应使用 Azure Kubernetes 服务。 但是，如果要构建 Kubernetes 风格的应用程序，并且不需要直接访问所有原生 Kubernetes API 和群集管理，则 Container Apps 可提供基于最佳做法的完全托管体验。 由于这些原因，许多团队可能更愿意使用 Azure Container Apps 来开始构建容器微服务。

有关详细信息，请参见:

• Azure 容器应用概述

您可以使用快速入门开始创建您的第一个容器应用。

分区

如果决定在现有计算实例中包含后台任务，则必须考虑这将如何影响计算实例的质量属性和后台任务本身。 这些因素将帮助你决定是将任务与现有计算实例并置，还是将它们分离到单独的计算实例中：

• 可用性：后台任务可能不需要与应用程序的其他部分具有相同的可用性级别，尤其是直接涉及用户交互的 UI 和其他部分。 由于可将操作排入队列，后台任务可能更容许延迟、重试的连接失败，以及影响可用性的其他因素。 但是，必须有足够的容量来防止请求积压，这可能会阻塞队列并影响整个应用程序。

• 可伸缩性：后台任务可能具有不同于 UI 和应用程序的交互式部分的可伸缩性要求。 缩放 UI 可能需要满足需求高峰，而未完成的后台任务可能会在不太繁忙的时间内通过更少的计算实例完成。

• 复原能力：如果这些任务的请求可以排队或推迟到任务再次可用，则仅托管后台任务的计算实例的失败可能不会对整个应用程序造成致命影响。 如果计算实例或任务可以在适当的时间间隔内重启，则应用程序的用户可能不会受到影响。

• 安全性：后台任务的安全要求或限制可能与 UI 或应用程序的其他部分不同。 通过使用单独的计算实例，可以为任务指定不同的安全环境。 还可以使用 Gatekeeper 等模式将后台计算实例与 UI 隔离，以便最大程度地提高安全性和分离性。

• 性能：可以选择后台任务的计算实例类型，以专门匹配任务的性能要求。 这可能意味着如果任务不需要与 UI 相同的处理功能，可以选择成本较低的计算选项；而如果任务需要额外的容量和资源，则可能需要更大的实例。

• 可管理性：后台任务可能具有与主应用程序代码或 UI 不同的开发和部署节奏。 将它们部署到单独的计算实例可以简化更新和版本控制。

• 成本：添加计算实例以执行后台任务会增加托管成本。 应仔细考虑额外的容量与这些额外成本之间的权衡。

有关详细信息，请参阅 “领导者选举”模式 和 竞争消费者模式。

冲突

如果有多个后台作业实例，他们可能会争用对资源和服务（例如数据库和存储）的访问权限。 此并发访问可能会导致资源争用，这可能会导致服务的可用性和存储中数据的完整性发生冲突。 您可以通过使用悲观锁定的方法来解决资源竞争问题。 这可以防止任务的竞争实例同时访问服务或损坏数据。

解决冲突的另一种方法是将后台任务定义为单例，这样永远只有一个实例在运行。 但是，这消除了多实例配置可以提供的可靠性和性能优势。 特别是在 UI 能够提供足够的工作量以使多个后台任务保持繁忙的情况下，这一点尤为明显。

必须确保后台任务可以自动重启，并且有足够的容量来应对需求高峰。 可以通过分配具有足够资源的计算实例来实现此目的，方法是实现一种排队机制，该机制可以在需求减少时存储后续执行请求，或使用这些技术的组合。

协调

后台任务可能比较复杂，可能需要执行多个单独的任务才能生成结果或满足所有要求。 在这些方案中，通常将任务划分为可由多个使用者执行的较小谨慎步骤或子任务。 多步骤作业可以更高效、更灵活，因为单个步骤可能在多个作业中可重用。 还可以轻松添加、删除或修改步骤的顺序。

协调多个任务和步骤可能很有挑战性，但有三种常见模式可用于指导解决方案的实现：

• 将任务分解为多个可重用步骤。 应用程序可能需要对处理的信息执行各种复杂度不同的任务。 实现此应用程序的简单但不灵活的方法可能是将此处理作为整体模块执行。 但是，此方法可能会减少重构代码、优化代码或重用代码的机会（如果应用程序中的其他位置需要相同处理部分）。 有关详细信息，请参阅 管道和筛选器模式。

• 管理任务的执行步骤。 应用程序可以执行由多个步骤构成的任务（其中一些步骤可能调用远程服务或访问远程资源）。 各个步骤可以彼此独立，但它们由实施任务的应用程序逻辑进行协调。 有关详细信息，请参阅计划程序代理监督程序模式。

• 管理任务步骤失败后的恢复。 如果一个或多个步骤失败，应用程序可能需要撤消由一系列步骤（共同定义最终一致性操作）执行的工作。 有关详细信息，请参阅 补偿事务模式。

复原注意事项

后台任务必须具有复原能力，才能为应用程序提供可靠的服务。 在规划和设计后台任务时，请考虑以下几点：

• 后台任务必须能够正常处理重启，而不会损坏数据或导致应用程序不一致。 对于长时间运行的任务或多步骤任务，请考虑使用检查点，方法是在永久性存储中保存作业状态，或者在队列中将作业状态另存为消息（如果适当）。 例如，可以在队列中的消息中保存状态信息，并使用任务进度以增量方式更新此状态信息，以便可以从上一个已知的良好检查点处理任务，而不是从头开始重启。 使用 Azure 服务总线队列时，可以使用消息会话来启用相同的方案。 会话允许使用 SetState 和 GetState 方法保存和检索应用程序处理状态。 有关设计可靠的多步骤进程和工作流的详细信息，请参阅 计划程序代理监督程序模式。

• 使用队列来与后台任务通信时，队列可以充当缓冲区，用于在应用程序超过一般负载时，存储发送给任务的请求。 这样，任务便可以在相对空闲期间与 UI 同步。 这也意味着重启不会阻止 UI。 有关详细信息，请参阅 Queue-Based 负载调配模式。 如果某些任务比其他任务更重要，请考虑实现 优先级队列模式 ，以确保这些任务在不太重要的任务之前运行。

• 由消息或进程消息启动的后台任务必须设计为处理不一致（例如消息无序到达）、反复导致错误的消息（通常称为 有害消息）和多次传递的消息。 请考虑以下事项：

  • 必须按特定顺序处理的消息（例如，根据现有数据值更改数据的消息（例如，向现有值添加值）可能无法按发送的原始顺序到达。 或者，由于每个实例上的负载不同，它们可能按不同的顺序由后台任务的不同实例处理。 必须按特定顺序处理的消息应包括序列号、键或其他一些指示符，后台任务可以使用这些指示器来确保按正确的顺序处理它们。 如果使用 Azure 服务总线，可以使用消息会话来保证传递顺序。 然而，如果可能，设计过程通常更高效，以使消息顺序不重要。

  • 一般而言，后台任务会在队列中扫视消息，这会暂时向其他消息使用者隐藏消息。 然后，它会在消息成功处理后将其删除。 如果后台任务在处理消息时失败，该消息将在速览超时过期后重新出现在队列中。 它将由任务的另一个实例处理，或在此实例的下一个处理周期内进行处理。 如果消息一直导致使用者出错，则会阻止任务、队列，并最终在队列填满时阻止应用程序本身。 因此，检测和删除队列中的有害消息至关重要。 如果使用 Azure 服务总线，导致出错的消息可以自动或手动移到关联的死信队列。

  • 系统为队列保证至少一次传送机制，但队列可能会多次传送同一条消息。 此外，如果后台任务在处理消息后失败，但在从队列中删除消息之前，该消息将再次可供处理。 后台任务应是幂等的，这意味着多次处理同一条消息不会导致应用程序数据出错或不一致。 某些操作原生就是幂等的，例如，将存储的值设置为特定的新值。 但是，如果不检查存储的值是否仍然与最初发送消息时相同就向其添加新值，这种操作将导致不一致。 可将 Azure 服务总线队列配置为自动删除重复的消息。 有关至少传递一次消息的挑战的详细信息，请参阅 有关幂等消息处理的指南。

  • 某些消息传送系统（例如 Azure 队列存储和 Azure 服务总线队列）支持取消队列计数属性，该属性指示从队列中读取消息的次数。 这可用于处理重复消息和有害消息。 有关详细信息，请参阅 异步消息传送入门 和 幂等模式。

缩放和性能注意事项

后台任务必须提供足够的性能，以确保它们不会阻碍应用程序，也不会因为系统负载高时操作延迟而导致不一致。 通常，通过缩放托管后台任务的计算实例来提高性能。 在规划和设计后台任务时，请考虑以下关于可伸缩性和性能的要点：

• Azure 根据当前的需求和负载或预定义的计划，支持对 Web 应用和虚拟机托管的部署使用自动缩放（向外缩放和向内缩放）。 使用此功能可确保整个应用程序具有足够的性能功能，同时最大程度地降低运行时成本。

• 如果后台任务与应用程序的其他部分（例如 UI 或组件（如数据访问层）具有不同的性能功能，则托管后台任务在单独的计算服务中一起托管后台任务可让 UI 和后台任务独立缩放以管理负载。 如果多个后台任务具有明显不同的性能功能，请考虑单独划分和缩放每种类型。 但是，请注意，这可能会增加运行时成本。

• 仅仅缩放计算资源可能不足以防止负载下的性能丢失。 可能还需要缩放存储队列和其他资源，以防止整个处理链的单一点成为瓶颈。 此外，请考虑其他限制，例如存储和应用程序所依赖的其他服务的最大吞吐量和后台任务。

• 后台任务必须设计为可扩展。 例如，它们必须能够动态检测正在使用的存储队列数，以便侦听或将消息发送到相应的队列。

• 默认情况下，WebJobs 使用其关联的 Azure Web 应用实例进行缩放。 但是，如果希望 WebJob 仅作为单个实例运行，则可以创建一个 Settings.job 文件，其中包含 JSON 数据 { “is_singleton”： true }。 这强制 Azure 仅运行 Web 作业的一个实例，即使关联 Web 应用的多个实例也是如此。 对于必须仅作为单个实例运行的计划作业，这可以是一种有用的技术。

后续步骤

• 计算分区指南
• 异步消息传送入门
• 幂等模式

相关资源

• 基于队列的负载调节模式
• 优先级队列模式
• 管道和筛选器模式
• 计划程序代理监督模式
• 补偿事务模式
• 领导人选举模式
• 使用者竞争模式