部署戳模式

部署缩放单元模式涉及预配、管理和监视异构资源组以托管和操作多个工作负载或租户。 Each individual copy is called a stamp, or sometimes a service unit, scale unit, or cell. 在多租户环境中，每个缩放单元可为预定义数量的租户提供服务。 可以部署多个缩放单元，以便准线性地缩放解决方案并为不断增加的租户提供服务。 此方法可以提高解决方案的可伸缩性，允许跨多个区域部署实例，以及隔离客户数据。

上下文和问题

在云中托管应用程序时，请务必考虑应用程序的性能和可靠性要求。 如果托管解决方案的单个实例，可能会受到以下限制：

• Scale limits. 部署应用程序的单个实例可能会导致自然缩放限制。 例如，使用的服务可能对入站连接、主机名、TCP 套接字或其他资源施加限制。
• 非线性缩放或成本。 解决方案的某些组件可能不会根据请求数量或数据量线性缩放。 达到阈值后，性能可能骤然下降或者成本骤然增加。 例如，在使用某个数据库时，你可能发现增加更多容量（纵向扩展）的边际成本变得过高，而横向扩展是更经济高效的策略。
• 客户隔离。 你可能需要将某些客户的数据与其他客户的数据相隔离。 同样，可能有些客户需要比其他客户更多的系统服务资源，你可以考虑在不同的基础结构集上将他们分组。
• 处理单租户和多租户实例。 你可能有一些大客户需要他们自己的独立解决方案实例。 你可能还有一个可以共享多租户部署的小型客户池。
• 复杂的部署要求。 你可能需要以受控方式将更新部署到服务，并在不同的时间部署到不同的客户群子集。
• Update frequency. 有些客户可以容忍系统频繁更新，而有些客户不愿意承受风险，希望为他们的请求提供服务的系统不经常更新。 将这些客户部署到隔离的环境中可能有帮助。
• 地理或地缘政治限制。 为了实现低延迟或遵守数据主权要求，可将某些客户部署到特定的区域。

这些限制通常适用于构建服务型软件 (SaaS) 的独立软件供应商 (ISV)，这种软件采用多租户设计。 但是，同样的限制也适用于其他应用场景。

Solution

To avoid these issues, consider grouping resources in scale units and provisioning multiple copies of your stamps. Each scale unit will host and serve a subset of your tenants. 标记彼此独立运行，且可以独立部署和更新。 单个地理区域可能包含单个缩放单元，也可能包含多个缩放单元以允许在区域内横向扩展。 缩放单元包含客户的子集。

无论解决方案使用的是基础结构即服务 (IaaS)、平台即服务 (PaaS) 组件还是混合使用两者，都可以应用部署缩放单元。 通常，IaaS 工作负载需要更多干预才能缩放，因此对于 IaaS 繁重型工作负载，可以使用该模式来实现横向扩展。

Stamps can be used to implement deployment rings. 如果不同的客户希望以不同的频率接收服务更新，可将他们分组到不同的缩放单元，并以不同的频率为每个缩放单元部署更新。

Because stamps run independently from each other, data is implicitly sharded. 此外，单个缩放单元可以利用进一步的分片在内部实现可伸缩性和弹性。

The deployment stamp pattern is used internally by many Azure services, including App Service, Azure Stack, and Azure Storage.

Deployment stamps are related to, but distinct from, geodes. 在部署缩放单元体系结构中，将部署系统的多个独立实例，其中包含客户和用户的子集。 在地理节点中，所有实例可为任何用户的请求提供服务，但此体系结构的设计和构建通常更复杂。 此外还可以考虑在一个解决方案中混合两种模式；本文稍后将介绍的流量路由方法就是这种混合应用场景的一个例子。

Deployment

由于部署相同组件的相同副本所涉及的复杂性，良好的 DevOps 实践对于确保成功实现此模式至关重要。 Consider describing your infrastructure as code, such as by using Bicep, JSON Azure Resource Manager templates (ARM templates), Terraform, and scripts. 使用这种方法可以确保每个缩放单元的部署可预测且可重复。 此外，还可以减少人为失误的可能性，例如缩放单元之间的配置意外地不匹配。

You can deploy updates automatically to all stamps in parallel, in which case you might consider technologies like Bicep or Resource Manager templates to coordinate the deployment of your infrastructure and applications. 或者，可以先向某些缩放单元逐步部署更新，然后再向其他缩放单元逐步部署更新。 Consider using a release management tool like Azure Pipelines or GitHub Actions to orchestrate deployments to each stamp. 有关详情，请参阅：

