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

有关开发后台作业的建议

  • 项目

适用于此 Azure 架构良好的框架可靠性清单建议：

RE：07 通过实施自我维持和自我修复措施，增强工作负载的复原能力和可恢复性。 使用基于基础结构的可靠性模式和基于软件的设计模式来处理组件故障和暂时性错误，将功能构建到解决方案中。 将功能构建到系统中，以检测解决方案组件故障，并在工作负荷继续完全或减少功能时自动启动纠正措施。

相关指南：暂时性故障 | 自我保存

本指南介绍了有关开发后台作业的建议。 后台作业自动运行，无需用户交互。 许多应用程序需要独立于 UI 运行的后台作业。

后台作业的一些示例包括批处理作业、密集型处理任务和长时间运行的进程，例如工作流。 应用程序启动作业并处理来自用户的交互式请求。 例如，如果应用程序需要生成用户上传的图像缩略图，则可以执行后台作业来生成缩略图并将其保存到存储。 用户无需等待进程完成。 另一个示例是客户下订单，该订单启动处理订单的后台工作流。 客户在后台作业运行时继续浏览 Web 应用。 后台作业完成后，它会更新存储的订单数据，并向客户发送电子邮件以确认订单。

后台作业有助于最大限度减少应用程序 UI 上的负载，从而提高可用性，缩短交互响应时间。

关键设计策略

若要选择要指定为后台作业的任务，请考虑该任务是否在没有用户交互的情况下运行，以及 UI 是否需要等待任务完成。 要求用户或 UI 在运行时等待的任务通常不适合后台作业。

评估后台作业的需求

后台作业的一些示例包括：

  • CPU 密集型作业，例如数学计算或结构模型分析。

  • I/O 密集型作业，例如运行一系列存储事务或索引文件。

  • 批处理作业，例如夜间数据更新或有计划的处理。

  • 长时间运行的工作流，例如订单履行或预配服务和系统。

  • 将任务传输到更安全的位置进行处理的敏感数据处理。 例如，可能不希望处理 Web 应用中的敏感数据。 而想使用守护程序模式等模式将数据传输到有权访问受保护存储的已隔离后台进程。

选择正确的触发器

使用以下方法启动后台作业：

事件驱动的触发器

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

  • UI 或其他作业将消息放置在队列中，如 Web-Queue-Worker 体系结构样式中所述。 该消息包含有关以前执行的操作的数据，例如下订单的客户。 后台作业监视此队列并检测新消息的到达。 它读取消息，并使用消息的数据作为后台作业的输入。 此模式称为 基于消息的异步通信。

  • UI 或其他作业保存或更新存储中的值。 后台作业监视存储并检测更改。 它读取数据并将其用作后台作业的输入。

  • UI 或其他作业向终结点发出请求，例如 HTTPS URI 或作为 Web 服务公开的 API。 作为请求的一部分，UI 或作业传输后台任务所需的数据。 终结点或 Web 服务调用后台任务，将数据用作其输入。

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

计划驱动的触发器

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

  • 在应用程序内部或作为应用程序操作系统的一部分在本地运行的计时器定期调用后台任务。

  • 在不同应用程序中运行的计时器（例如Azure 逻辑应用）定期向 API 或 Web 服务发送请求。 API 或 Web 服务调用后台任务。

  • 单独的进程或应用程序启动计时器，该计时器在时间延迟或特定时间后调用后台任务。

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

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

  • 如果运行计划程序（例如使用 Windows 计划任务的虚拟机（VM）的计算实例进行缩放，则运行计划的多个实例。 计划程序多个实例可以启动任务的多个实例。 有关详细信息，请参阅 软件系统中幂等的含义是什么？

  • 如果任务运行时间超过计划程序事件之间的时间段，则计划程序可能会在上一个任务运行时启动该任务的另一个实例。

将数据返回到工作负荷

