将多个任务或操作合并到单个计算单元。 这可以提高计算资源利用率，并减少与在云托管应用程序中执行计算处理关联的成本和管理开销。
上下文和问题
云应用程序通常实现各种操作。 在某些解决方案中，合理的做法是最初遵循问题分离的设计原则，将这些操作划分成分别进行托管和部署的单独计算单元（例如，作为单独的应用服务 Web 应用或单独的虚拟机）。 但是，虽然此策略可以帮助简化解决方案的逻辑设计，不过将大量计算单元作为相同应用程序的一部分进行部署可能会增加运行时托管成本并使系统管理更复杂。
作为示例，下图显示使用多个计算单元实现的云托管解决方案的简化结构。 每个计算单元都在其自己的虚拟环境中运行。 每个函数都作为在其自己的计算单元中运行的单独任务（标记为任务 A 到任务 E）来实现。
每个计算单元都会消耗应计费资源，即使它处于空闲状态或不常使用。 因此，这并不总是最经济高效的解决方案。
在 Azure 中，此问题适用于应用服务、容器应用和虚拟机。 这些项在其自己的环境中运行。 运行设计为执行一组定义完善的操作，但需要作为单个解决方案的一部分进行通信和协作的单独网站、微服务或虚拟机的集合可能对资源的使用较为低效。
解决方案
若要帮助降低成本、提高利用率、加快通信速度并减少管理，可以将多个任务或操作合并到单个计算单元。
任务可以按照基于环境提供的功能以及与这些功能关联的成本的条件进行分组。 一种常见方法是查找在其可伸缩性、生存期和处理要求方面具有类似特征的任务。 将它们组合在一起可使它们作为一个单元进行缩放。 借助许多云环境提供的弹性，可以根据工作负载来启动和停止计算单元的附加实例。 例如，Azure 提供自动缩放功能，可以应用于应用服务和虚拟机规模集。 有关详细信息，请参阅 Autoscaling Guidance（自动缩放指南）。
作为用于演示如何使用可伸缩性确定不应组合在一起的操作的计数器示例，请考虑以下两个任务：
- 任务 1 轮询发送给队列的对时间不敏感的少见消息。
- 任务 2 处理大量网络流量突发。
第二个任务需要可能会涉及到启动和停止大量计算单元实例的弹性。 将相同缩放应用于第一个任务只会导致更多任务在相同队列中侦听少见消息，是一种资源浪费。
在许多云环境中，可以在 CPU 核心数、内存、磁盘空间等方面指定可供计算单元使用的资源。 一般情况下，指定的资源越多，成本便越高。 为了节省资金，请务必最大程度提高昂贵计算单元执行的工作量，不要让它长时间处于非活动状态。
如果有在短暂突发中需要大量 CPU 能力的任务，请考虑将这些任务合并到可提供所需能力的单个计算单元。 但是，请务必平衡此需求以使昂贵资源在面对可能发生的争用（如果它们处于超负荷状态）时保持繁忙状态。 例如，长时间运行的计算密集型任务不应共享相同的计算单元。
问题和注意事项
在实现此模式时，请考虑以下几点：
可伸缩性和弹性。 许多云解决方案通过启动和停止计算单元实例，在计算单元级别实现可伸缩性和弹性。 应避免将具有冲突可伸缩性要求的任务分组到相同计算单元中。
生存期。 云基础结构会定期回收托管计算单元的虚拟环境。 当一个计算单元中存在许多长时间运行的任务时，可能需要配置该单元以防止在这些任务完成之前回收它。 或者，使用检查点方法设计任务，该方法使任务可完全停止，然后在计算单元重新启动时在中断位置处继续执行。
发布节奏。 如果任务的实现或配置经常更改，则可能需要停止托管更新的代码的计算单元，重新配置和重新部署该单元，然后重新启动它。 此过程还需要相同计算单元中的所有其他任务停止、重新部署并重新启动。
安全性。 相同计算单元中的任务可能会共享相同安全性上下文，并能够访问相同资源。 任务之间必须存在高度信任，并且确信一个任务不会对其他任务造成损坏或产生负面影响。 此外，增加在计算单元中运行的任务数会增大单元的攻击面。 每个任务的安全性只与具有最多漏洞的任务相同。
容错。 如果计算单元中的一个任务失败或行为异常，则它可能会影响在相同单元中运行的其他任务。 例如，如果一个任务未能正确启动，则它可能会导致计算单元的整个启动逻辑失败，并阻止相同单元中的其他任务运行。
争用。 应避免在相同计算单元中的任务之间出现竞争资源的争用。 理想情况下，共享相同计算单元的任务应表现出不同的资源利用率特征。 例如，两个计算密集型任务不应位于相同计算单元中，两个占用大量内存的任务也是如此。 但是，混合使用计算密集型任务与需要大量内存的任务是可行的组合。
注意
可考虑仅对已在一段时间内处于生产环境的系统合并计算资源，以便操作员和开发人员可以监视系统并创建标识每个任务如何使用不同资源的热度地图。 此地图可以用于确定非常适合用于共享计算资源的任务。
复杂性。 将多个任务合并到单个计算单元会向单元中的代码增加复杂性，从而更加难以进行测试、调试和维护。
稳定的逻辑体系结构。 设计和实现每个任务中的代码，以便即使运行任务的物理环境发生更改也无需更改代码。
其他策略。 合并计算资源只是可帮助降低与并发运行多个任务关联的成本的一种方式。 它需要进行仔细规划和监视以确保保持为有效方法。 其他策略可能更为合适，具体取决于工作的性质以及运行这些任务的用户所处的位置。 例如，工作负载的功能分解（如计算分区指南中所述）可能是更好的选择。
何时使用此模式
对于在其自己的计算单元中运行时不怎么经济高效的任务，可使用此模式。 如果任务长时间处于空闲状态，则在专用单元中运行此任务可能成本高昂。
此模式可能不适合执行关键容错操作的任务，或是处理高度敏感或私有数据并需要其自己的安全性上下文的任务。 这些任务应在其自己的隔离环境、在单独的计算单元中运行。
工作负载设计
架构师应评估如何在其工作负荷的设计中使用“计算资源合并模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 成本优化的重点是维持和提高工作负载的投资回报率。 | 此模式通过在池基础架构上聚合组件甚至整个工作负载来避免未使用的已预配容量，从而最大限度地利用计算资源。 - CO:14 合并 |
| 卓越运营有助于通过标准化流程和团队凝聚力来实现工作负荷质量。 | 整合可以产生更加同质的计算平台，从而简化管理和可观察性，减少运营任务的不同方法，并减少所需的工具数量。 - OE:07 监视系统 - OE:10 自动化设计 |
| 性能效率通过在缩放、数据和代码方面进行优化， 帮助工作负载高效地满足需求。 | 整合通过使用备用节点容量和减少超量预配的需要，最大限度地提高了计算资源的利用率。 这些基础结构的资源池中经常使用大型（垂直缩放）计算实例。 - PE:02 容量规划 - PE:03 选择服务 |
与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。
应用程序平台选择
可以通过不同的方式实现此模式，具体取决于所使用的计算服务。 请参阅以下示例服务：
- Azure 应用服务和 Azure Functions：部署表示托管服务器基础结构的共享应用服务计划。 可将一个或多个应用配置为在相同的计算资源中（或相同的应用服务计划中）运行。
- Azure 容器应用：将容器应用部署到同一共享环境；尤其是在需要管理相关服务或需要将不同应用程序部署到同一虚拟网络的情况下。
- Azure Kubernetes 服务 (AKS)：AKS 是基于容器的托管基础结构，在 AKS 中可将多个应用程序或应用程序组件配置为在同一计算资源（节点）上共同运行，按 CPU 或内存要求（节点池）等计算要求分组。
- 虚拟机：部署一组虚拟机供所有租户使用，从而可以在租户之间分摊管理成本。 虚拟机规模集是一项支持共享资源管理、负载均衡和虚拟机水平缩放的功能。
相关资源
实施此模式时，可能也会与以下模式和指南相关：
Autoscaling Guidance（自动缩放指南）。 自动缩放可以用于根据对处理的预计需求，启动和停止托管计算资源的服务的实例。
计算分区指南。 介绍如何在云服务中分配服务和组件，以便最大程度地降低运行成本，同时保持服务的可伸缩性、性能、可用性和安全性。
多租户解决方案中的计算体系结构方法。 提供有关解决方案架构师在规划多租户解决方案计算服务时基本的注意事项和要求的指导。