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

有关开发后台作业的建议

  • 项目

适用于此 Azure Well-Architected 框架可靠性清单建议：

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

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

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

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

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

关键设计策略

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

后台作业的类型

后台作业的一些示例如下：

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

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

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

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

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

触发器

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

事件驱动的触发器

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

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

  • 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 相同的处理功能，则可以使用成本较低的计算选项。 或者，如果任务需要更多的容量和资源，则可以使用更大的实例。

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

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

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

冲突

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

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

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

协调

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

协调多个任务和步骤可能很困难，但有三种常见模式可以指导解决方案：

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

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

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

复原注意事项

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

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

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

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

消息

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

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

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

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

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

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

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

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

缩放和性能注意事项

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

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

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

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

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

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

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

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

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

Azure 简化

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

托管环境

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

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

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

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

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

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

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

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

Web 应用和 Web 作业

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

配置 Web 作业时：

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

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

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

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

WebJobs 具有以下特征：

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

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

  • 部署：可以使用 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 name>

    • 对于连续部署：Vfs/data/jobs/continuous/<job name>

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

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Web 应用和 Web 作业注意事项

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

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

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 中的操作系统收集数据。 为此，可以使用 适用于 Azure 的 System Center 管理包 。

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

有关详细信息，请参阅：

Batch

如果需要跨数十、数百或数千个 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 和群集管理，请使用容器应用来获得完全托管的体验。 容器应用最适合用于生成容器微服务。

有关详细信息，请参阅：

可靠性清单

请参阅完整的建议集。

可靠性清单