后台作业在单独的进程中（甚至位于单独的位置）与调用后台作业的 UI 或进程异步运行。 理想情况下，后台作业会 触发和忘记 操作。 它们的运行时进度对 UI 或调用进程没有影响，这意味着调用进程不会等待任务完成。 UI 和调用进程无法检测到任务何时结束。

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

  • 将状态指示器值写入 UI 或调用方任务可访问的存储，该任务可以监视或检查此值。 后台任务返回给调用方的其他数据可以放置在同一存储中。

  • 建立 UI 或调用方监视的回复队列。 后台任务可以将消息发送到指示状态的队列。 后台任务返回到调用方的数据可以放置在消息中。 对于Azure 服务总线，请使用ReplyTo和CorrelationId属性来实现此功能。

  • 从 UI 或调用方可以访问的后台任务公开 API 或终结点以获取状态信息。 响应可以包含后台任务返回给调用方的数据。

  • 配置后台任务以通过 API 回调 UI 或调用方，以指示在预定义点或完成时的状态。 可以使用本地引发的事件或发布和订阅机制。 请求或事件有效负载可以包含后台任务返回给调用方的数据。

分区后台作业

如果在现有计算实例中包含后台作业，请考虑这些更改如何影响计算实例的质量属性和后台作业。 请考虑这些因素来决定是将任务与现有计算实例并置，还是将它们分离到不同的计算实例中：

  • 可用性：后台任务可能不需要与应用程序的其他部分相同的可用性级别，尤其是直接涉及用户交互的 UI 和部件。 后台任务对延迟、重试的连接失败和影响可用性的其他因素的容忍度可能更高，因为操作可以排队。 但是，必须有足够的容量来防止备份的请求阻止队列并影响整个应用程序。

  • 可伸缩性：与 UI 和应用程序的交互部分相比，后台任务可能具有不同的可伸缩性要求。 可能需要缩放 UI 以满足需求高峰。 未完成的后台任务可以在不太繁忙的时间和更少的计算实例的情况下运行。

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

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

  • 性能：为专门满足任务性能要求的后台任务选择计算实例的类型。 如果任务不需要与 UI 相同的处理功能，则可以使用成本较低的计算选项。 或者，如果任务需要更多容量和资源，则可以使用更大的实例。

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

  • 成本：如果添加计算实例来运行后台任务，托管成本将增加。 仔细考虑更多容量与额外成本之间的权衡。

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

防止资源冲突

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

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

确保后台任务可以自动重启，并且有足够的容量来处理需求高峰。 分配具有足够资源的计算实例，实现一种队列机制，用于存储需求减少时运行的请求，或使用这些技术的组合。

协调多个任务

后台任务可能很复杂，需要运行多个任务。 在这些方案中，通常将任务划分为多个使用者可以运行的较小离散步骤或子任务。 多步骤作业更高效、更灵活，因为单个步骤通常可在多个作业中重复使用。 添加、删除或修改步骤顺序也很容易。

协调多个任务和步骤可能是一项挑战，但有三种常见模式可指导解决方案：

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

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

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

使作业具有复原能力

创建可复原的后台任务，为应用程序提供可靠的服务。 规划和设计后台任务时，请考虑以下几点：

  • 后台任务需要妥善处理重启，确保不会损坏数据或导致应用程序不一致。 对于长时间运行的或多步骤任务，请考虑使用 检查点。 使用检查点将作业的状态保存在永久性存储中或作为队列中的消息保存。 例如，可以将状态信息存储在队列中的消息中，并使用任务进度以增量方式更新此状态信息。 可以从上一个已知检查点处理任务，而不是从头开始重启。

    对于服务总线队列，请使用消息会话实现此目的。 使用消息会话时，使用 SetState 和 GetState 方法保存和检索应用程序处理状态。 有关设计可靠的多步骤流程和工作流的详细信息，请参阅 计划程序代理监督器模式。

  • 使用队列来与后台任务通信时，队列可以充当缓冲区，用于在应用程序超过一般负载时，存储发送给任务的请求。 任务可以在不太繁忙的时间段内赶上 UI，重启不会阻止 UI。 有关详细信息，请参阅基于队列的负载调节模式。 如果某些任务比其他任务更重要，请考虑实现 优先级队列模式 ，以确保这些任务首先运行。

消息