• 将 Bicep 与 Azure Pipelines 集成
• 将 JSON ARM 模板与 Azure Pipelines 集成

认真考虑部署的 Azure 订阅和资源组的拓扑：

• 订阅通常会包含单个解决方案的所有资源，因此我们一般会考虑对所有缩放单元使用单个订阅。 但是，某些 Azure 服务实施订阅范围的配额，因此如果你使用此模式来实现较高程度的横向扩展，可能需要考虑在不同的订阅中部署缩放单元。
• 资源组通常用于部署具有相同生命周期的组件。 如果你打算一次性将更新部署到所有缩放单元，请考虑使用单个资源组来包含所有缩放单元的所有组件，并使用资源命名约定和标记来标识属于每个缩放单元的组件。 或者，如果你打算单独将更新部署到每个缩放单元，请考虑将每个缩放单元部署到其自身的资源组中。

Capacity planning

使用负载和性能测试来确定给定缩放单元大约可以容纳的负载。 负载指标可以基于单个缩放单元可以容纳的客户/租户数量，也可以基于缩放单元中的组件发出的服务指标。 确保采取充分的检测措施来度量给定缩放单元何时接近其容量限制，以及能否快速部署新的缩放单元来应对需求。

Traffic routing

如果每个缩放单元可单独寻址，则部署缩放单元模式可以顺利工作。 例如，如果 Contoso 要将同一个 API 应用程序部署到多个缩放单元，则他们可以考虑使用 DNS 将流量路由到相关缩放单元：

• unit1.aus.myapi.contoso.com 将流量路由到澳大利亚区域中的缩放单元 unit1。
• unit2.aus.myapi.contoso.com 将流量路由到澳大利亚区域中的缩放单元 unit2。
• unit1.eu.myapi.contoso.com 将流量路由到欧洲区域中的缩放单元 unit1。

然后客户端负责连接到正确的缩放单元。

如果所有流量需要单个入口点，可以使用流量路由服务来解析给定请求、客户或租户的缩放单元。 流量路由服务将客户端定向到缩放单元的相关 URL（例如，使用 HTTP 302 响应状态代码），或者充当反向代理，在客户端不知情的情况下将流量转发到相关缩放单元。

集中式流量路由服务可能是设计上较为复杂的组件，尤其是当解决方案跨多个区域运行时。 考虑将流量路由服务部署到多个区域（可能包括缩放单元部署到的每个区域），并确保数据存储（将租户映射到缩放单元）同步。 The traffic routing component might itself be an instance of the geode pattern.

例如，可以部署 Azure API 管理来充当流量路由服务角色。 它可以通过在存储租户与缩放单元之间的映射的 Azure Cosmos DB 集合中查找数据来确定请求的适当缩放单元。 然后 API 管理可以动态设置相关缩放单元的 API 服务的后端 URL。

若要启用请求异地分发和流量路由服务的异地冗余，可将 API 管理部署到多个区域，或者可以使用 Azure Front Door 将流量定向到最靠近的实例。 Front Door can be configured with a backend pool, enabling requests to be directed to the closest available API Management instance. 如果应用程序不是通过 HTTP/S 公开的，则可以使用跨区域 Azure 负载均衡器将传入调用分发到区域 Azure 负载均衡器。 可以使用 Azure Cosmos DB 的全球分发功能在每个区域中保持映射信息的更新状态。

If a traffic-routing service is included in your solution, consider whether it acts as a gateway and could therefore perform gateway offloading for the other services, such as token validation, throttling, and authorization.

示例流量路由体系结构

请考虑以下示例流量路由体系结构，它使用 Azure Front Door、Azure API 管理和 Azure Cosmos DB 进行全局流量路由，然后使用一系列特定于区域的缩放单元：

假设某个用户平时居住在纽约。 其数据存储在“美国东部”区域的缩放单元 3 中。

如果该用户前往加利福尼亚，然后访问系统，则其连接可能会通过“美国西部 2”区域路由，因为该区域在地理位置上与该用户发出请求时所处的位置最靠近。 但是，该请求最终必须由缩放单元 3 提供服务，因为这是该用户的数据的存储位置。 流量路由系统确保将请求路由到正确的缩放单元。

问题和注意事项

