你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

后台作业

许多类型的应用程序需要运行与用户界面 (UI) 无关的后台任务。 例如包括批处理作业、密集处理型任务，以及长时间运行的过程，例如工作流。 后台作业无需用户交互就可执行 -- 应用程序可以启动作业，并继续处理来自用户的交互请求。 这有助于减少应用程序 UI 上的负载，从而提高可用性，降低交互响应时间。

例如，如果应用程序需要生成用户上传的图像缩图，可以后台作业的形式执行此操作，并在完成时会缩图保存到存储中，用户无需等待过程完成。 同样地，下单的用户可以启动一个后台工作流来处理订单，同时，UI 可让用户继续浏览 Web 应用。 当后台作业完成时，可以更新存储的订单数据，并将确认订单的电子邮件发送给用户。

考虑是否将任务作为后台作业执行时，主要的准则是：是否可以在无需用户交互的情况下运行该任务，且 UI 无需等待作业完成。 在完成之前需要用户或 UI 等待的任务不适合作为后台作业运行。

后台作业的类型

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

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

触发器

可通过多种不同的方式启动后台作业。 这些方式属于以下类别之一：

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

事件驱动的触发器

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

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

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

计划驱动的触发器

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

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

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

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

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

返回结果

后台作业通过 UI 或调用后台任务的进程，以异步方式在独立进程甚至不同的位置运行。 在理想情况下，后台任务是“即发即弃”的操作，其执行进度不会影响 UI 或调用进程。 这意味着，调用进程不会等待任务完成。 因此无法自动检测任务的结束时间。

如果需要后台任务与调用任务通信以指示进度或完成状态，则必须为此实施一种机制。 下面是一些示例：

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

宿主环境

可以使用各种不同的 Azure 平台服务来托管后台任务：

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

以下各节详细介绍这些选项，并提供相关注意事项，帮助你选择适当的选项。

Azure Web 应用和 Web 作业

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

配置 Web 作业时：

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

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

Azure Web 作业具有以下特征：

• 安全性：Web 作业受 Web 应用的部署凭据保护。
• 支持的文件类型：可以使用命令脚本 (.cmd)、批处理文件 (.bat)、PowerShell 脚本 (.ps1)、Bash shell 脚本 (.sh)、PHP 脚本 (.php)、Python 脚本 (.py)、JavaScript 代码 (.js) 和可执行程序（.exe、.jar 等等）来定义 Web 作业。
• “部署”：可以使用 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 配置 Web 作业。 可以使用与作业脚本位于同一根目录的配置文件（名为 settings.job）来提供作业的配置信息。 例如：
  • { "stopping_wait_time": 60 }
  • { "is_singleton": true }

注意事项

• 默认情况下，Web 作业会随 Web 应用缩放。 但是，可以通过将 is_singleton 配置属性设置为 true，将作业配置为在单个实例上运行。 单个实例 Web 作业适用于不希望以同时进行多个实例的方式进行缩放或运行的任务（如重建索引、数据分析和类似任务）。
• 要将 Web 应用性能对任务的影响降到最低，请考虑在新的应用服务计划中创建空的 Azure Web 应用实例，以托管长时间运行或资源密集型的 WebJobs。

Azure Functions

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

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

注意事项

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

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

如果工作负荷已在其中运行，则专用计划最适合后台作业。 如果虚拟机利用不充分，可以在同一台虚拟机上对其运行并共享计算成本。

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

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

Azure 虚拟机

实施后台任务时，可以避免将其部署到 Azure Web 应用，但有时这些选项可能不方便。 典型的示例包括 Windows 服务、第三方实用程序和可执行程序。 另一个示例是针对托管应用程序以外的执行环境所编写的程序。 例如，它可能是你想要从 Windows 或 .NET 应用程序执行的 Unix 或 Linux 程序。 可以为 Azure 虚拟机选择各种操作系统，并在该虚拟机上运行服务或可执行文件。

若要确定何时使用虚拟机，请参阅 Azure 应用服务s, Cloud Services and Virtual Machines comparison（Azure 应用程序服务、云服务和虚拟机的比较）。 有关虚拟机选项的信息，请参阅 Azure 中的 Windows 虚拟机大小。 有关虚拟机可用的操作系统和预建映像的详细信息，请参阅 Azure 虚拟机市场。

若要在独立的虚拟机中启动后台任务，可以从多个选项中进行选择：

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

有关如何启动后台任务的详细信息，请参阅前面的触发器部分。

注意事项

在确定是否要在 Azure 虚拟机中部署后台任务时，请注意以下几点：

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

有关详细信息，请参阅：

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

Azure Batch

如果需要在数十、数百或数千个 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 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 或应用程序的其他部分，后台任务可能有不同的安全要求或限制。 通过使用单独的计算实例，可以为任务指定不同的安全环境。 还可以使用模式（例如守护程序）将后台计算实例与 UI 相隔离，以最大程度地提供安全性和隔离性。