配置由消息启动或处理消息以处理不一致的后台任务，例如不按顺序到达的消息、反复导致错误（有害消息）的消息以及多次传递的消息。 请考虑以下建议：

  • 有时需要按特定顺序处理消息，例如根据现有数据值更改数据的消息，例如向现有值添加值。 消息并不总是按照发送的顺序到达。 此外，由于每个实例上的负载不同，后台任务的不同实例可能会按不同的顺序处理消息。

    对于必须按特定顺序处理的消息，请包括序列号、键或后台任务可用于按正确顺序处理消息的另一个指示器。 对于服务总线，请使用消息会话来保证传递的正确顺序。 设计过程更高效，以便消息顺序不重要。 有关详细信息，请参阅 消息排序和时间戳。

  • 通常，后台任务会查看队列中的消息，该任务会暂时将其从其他消息使用者中隐藏。 任务成功处理消息后，会删除该消息。 如果后台任务在处理消息时失败，该消息会在速览超时过期后重新出现在队列中。 任务的不同实例处理消息，或原始实例的下一个处理周期处理消息。

    如果消息在使用者中一致导致错误，它会阻止任务、队列，并最终在队列满时应用程序本身。 从队列中检测和删除有害消息至关重要。 如果使用服务总线，请自动或手动将病毒消息移动到关联的死信队列。

  • 队列是 至少一次 传递机制，但它们可能会多次传递相同的消息。 如果后台任务在处理消息后失败，但在从队列中删除消息之前，该消息将再次可供处理。

    后台任务应该是幂等的，这意味着当任务多次处理同一条消息时，它不会在应用程序的数据中造成错误或不一致。 某些操作自然是幂等的，例如，如果存储的值设置为特定的新值。 但是，某些操作会导致不一致，例如，如果在未验证存储值与最初发送消息时的值相同的情况下将值添加到现有存储值中。 配置服务总线队列以自动删除重复的消息。 有关详细信息，请参阅幂等消息处理。

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

使作业可缩放

后台任务必须提供足够的性能，确保在系统承受负载时不会阻止应用程序或延迟操作。 通常，缩放托管后台任务的计算实例时，性能会提高。 规划和设计后台任务时，请考虑以下与可伸缩性和性能相关的要点：

  • Azure 虚拟机和Azure App 服务的Web 应用功能可以托管部署。 它们支持自动缩放，包括横向扩展和缩小。 自动缩放由需求和负载或预定义计划决定。 使用自动缩放来帮助确保应用程序具有足够的性能功能，同时最大程度地降低运行时成本。

  • 与应用程序的其他部分（例如 UI 或组件（如数据访问层）相比，某些后台任务具有不同的性能功能。 在这种情况下，将后台任务一起托管在单独的计算服务中，以便 UI 和后台任务可以独立缩放来管理负载。 如果多个后台任务具有明显不同的性能功能，请将其划分并独立缩放每个类型。 此方法可能会增加运行时成本。

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

  • 设计用于缩放的后台任务。 例如，后台任务必须动态检测已使用存储队列的数量，以监视消息或将消息发送到相应的队列。

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

  • 后台作业可能会为数据同步和进程协调带来挑战，尤其是在后台任务彼此依赖或其他数据源时。 例如，后台作业可能会处理数据一致性问题、争用条件、死锁或超时。

  • 如果后台任务的结果呈现给用户，后台作业可能会影响用户体验。 例如，后台作业可能要求用户等待通知、刷新页面或手动检查任务的状态。 这些行为可以提高用户交互的复杂性，并对用户体验产生负面影响。

权衡：后台作业向系统引入更多的组件和依赖项，这可能会增加解决方案的复杂性和维护成本。 例如，后台作业可能需要单独的队列服务、辅助角色服务、监视服务和重试机制。

Azure 便利化

以下部分介绍了可用于托管、运行、配置和管理后台作业的 Azure 服务。

主机环境

有几个 Azure 平台服务可以托管后台任务：

  • Web 应用和 WebJobs：使用App 服务的 WebJobs 功能来运行基于可在 Web 应用中运行的不同脚本或程序的自定义作业。

  • Azure Functions：对长时间不运行的后台作业使用函数应用。 如果在未充分利用的App 服务计划中托管工作负荷，也可以使用函数应用。

  • 虚拟机：如果有 Windows 服务或使用 Windows 任务计划程序，请在专用 VM 中托管后台任务。

  • Azure Batch：Batch 是一种平台服务，可用于计划在托管 VM 集合上运行的计算密集型工作。 它可以自动缩放计算资源。

  • Azure Kubernetes 服务（AKS）：AKS 为 Azure 上的 Kubernetes 提供托管托管托管环境。

  • Azure 容器应用：使用容器应用，可以生成基于容器的无服务器微服务。