在决定如何实现此模式时，应考虑以下几点：

• Deployment process. 部署多个缩放单元时，强烈建议使用自动化且完全可重复的部署过程。 Consider using Bicep, JSON ARM templates, or Terraform modules to declaratively define your stamps, and to keep the definitions consistent.
• Cross-stamp operations. 将解决方案独立部署到多个缩放单元时，“我们的所有缩放单元中有多少客户？”之类的问题可能更难以回答。 可能需要针对每个缩放单元执行查询并聚合结果。 或者，考虑让所有缩放单元将数据发布到一个集中的数据仓库中以进行合并报告。
• 确定横向扩展策略。 缩放单元的容量有限，可以使用代理指标（例如可部署到缩放单元的租户数）来定义容量。 必须监视每个缩放单元的可用容量和已用容量，并前瞻性地部署更多的缩放单元，以便能够将新租户定向到它们。
• 最小缩放单元数。 使用部署缩放单元模式时，建议至少为解决方案部署两个缩放单元。 如果只部署一个缩放单元，则很容易意外地将假设硬编码到代码或配置中，而这些假设在横向扩展时不适用。
• Cost. 部署缩放单元模式涉及到部署基础结构组件的多个副本，这可能会大幅增加解决方案的操作成本。
• 在缩放单元之间移动。 由于每个缩放单元都是独立部署和操作的，因此在缩放单元之间移动租户可能很困难。 应用程序需要通过自定义逻辑将有关给定客户的信息传输到不同的缩放单元，然后从原始缩放单元中删除租户的信息。 此过程可能需要通过一个背板在缩放单元之间进行通信，从而进一步增大了整个解决方案的复杂性。
• Traffic routing. 如上文所述，将流量路由到给定请求的正确缩放单元可能需要通过附加的组件将租户解析到缩放单元。 而此组件可能需要高度可用。
• Shared components. 可能有一些组件在缩放单元之间共享。 For example, if you have a shared single-page app for all tenants, consider deploying that into one region and using Azure CDN to replicate it globally.

何时使用此模式

此模式可用于解决以下问题和需求：

• 可伸缩性的自然限制。 例如，如果某些组件无法或者不应扩展到超过特定数量的客户或请求，请考虑使用缩放单元进行横向扩展。
• 将某些租户与其他租户隔离的需求。 如果出于安全考虑，不能将某些客户与其他客户一起部署到多租户缩放单元，可以将他们部署到其自己的隔离缩放单元中。
• 需要同时将某些租户部署在不同版本的解决方案中。
• 需要将多区域应用程序中每个租户的数据和流量定向到特定区域。
• 希望在服务中断期间实现复原。 由于缩放单元彼此独立，如果服务中断影响了单个缩放单元，部署到其他缩放单元的租户应该不会受到影响。 这种隔离有助于控制事件或服务中断的“冲击范围”。

此模式不适合以下解决方案：

• 不需要高度扩展的简单解决方案。
• 可以在单个实例中轻松横向扩展或纵向扩展的系统，例如通过增大应用程序层的大小或通过增加数据库和存储层的预留容量进行扩展。
• 需要将其中的数据复制到所有已部署实例的解决方案。 Consider the geode pattern for this scenario.
• 仅需要扩展某些组件而不需要扩展其他组件的解决方案。 例如，考虑是否可以通过将数据存储分片而不是部署所有解决方案组件的新副本来扩展解决方案。
• 仅由静态内容组成的解决方案，例如前端 JavaScript 应用程序。 Consider storing such content in a storage account and using Azure CDN.

Workload design

架构师应评估如何在其工作负荷的设计中使用“部署标记模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 For example:

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

Supporting technologies

• 基础结构即代码。 例如，Bicep、资源管理器模板、Azure CLI、Terraform、PowerShell、Bash。
• Azure Front Door，它可以将流量路由到特定缩放单元或流量路由服务。

Contributors

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

Principal author:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

• Daniel Larsen | Principal Customer Engineer, FastTrack for Azure
• Angel Lopez | Senior Software Engineer, Azure Patterns and Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。

Related resources

• 分片可以用作横向扩展数据层的另一种更简单方法。 缩放单元隐式将其数据分片，但分片不需要部署缩放单元。 For more information, see the Sharding pattern.
• If a traffic routing service is deployed, the Gateway Routing and Gateway Offloading patterns can be used together to make the best use of this component.