• 性能：可以选择专门与任务的性能要求相符的后台任务计算实例类型。 这可能意味着，当任务无需与 UI 具有相同处理功能时，可以使用更便宜的计算选项；或者如果任务需要附加的容量和资源，则使用更大的实例。

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

• 成本：添加计算实例来执行后台任务会增加托管成本。 应该仔细考虑如何在添加容量与产生的成本之间做出取舍。

有关详细信息，请参阅领导选拔模式和使用者竞争模式。

冲突

如果有后台作业的多个实例，这些实例可能会争用对资源和服务（例如数据库和存储）的访问权。 这种并发访问可能会导致资源争用情况，从而造成服务可用性及存储中数据完整性的冲突。 可以使用悲观锁定方法来解决资源争用。 这可以防止任务的竞争实例同时访问某个服务或损坏数据。

另一种解决冲突的方法是将后台任务定义为单一实例，以便只有一个运行中的实例。 但是，这会消除多实例配置可提供的可靠性和性能优势。 当 UI 可以提供足够的工作让多个后台任务保持繁忙时尤其如此。

必须确保后台任务可以自动重新启动，并且有足够的容量来应对需求高峰。 这可以通过将足够的资源分配给计算实例、实施队列机制（可存储请求以便日后续需求降低时执行）或使用这些方法的组合来实现此目的。

协调

后台任务可能很复杂，需要执行多个不同的任务来生成结果或满足所有要求。 在这些方案中，住往会将任务分割成可由多个使用者执行的较小离散步骤或子任务。 多步骤操作可能更有效率且更具弹性，因为单个步骤可以在多个作业中重复使用。 还可以轻松地添加、删除或修改步骤的顺序。

协调多个任务和步骤可能相当困难，但可以参考三种常见的模式来实施解决方案：

• 将一个任务分解成多个可重复使用的步骤。 对于处理的信息，应用程序可能需要执行复杂性不一的各种任务。 实施此应用程序的一种直接但有弹性的方法是将这种处理当作单一模块来执行。 但是，这种方法可能会降低重构代码、优化代码或在应用程序的其他位置需要相同处理的部分时重复使用代码的机会。 有关详细信息，请参阅管道和筛选器模式。

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

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

复原注意事项

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

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

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

• 必须将消息或进程消息启动的后台任务设计为处理不一致情况，例如消息以错误顺序到达、消息重复导致错误（通常称为有害消息）和消息传送多次。 考虑以下情况：

  • 必须按特定顺序处理消息，例如，根据数据的现有数据值更改数据的消息（例如，将值添加到现有值）可能不以其原始发送顺序到达。 或者，可能因为每个实例上的负载不同，后台任务的不同实例按不同的顺序处理消息。 必须按特定顺序处理的消息应该包括序号、键，或者可由后台任务用来确保按正确顺序处理这些消息的其他某个指示器。 如果使用 Azure 服务总线，可以使用消息会话来保证传送顺序。 但是，尽可能设计好过程，使消息顺序变得不重要的思路通常更有效率。

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

  • 系统为队列保证至少一次传送机制，但队列可能会多次传送同一条消息。 此外，如果在处理消息之后、从队列中删除消息之前后台任务失败，消息将可再次处理。 后台任务应该具有幂等性，这意味着多次处理同一条消息不会导致错误，或者使应用程序的数据不一致。 某些操作原生就是幂等的，例如，将存储的值设置为特定的新值。 但是，有些操作（例如，将值添加到现有的存储值而不检查存储值是否仍与最初发送的消息相同）会导致不一致情况。 可将 Azure 服务总线队列配置为自动删除重复消息。 若要详细了解“至少一次”消息传送的相关难题，请参阅幂等消息处理指南。

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

缩放和性能注意事项

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

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

• 当后台任务的执行功能不同于应用程序的其他部分（例如，UI 或数据访问层等组件）时，在另一计算服务中将后台任务托管在一起可让 UI 和后台任务单独进行缩放，便于管理负载。 如果多个后台任务彼此有明显不同的执行功能，请考虑将它们分割并单独缩放每个类型。 但请注意，这可能会增加运行时成本。

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

• 必须针对缩放设计后台任务。 例如，后台任务必须能够动态检测正在使用的存储队列数，以侦听相应的队列或向其发送消息。

• 默认情况下，Web 作业会随着其关联的 Azure Web 应用实例进行缩放。 但是，如果只想要将 Web 作业当作单个实例运行，可以创建包含 JSON 数据 { "is_singleton": true } 的 Settings.job 文件。 这会强制 Azure 只运行 Web 作业的一个实例，即使关联的 Web 应用有多个实例。 对于必须以单个实例运行的计划作业而言，这可能是有用的方法。

后续步骤

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

相关资源

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