以下部分提供了每个选项的注意事项，可帮助你选择最佳选项。

Web 应用和 WebJobs

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

配置 Web 作业时：

  • 如果希望作业响应事件驱动的触发器，请将其配置为 连续运行。 脚本或程序存储在名为 site/wwwroot/app_data/jobs/continuous 的文件夹中。

  • 如果希望作业响应计划驱动的触发器，请将其配置为 按计划运行。 脚本或进程存储在名为 site/wwwroot/app_data/jobs/triggered 的文件夹中。

  • 如果在配置作业时选择“按需运行”选项，则它在启动作业时按计划选项运行相同的代码。

WebJob 在 Web 应用的沙盒中运行。 它有权访问环境变量，并且可以与 Web 应用共享信息，例如连接字符串。 WebJob 有权访问运行 WebJob 的计算机的唯一标识符。 命名AzureWebJobsStorage的连接字符串提供对应用程序数据的存储队列、Blob 和表的访问权限。 它还提供对消息和通信服务总线的访问权限。 命名AzureWebJobsDashboard的连接字符串提供对 WebJob 操作日志文件的访问权限。

WebJobs 具有以下特征：

  • 安全性：Web 应用的部署凭据为 WebJobs 提供保护。

  • 支持的文件类型：使用命令脚本（.cmd）、批处理文件（.bat）、PowerShell 脚本（.ps1）、Bash shell 脚本（.sh）、PHP 脚本（.php）、Python 脚本（.py）、JavaScript 代码（.js）和可执行程序（.exe和.jar）定义 WebJobs。

  • 部署：可以使用 Azure 门户、Visual Studio 或 WebJobs SDK 部署脚本和可执行文件，也可以将它们直接复制到以下位置：

    • 对于触发的部署：site/wwwroot/app_data/jobs/triggered/<job name>

    • 对于持续部署：site/wwwroot/app_data/jobs/continuous/<job name>

  • 日志文件： Console.Out 被视为或标记为 INFO. Console.Error 被视为 ERROR. 使用门户访问监视和诊断信息。 直接从网站下载日志文件。 日志文件保存在以下位置：

    • 对于触发的部署：Vfs/data/jobs/triggered/<job 名称>

    • 对于持续部署：Vfs/data/jobs/continuous/<job 名称>

  • 配置：使用门户、REST API 和 PowerShell 配置 WebJobs。 使用名为 settings.job 的配置文件（与 WebJob 脚本位于同一根目录中）为 WebJob 提供配置信息。 例如：

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Web 应用和 WebJobs 注意事项

  • 默认情况下，Web 作业会随 Web 应用缩放。 若要将 WebJobs 配置为在单个实例上运行，请将 is_singleton 配置属性设置为 true。 对于不想同时缩放或作为多个实例运行的任务，例如重新编制索引或数据分析，单个实例 WebJobs 非常有用。

  • 为了最大程度地减少 Web 作业对 Web 应用性能的影响，请在新的App 服务计划中创建一个空的 Web 应用实例，以托管长时间运行或资源密集型的 WebJobs。

Azure Functions

Azure Functions 类似于 WebJobs。 Azure Functions 无服务器，最适合短时间内运行的事件驱动触发器。 如果将函数配置为在指定时间运行，还可以使用 Azure Functions 通过计时器触发器运行计划作业。

不建议将 Azure Functions 用于大型长时间运行的任务，因为函数可能会导致意外超时。 但是，根据托管计划，请考虑对计划驱动触发器使用函数。

Azure Functions 注意事项

如果预期后台任务在响应事件时需要短时间内运行，请考虑在消耗计划中运行该任务。 可以将运行时配置为最长时间。 运行时间较长的函数的成本会更多。 消耗更多内存的 CPU 密集型作业可能更昂贵。 如果将其他触发器用于服务作为任务的一部分，它们会单独计费。

如果有多个任务较短，但它们持续运行，则高级计划适用。 此计划的成本更高，因为它需要更多的内存和 CPU。 作为一个好处，可以使用其他功能，例如虚拟网络集成。

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

有关详细信息，请参阅：

虚拟机

你可以实现后台任务，以便它们不会部署到Web 应用。 例如，可以使用 Windows 服务、第三方实用工具或可执行程序来实现任务。 还可以使用为不同于托管应用程序的环境的运行时环境编写的程序。 例如，可以使用要从 Windows 或 .NET 应用程序运行的 Unix 或 Linux 程序。 从 Azure VM 的多个操作系统中进行选择，并在该 VM 上运行服务或可执行文件。

