你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本指南介绍开发后台作业的建议。 后台作业自动运行，无需用户交互。 许多应用程序需要独立于 UI 运行的后台作业。
后台作业的一些示例包括批处理作业、密集型处理任务和长时间运行的流程，如工作流。 应用程序启动作业并处理用户的交互式请求。 例如，如果应用程序需要生成用户上传的图像缩略图，则可以执行后台作业来生成缩略图并将其保存到存储。 用户无需等待该过程完成。 另一个示例是客户下订单，该订单启动处理订单的后台工作流。 客户在后台作业运行时继续浏览 Web 应用。 后台作业完成后，它会更新存储的订单数据，并向客户发送电子邮件以确认订单。
后台作业有助于最大程度地减少应用程序 UI 上的负载，从而提高可用性并减少交互式响应时间。
若要选择要指定为后台作业的任务，请考虑任务是否在没有用户交互的情况下运行，以及 UI 是否需要等待任务完成。 要求用户或 UI 在运行时等待的任务通常是不适合的后台作业。
评估后台作业的需求
后台作业的一些示例如下：
CPU 密集型作业，例如数学计算或结构模型分析。
I/O 密集型作业，例如运行一系列存储事务或索引文件。
批处理作业，例如夜间数据更新或有计划的处理。
长期运行的工作流，如订单履行或预配服务和系统。
将任务传输到更安全的位置进行处理的敏感数据处理。 例如，您可能不想在 web 应用程序中处理敏感数据。 相反，您可以使用 Gatekeeper 模式等模式，将数据转移到能够访问受保护的存储的已隔离后台进程。
选择正确的触发器
使用以下方法启动后台作业：
事件驱动的触发器
操作触发启动后台任务的事件驱动调用。 事件驱动触发器的示例包括：
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属性来实现此功能。把后台任务中的 API 或终结点公开，使 UI 或调用方可以访问，以获取状态信息。 响应可以包含后台任务返回给调用方的数据。
将后台任务配置为通过 API 回调至 UI 或调用方，以在预定义的点或完成时指示状态。 可以使用本地生成的事件或发布-订阅机制。 请求或事件有效负载可以包含后台任务返回给调用方的数据。
分区后台作业
如果在现有计算实例中包含后台作业，请考虑这些更改如何影响计算实例的质量属性和后台作业。 请考虑这些因素来决定是将任务与现有计算实例并置，还是将它们分离到不同的计算实例中：
可用性：后台任务可能不需要与应用程序的其他部分相同的可用性级别，尤其是直接涉及用户交互的 UI 和部件。 后台任务对延迟、重试连接失败和影响可用性的其他因素的容忍度可能更高，因为操作可以排队。 但是，必须有足够的容量来防止备份的请求阻止队列并影响整个应用程序。
可伸缩性：与 UI 和应用程序的交互部分相比，后台任务可能具有不同的可伸缩性要求。 可能需要扩展 UI 以应对需求高峰。 未完成的后台任务可以在不太繁忙的时间和更少的计算实例的情况下运行。
复原能力：如果托管后台任务的计算实例失败，则它可能不会对整个应用程序造成致命影响。 这些任务的请求可以排队或推迟，直到任务可用。 如果计算实例或任务可以在适当的时间间隔内重启，则它可能不会影响应用程序用户。
安全性：与 UI 或应用程序的其他部分相比，后台任务可能有不同的安全要求或限制。 使用单独的计算实例为任务指定不同的安全环境。 为了最大程度地提高安全性和分离性，还可以使用 Gatekeeper 等模式将后台计算实例与 UI 隔离开来。
性能：为专门满足任务性能要求的后台任务选择计算实例的类型。 如果任务不需要与 UI 相同的处理功能，则可以使用成本较低的计算选项。 或者，如果任务需要更多容量和资源，则可以使用更大的实例。
可管理性：与主要应用程序代码或 UI 相比，后台任务可能有不同的开发和部署节奏。 为了简化更新和版本控制，请将后台任务部署到单独的计算实例。
成本：如果添加计算实例来运行后台任务，托管成本将增加。 仔细考虑更多容量与额外成本之间的权衡。
有关详细信息，请参阅 “领导者选举模式 ”和 “竞争消费者”模式。
防止资源冲突
如果有多个后台作业实例，则它们可能会争用对资源和服务（例如数据库和存储）的访问权限。 此并发访问可能会导致资源争用，这可能会导致服务可用性冲突并损害存储中数据的完整性。 使用悲观锁定方法解决资源争用。 此方法可防止任务的竞争实例同时访问服务或损坏数据。
解决冲突的另一种方法是将后台任务定义为单一实例，以便仅运行一个实例。 但是，此方法消除了多实例配置提供的可靠性和性能优势。 如果 UI 提供足够的工作来保持多个后台任务繁忙，则这种缺点尤其如此。
确保后台任务可以自动重启，并且有足够的容量来处理需求高峰。 分配具有足够资源的计算实例，实现一种队列机制，用于存储需求减少时运行的请求，或使用这些技术的组合。
协调多个任务
后台任务可能比较复杂，需要运行多个任务。 在这些方案中，通常将任务划分为多个使用者可以运行的较小离散步骤或子任务。 多步骤作业更高效、更灵活，因为单个步骤通常在多个作业中可重复使用。 还可以轻松添加、删除或修改步骤的顺序。
协调多个任务和步骤可能很困难，但有三种常见模式可以指导解决方案：
将任务分解为多个可重用的步骤。 应用程序可能需要对其处理的信息执行不同复杂度的各种任务。 实现此类应用程序的一种简单但不灵活的方法是以整体模块的形式执行此处理。 但是，如果应用程序在其他位置需要部分相同的处理，此方法可能会减少重构代码、优化代码或重用代码的机会。 有关详细信息，请参阅 管道和筛选器模式。
管理任务步骤的编排。 应用程序可能会执行包含许多步骤的任务，其中一些步骤可能会调用远程服务或访问远程资源。 有时，各个步骤彼此独立，但它们由实现任务的应用程序逻辑进行协调。 有关详细信息，请参阅计划程序代理监督程序模式。
管理失败的任务步骤的恢复。 如果一个或多个步骤失败，应用程序可能需要撤消一系列步骤执行的工作，这共同定义了最终一致的操作。 有关详细信息，请参阅 补偿事务模式。
使作业具有弹性
创建可复原的后台任务，为应用程序提供可靠的服务。 规划和设计后台任务时，请考虑以下几点：
后台任务需要正常处理重启，而不会损坏数据或导致应用程序不一致。 对于长时间运行或多步骤的任务，请考虑使用检查点。 使用检查点将作业状态保存到持久存储中，或者将其作为消息保存到队列中。 例如，可以将状态信息存储在队列中的消息中，并使用任务进度以增量方式更新此状态信息。 可以从上一个已知检查点处理任务，而不是从头开始重启。
对于服务总线队列，请使用消息会话实现此目的。 使用消息会话时，使用 SetState 和 GetState 方法保存和检索应用程序处理状态。 有关设计可靠的多步骤流程和工作流的详细信息，请参阅 计划程序代理监督器模式。
使用队列来与后台任务通信时，队列可以充当缓冲区，用于在应用程序超过一般负载时，存储发送给任务的请求。 任务可以在不太繁忙的时段赶上 UI，重启不会阻止 UI。 有关详细信息，请参阅基于队列的负载调配模式。 如果某些任务比其他任务更重要，请考虑实现 优先级队列模式 ，以确保这些任务首先运行。
Messages
配置由消息启动或用于处理消息以解决不一致的后台任务，例如不按顺序到达的消息、反复导致错误的消息（毒性消息），以及被多次传递的消息。 请考虑以下建议：
有时需要按特定顺序处理消息，例如根据现有数据值更改数据的消息，例如向现有值添加值。 消息并不总是按照发送的顺序到达。 此外，由于每个实例上的负载不同，后台任务的不同实例可能会按不同的顺序处理消息。
对于必须按特定顺序处理的消息，请包括序列号、键或后台任务可用于按正确顺序处理消息的另一个指示器。 对于服务总线，请使用消息会话来保证传递的正确顺序。 将过程设计得更高效，使得消息顺序无关紧要。 有关详细信息，请参阅 消息排序和时间戳。
通常，后台任务会窥视队列中的消息，暂时将这些消息从其他消息使用者中隐藏。 任务成功处理消息后，会删除该消息。 如果后台任务在处理消息时失败，该消息会在速览超时过期后重新出现在队列中。 任务的不同实例处理消息，或原始实例的下一个处理周期处理消息。
如果消息在消费者中反复引发错误，它会阻塞任务和队列，最终当队列满时，阻塞应用程序本身。 从队列中检测和删除有害消息至关重要。 如果使用服务总线，请自动或手动将毒信移至关联的 死信队列。
队列是至少一次的传递机制，但它们有可能多次传递相同的消息。 如果后台任务在处理消息后失败，但在从队列中删除消息之前，该消息将再次可供处理。
后台任务应该是幂等的，这意味着当任务多次处理同一条消息时，它不会在应用程序的数据中造成错误或不一致。 某些操作天生具有幂等性，例如，如果将存储值设置为特定的新值。 但是，某些作会导致不一致，例如，如果在未验证存储值与最初发送消息时的值相同的情况下将值添加到现有存储值中。 配置服务总线队列以自动删除重复的消息。 有关详细信息，请参阅幂等消息处理。
某些消息传送系统（例如 Azure 存储队列和服务总线队列）支持出队计数属性，该属性指示消息被从队列中读取的次数。 此数据可用于处理重复的消息和有害消息。 有关详细信息，请参阅 异步消息传送入门 和 幂等模式。
使任务可扩展
后台任务必须提供足够的性能，以确保它们在系统负载不足时不会阻止应用程序或延迟操作。 通常，缩放托管后台任务的计算实例时，性能会提高。 规划和设计后台任务时，请考虑以下与可伸缩性和性能相关的要点：
Azure 应用服务的 Azure 虚拟机和 Web 应用功能可以托管部署。 它们支持自动缩放，包括横向扩展和缩小。 自动缩放由需求和负载或预定义计划决定。 使用自动缩放来帮助确保应用程序具有足够的性能功能，同时最大程度地降低运行时成本。
与应用程序的其他部分（例如 UI 或组件（如数据访问层）相比，某些后台任务具有不同的性能功能。 在这种情况下，将后台任务一起托管在单独的计算服务中，以便 UI 和后台任务可以独立缩放来管理负载。 如果多个后台任务具有明显不同的性能功能，请将其划分并独立缩放每个类型。 此方法可能会增加运行时成本。
为了防止性能在负载下的下降，您可能还需要扩展存储队列和其他资源，以避免处理链中的单点造成瓶颈。 请考虑其他限制，例如应用程序和后台任务所依赖的存储和其他服务的最大吞吐量。
设计后台任务以实现扩展。 例如，后台任务必须动态检测已使用存储队列的数量，以监视消息或将消息发送到相应的队列。
默认情况下，WebJob 会与其关联的 Web 应用实例进行缩放。 但是，如果希望 WebJob 仅作为单个实例运行，则可以创建一个包含 JSON 数据的
{ "is_singleton": true }Settings.job 文件。 此方法强制 Azure 仅运行 Web 作业的一个实例，即使关联 Web 应用的多个实例也是如此。 此方法对于必须仅作为单个实例运行的计划作业非常有用。后台作业可能会给数据同步和进程协调带来挑战，尤其是在后台任务相互依赖或其他数据源的情况下。 例如，后台作业可能会处理数据一致性问题、争用条件、死锁或超时。
如果向用户显示后台任务的结果，后台作业可能会影响用户体验。 例如，后台作业可能要求用户等待通知、刷新页面或手动检查任务状态。 这些行为会增加用户交互的复杂性，并对用户体验产生负面影响。
权衡：后台作业向系统引入更多组件和依赖项，这可能会增加解决方案的复杂性和维护成本。 例如，后台作业可能需要单独的队列服务、工作服务、监视服务和重试机制。
Azure 便利化
以下部分介绍了可用于托管、运行、配置和管理后台作业的 Azure 服务。
主机环境
有几个 Azure 平台服务可以托管后台任务：
Web 应用和 WebJobs：使用应用服务的 WebJobs 功能运行基于可在 Web 应用中运行的不同脚本或程序的自定义作业。
Azure Functions：对长时间不运行的后台作业使用函数应用。 如果您的工作负载托管在未充分利用的应用服务计划上，仍可以使用函数应用。
Azure 逻辑应用：使用逻辑应用来处理需要在多个服务和系统之间进行编排的后台作业。
虚拟机：如果你有 Windows 服务或使用 Windows 任务计划程序，请在专用 VM 中托管后台任务。
Azure Batch：Batch 是一种平台服务，可用于计划在托管 VM 集合上运行的计算密集型工作。 它可以自动缩放计算资源。
Azure Kubernetes 服务（AKS）：AKS 为运行在 Azure 上的 Kubernetes 提供托管环境。
Azure 容器应用：使用容器应用，可以生成基于容器的无服务器微服务。
以下部分提供了每个选项的注意事项，可帮助你选择最佳选项。
Web 应用和 Web 作业
可以使用 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/<作业名称>
对于持续部署：site/wwwroot/app_data/jobs/continuous/<作业名称>
日志文件：
Console.Out被视为或标记为INFO.Console.Error被视为ERROR. 使用门户访问监视和诊断信息。 直接从网站下载日志文件。 日志文件保存在以下位置：对于触发的部署：Vfs/data/jobs/triggered/<作业名称>
对于持续部署：Vfs/data/jobs/continuous/<作业名称>
配置：使用门户、REST API 和 PowerShell 配置 WebJobs。 使用名为 settings.job 的配置文件（与 WebJob 脚本位于同一根目录中）为 WebJob 提供配置信息。 例如：
{ "stopping_wait_time": 60 }{ "is_singleton": true }
Web 应用和 WebJobs 注意事项
默认情况下，WebJobs 使用 Web 应用进行缩放。 若要将 WebJobs 配置为在单个实例上运行，请将
is_singleton配置属性设置为true。 对于不需要缩放或者以多个实例同时运行的任务，例如重新编制索引或数据分析，单实例WebJobs非常有用。为了最大程度地减少 WebJobs 对 Web 应用性能的影响，请在新的应用服务计划中创建一个空的 Web 应用实例，以托管长时间运行或资源密集型的 WebJobs。
Azure Functions
Azure Functions 无服务器，最适合短时间内运行的事件驱动触发器。 如果将函数配置为在指定时间运行，还可以使用 Azure Functions 通过计时器触发器运行计划作业。
使用 Azure Durable Functions 协调复杂的工作流和长时间运行的进程。 Durable Functions 允许在无服务器环境中定义有状态工作流，这对于需要协调和状态管理的后台作业尤其有用。
Azure Functions 注意事项
如果预期后台任务在响应事件时需要短时间内运行，请考虑在消耗计划中运行该任务。 可以将运行时配置为最长时间。 运行时间更长的函数成本更高。 消耗更多内存的 CPU 密集型作业可能更昂贵。 如果您在任务中使用了额外的服务触发器，它们会被单独计费。
如果有多个任务较短，但它们持续运行，则高级计划适用。 此计划更昂贵，因为它需要更多的内存和 CPU。 作为一个好处，可以使用其他功能，例如虚拟网络集成。
如果工作负荷已在专用计划中运行，则专用计划适用于后台作业。 如果 VM 使用率不足，则可以在同一 VM 上运行专用计划并共享计算成本。
有关详细信息，请参见:
Azure Logic Apps
Azure 逻辑应用提供了一个功能强大的平台，用于自动执行工作流和集成各种服务。 它们特别适合托管需要在多个服务和系统之间协调的后台作业。
Azure 逻辑应用具有用于创建工作流的可视化设计器、用于集成各种服务、事件驱动的触发器、用于复杂协调的有状态工作流以及内置错误处理和重试的连接器库，以确保从暂时性故障中复原和恢复。
Azure 逻辑应用注意事项
如果不需要保证较低的延迟进行响应，则非常适合使用逻辑应用，例如执行异步操作，或者运行时间适中的 API 调用。 如果需要低延迟（例如，在阻止用户界面的调用中）使用其他技术，如 Azure Functions 或部署到 Azure 应用服务的 Web API。
Azure 逻辑应用遵循即用即付定价模型，根据执行的作数和使用的连接器收费。 通过设计高效的工作流并最大程度地减少逻辑应用中使用的作和连接器数量，从而优化成本。
逻辑应用根据传入的请求数和工作流的复杂性自动缩放。 但是，请注意 Logic Apps 的节流限制和配额，尤其是在后台作业涉及高频率触发器或大量数据时。
有关详细信息，请参见:
虚拟机
你可以实现后台任务，以便它们不会部署到 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 终结点公开的监控探针。 可以配置这些探测器的代码来执行运行状况检查并收集操作信息和统计信息。 还可以使用探测整理错误信息并将其返回到管理应用程序。
有关详细信息，请参见:
Azure 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 需要了解如何使用容器编排器。
有关详细信息，请参见:
Azure 容器应用
使用容器应用，可以生成基于容器的无服务器微服务。 容器应用：
专为运行通用用途容器进行优化，尤其适用于跨多个容器部署的微服务应用程序。
由 Kubernetes 和开源技术（如 Dapr、 Kubernetes 事件驱动的自动缩放（KEDA）和 Envoy 提供支持。
通过支持基于流量的扩展，并从事件源（例如 队列）拉取（包括扩展至零）来启用事件驱动的应用程序架构。
支持长时间运行的进程，并且可以运行 后台任务。
容器应用注意事项
容器应用不提供对基础 Kubernetes API 的直接访问。 如果需要访问 Kubernetes API 和控制平面，请使用 AKS。 如果想要生成 Kubernetes 样式的应用程序，并且不需要直接访问本机 Kubernetes API 和群集管理，请使用容器应用实现完全托管的体验。 容器应用最适合用于生成容器微服务。
有关详细信息，请参见:
相关链接
可靠性清单
请参阅完整的建议集。