Azure 中的容器概述

专用 Docker 容器注册表简介

Azure Container Apps

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

可用性 ：后台任务可能无需具有应用程序其他部分所具有的相同可用性级别，特别是直接参与用户交互的 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 应用有多个实例。 对于必须以单个实例运行的计划作业而言，这可能是有用的方法。