有关详细信息，请参阅：

若要在单独的 VM 中启动后台任务，可以：

  • 向任务公开的终结点发送请求，以便直接从应用程序按需运行任务。 请求传输任务所需的数据。 终结点调用任务。

  • 使用所选操作系统中的计划程序或计时器将任务配置为按计划运行。 例如，在 Windows 上，可以使用 Windows 任务计划程序来运行脚本和任务。 如果已在 VM 上安装 SQL Server，请使用SQL Server 代理运行脚本和任务。

  • 使用逻辑应用通过将消息添加到任务监视的队列或通过向任务公开的 API 发送请求来启动任务。

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

虚拟机注意事项

在 Azure VM 中部署后台任务时，请考虑以下几点：

  • 在单独的 Azure VM 中托管后台任务，以灵活地精确控制启动、部署、计划和资源分配。 但是，如果只为后台任务部署 VM，运行时成本会增加。

  • 无需监视门户中的任务，也没有针对失败任务自动重启功能。 但可以使用 Azure 资源管理器 cmdlet 监视 VM 的状态并对其进行管理。 没有用于控制计算节点中的进程和线程的设施。 通常，如果使用 VM，则必须实现从任务中的检测以及 VM 中的操作系统收集数据的机制。 为此， 可以使用 System Center Management Pack for Azure 。

  • 请考虑创建通过 HTTP 终结点公开的监视探测。 可以配置这些探测的代码以执行运行状况检查并收集操作信息和统计信息。 还可以使用探测整理错误信息并将其返回到管理应用程序。

有关详细信息，请参阅：

批处理

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

使用 Batch 准备 VM、将任务分配给 VM、运行任务、监视进度，并自动横向扩展 VM 以响应工作负荷。 Batch 还提供作业计划并支持 Linux 和 Windows VM。

批处理注意事项

Batch 适用于内部并行工作负荷。 可以使用 Batch 在末尾执行减少步骤的并行计算，或者针对需要在节点之间传递消息的并行任务运行 消息传递接口 （MPI） 应用程序 。

Batch 作业在节点池或 VM 上运行。 只能在需要时分配池，然后在作业完成后将其删除。 由于节点不处于空闲状态，因此此方法将最大化利用率，但作业必须等待分配节点。 或者，可以提前创建池。 此方法将作业启动所需的时间降到最低，但可能导致节点处于空闲状态。

有关详细信息，请参阅：

Azure Kubernetes 服务

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

容器可用于运行后台作业。 部分优点包括：

  • 容器支持高密度托管。 可以隔离容器中的后台任务，同时在每个 VM 中放置多个容器。

  • 使用容器业务流程协调程序执行内部负载均衡、配置内部网络和执行其他配置任务。

  • 可以根据需要启动和停止容器。

  • 使用 Azure 容器注册表，可以在 Azure 边界内注册容器，以提供安全、隐私和邻近性优势。

AKS 注意事项

AKS 需要了解如何使用容器业务流程协调程序。

有关详细信息，请参阅：

容器应用

使用容器应用，可以生成基于容器的无服务器微服务。 容器应用：

  • 针对运行常规用途容器进行优化，尤其是跨容器中部署的许多微服务的应用程序。

  • 由 Kubernetes 和开源技术（如 Dapr、 Kubernetes 事件驱动的自动缩放（KEDA）和 Envoy 提供支持。

  • 支持 Kubernetes 风格的应用，以及具有服务发现和流量拆分等功能的微服务。

  • 通过支持基于流量和从事件源（例如队列）拉取（包括缩放到零）的缩放来启用事件驱动应用程序体系结构。

  • 支持长时间运行的进程，并且可以运行 后台任务。

容器应用注意事项

容器应用不提供对基础 Kubernetes API 的直接访问。 如果需要访问 Kubernetes API 和控制平面，请使用 AKS。 如果想要生成 Kubernetes 样式的应用程序，并且不需要直接访问本机 Kubernetes API 和群集管理，请使用容器应用实现完全托管的体验。 容器应用最适合用于生成容器微服务。

有关详细信息，请参阅：

可靠性清单

请参阅完整的建议集。

可靠性清单