你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
部署标记模式预配、管理和监视一组资源来托管和操作多个工作负荷或租户。 每个副本称为 戳记，有时称为 服务单元、 缩放单元或 单元。 在多租户环境中，每个站点服务预定义数目的租户。 部署多个实例以接近线性地扩展解决方案，并为越来越多的租户提供服务。 此方法可以提高解决方案的可伸缩性，使你可以跨多个区域部署实例，并分离客户数据。
注意
有关详细信息，请参阅 Azure 上的架构多租户解决方案。
上下文和问题
在云中托管应用程序时，请考虑应用程序的性能和可靠性。 如果托管解决方案的单个实例，可能会应用以下限制：
规模限制： 应用程序的单个实例可能会达到自然缩放限制。 例如，你使用的服务可能会限制入站连接数、主机名、传输控制协议（TCP）套接字或其他资源的数量。
非线性缩放或成本： 某些解决方案的组件可能无法随请求数或数据量线性缩放。 相反，达到阈值后，性能可能会下降或成本激增。 例如，你可能会发现，向数据库添加更多容量或纵向扩展会变得非常昂贵，并且横向扩展更具成本效益。
客户分离： 可能需要将一个客户的数据与另一个客户的数据隔离开来。 你可能还有些客户消耗的系统资源比其他客户多。 可以在不同的基础设施组上对它们进行分组。
单租户和多租户实例： 某些大型客户可能需要自己的解决方案独立实例。 较小的客户可以共享多租户部署。
复杂的部署要求： 可能需要以受控方式将更新部署到服务，并在不同时间部署到不同客户群的不同子集。
更新频率： 一些客户容忍频繁更新，而风险厌恶的客户希望不经常更新服务其请求的系统。 可以将这些客户部署到隔离的环境。
地理或地缘政治限制： 若要实现低延迟或符合数据主权要求，可以将一些客户部署到特定区域。
这些限制通常适用于构建软件即服务（SaaS）的软件开发公司，它们通常将其设计为多租户。 同样的限制也适用于其他方案。
解决方案
为了避免这些问题，请考虑将资源分组到 缩放单元 中，并预配 标记的多个副本。 每个扩展单元托管并服务于您的租户子集。 标记彼此独立运行，可以独立部署和更新它们。 单个地理区域可能包含一个戳记，或多个在该区域内水平扩展的戳记。 每个标记都为部分客户群体提供服务。
无论解决方案是使用基础结构即服务（IaaS）还是平台即服务（PaaS）组件或两者的组合，都可以应用部署标记。 IaaS 工作负载通常需要更多干预来扩展，因此此模式可以帮助 IaaS 密集型的工作负载横向扩展。
可以使用标记来实现 部署圈。 如果不同的客户想要不同频率的服务更新，请将它们分组到不同的戳记上，并按不同的节奏为每个标记部署更新。
印章独立运行，因此它们会隐式对您的数据进行分片。 单个模具还可以在内部使用进一步分片来缩放和保持弹性。
部署相同组件的相同副本很复杂，因此良好的 DevOps 做法至关重要。 将基础结构描述为代码，以便每个标记的部署可预测且可重复。
部署标记与几何图形有关，但不同。 在部署标记体系结构中，系统的每个独立实例都为一部分客户和用户提供服务。 在地理设计体系结构中，每个实例都可以为来自任何用户的请求提供服务，但此方法通常更复杂，需要设计和生成。 还可以在一个解决方案中合并这两种模式。 本文稍后介绍的 流量路由方法是 此类混合方案的示例。
问题和注意事项
在决定如何实现此模式时，请考虑以下几点：
部署过程： 部署多个标记时，自动执行并完全重复部署过程。 使用 Bicep 或 Terraform 模块以声明方式定义戳记并保持定义一致。
跨戳操作： 当您在多个实例中独立部署解决方案时，很难确定您在所有实例中的客户总数。 可能需要查询每个标记并聚合结果。 或者，可以让所有印章将数据发布到集中式数据仓库中，以便进行合并报告。
横向扩展策略： 图章具有有限的容量，可以使用代理指标进行定义，例如可以部署到图章的租户数。 监视每个标记的可用和已用容量，并主动部署更多标记以将新租户定向到它们。
最小邮票数： 使用部署标记模式时，至少部署解决方案的两个戳记。 如果仅部署一个标记，则可以轻松地将硬代码假设引入到横向扩展时不适用的代码或配置中。
成本： 部署标记模式部署基础结构组件的多个副本，这大大增加了解决方案的运行成本。
在分区之间移动： 每个分区独立运行，因此在分区之间移动租户可能具有挑战性。 应用程序需要自定义逻辑，才能将客户的信息传输到其他标记，然后从原始戳中删除租户的信息。 此过程可能需要通过背板在模块之间进行通信，从而进一步增加解决方案的复杂性。
流量路由： 如本文前面所述，将流量路由到给定请求的正确戳记可能需要将租户解析为戳记的额外组件。 此组件可能还需要具有高可用性。
跨邮票的可观测性： 随着邮票数量的增加，理解整体运行状况并快速检测事件变得更加困难。 使用 Azure Monitor 在所有标记中收集和关联指标、日志、跟踪和警报。 使用此数据可识别不正常的戳记和诊断问题。
区域故障影响： 邮票独立运行，但它们在区域之间本质上不是冗余的。 如果托管一个或多个标记的区域变得不可用，则这些标记上的租户将失去访问权限，直到区域恢复或您将租户迁移到另一个区域中的标记。 若要规划此方案，请记录恢复过程、设置租户预期，并考虑关键租户是否需要异地冗余标记放置。
共享组件： 你可能具有可在图章之间共享的组件。 例如，如果你有一个为所有租户共享的单页应用程序，请将其部署到一个区域，并使用 Azure Front Door 边缘缓存进行全局复制。
治理和配置偏移： 随着实例数量的增加，保持安全策略、基于角色的访问控制（RBAC）分配、网络控制、可观测性设置和服务配置的一致性变得更加困难。 使用 Azure Policy 将治理视为代码并持续验证每个印章，以防止不一致的行为和合规性差距。
何时使用此模式
在以下情况下使用此模式：
你的解决方案对可伸缩性有自然限制。 例如，如果某些组件不能或不应扩展到特定数量的客户或请求，请使用印章进行横向扩展。
需要将某些租户与其他租户分开。 如果出于安全考虑而无法将某些客户部署到多租户节点，则将其部署到自己的独立节点上。
需要同时在解决方案的不同版本上托管一些租户。
构建需要将每个租户的数据和流量定向到特定区域的多区域应用程序。
你想要在中断期间实现复原能力。 印花独立运行，因此，如果服务中断影响单个标记，其他印花上的租户仍不受影响。 此隔离限制了事件或中断的 爆炸半径 。
在以下情况下，此模式可能不适用：
您的解决方案非常简单，不需要大幅扩展。
可以在单个实例中横向扩展或纵向扩展系统，例如增加应用程序层的大小或增加数据库和存储层的预留容量。
您需要在跨所有已部署实例之间复制数据。 请考虑此方案的 Geode 模式 。
只需缩放某些组件，而不需要缩放其他组件。 例如，考虑是否可以通过 分片数据存储 来缩放解决方案，而不是部署所有解决方案组件的新副本。
解决方案仅包含静态内容，例如前端 JavaScript 应用程序。 通过 内容分发网络传送此内容。
工作负载设计
评估如何在工作负载的设计中使用部署戳记范式来实现 Azure Well-Architected 框架支柱中涵盖的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 可靠性 设计决策有助于工作负荷在发生故障后 复原 ，并确保它在发生故障后 恢复到 正常运行状态。 | 戳独立运行，因此一个戳中的故障是隔离的，不会影响其他戳上的租户。 跨区域部署多个站点也为冗余和恢复规划提供了基础，从而减少区域故障的影响范围。 - RE:05 冗余 - RE:07 自我保护 |
| 卓越运营有助于通过标准化流程和团队凝聚力来实现工作负荷质量。 | 此模式支持不可变的基础结构目标、高级部署模型，并且可以促进安全部署实践。 - OE:05 基础结构即代码 - OE:11 安全部署实践 |
| 通过缩放、数据和代码的优化，性能效率可帮助工作负荷高效地满足需求。 | 此模式通常与工作负荷中定义的比例单位保持一致。 当需要超过单个缩放单元所提供的容量时，可以部署另外一个部署单元来扩展容量。 - PE:05 缩放和分区 |
如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。
Example
以下示例体系结构使用Azure Front Door、Azure API 管理和Azure Cosmos DB将流量全局路由到一系列特定于区域的标记。
假设用户位于纽约。 位于美国东部地区的标识3存储数据。
如果用户前往加州并访问系统，则系统会通过美国西部 2 区域路由其连接，因为在发出请求时该区域离他们最近的区域。 但是，stamp 3 最终必须处理请求，因为它存储着他们的数据。 流量路由系统将请求路由到正确的标记。
部署
使用 Bicep 或 Terraform 将基础结构描述为代码。 此方法可确保每个标记的部署可预测且可重复。 此外，还可以减少人为失误的可能性，例如标记之间的配置意外地不匹配。
可以将更新自动部署到所有戳记。 Bicep 等技术可以协调基础结构和应用程序的部署。 或者，你可能决定先逐步推出对某些邮票的更新，然后逐渐向其他邮票推出更新。 请考虑使用 Azure Pipelines 或 GitHub Actions 等发布管理工具来协调每个标记的部署。
认真考虑部署的 Azure 订阅和资源组的拓扑：
通常，订阅包含单个解决方案的所有资源，因此请考虑对所有戳记使用单个订阅。 但是，一些Azure服务在整个订阅范围内施加配额限制。 如果使用这种模式来实现高水平的横向扩展，可能需要在不同的订阅中部署组件。
资源组通常包含共享相同生命周期的组件。 如果计划同时为所有图章部署更新，则可以使用一个资源组，其中包含所有戳记的所有组件。 使用资源命名约定和标记来标识属于每个标记的组件。 或者，如果计划单独将更新部署到每个标记，则可以将每个标记部署到其自己的资源组中。
产能规划
使用负载和性能测试来确定给定模块可以承受的大致负载。 加载指标可能基于单个标记可以容纳的客户或租户数，或基于标记中服务发出的指标。 检测每个标记，以便可以测量何时接近其容量，并确保可以快速部署新标记以响应需求。
流量路由
独立处理每个标记时，部署标记模式效果良好。 例如，如果 Contoso 跨多个标记部署相同的 API 应用程序，Contoso 可能会使用域名系统（DNS）将流量路由到相关标记：
-
unit1.aus.myapi.contoso.com将流量路由到位于澳大利亚地区的Stamp实例unit1。 -
unit2.aus.myapi.contoso.com将流量路由到位于澳大利亚地区的Stamp实例unit2。 -
unit1.eu.myapi.contoso.com将流量路由到欧洲区域中的缩放单元unit1。
在Azure中，可以在 Azure DNS 中托管这些记录，并为每个区域和标记使用一致的子域约定。 此方法维护可预测的路由和操作。
客户端负责连接到正确的戳记。
如果解决方案需要所有流量的单个入口点，则可以使用流量路由服务来解析给定请求、客户或租户的戳记。 流量路由服务要么将客户端定向到标记的相关 URL（例如，通过返回 HTTP 302 响应状态代码），要么充当反向代理，并将流量转发到相关标记，而不会知道客户端。
集中式流量路由服务可能是设计上较为复杂的组件，尤其是当解决方案跨多个区域运行时。 请考虑将流量路由服务部署到多个区域，可能包括托管邮戳的每个区域，并同步映射租户到邮戳的数据存储。 流量路由组件本身可能是 Geode 模式的实例。
例如，可以部署 API 管理 来充当流量路由服务。 API 管理通过在存储租户和标记之间映射关系的 Azure Cosmos DB 集合中查找数据来确定请求的相应标记。 然后，API 管理 会将后端 URL 动态设置为 相关标记的 API 服务。
若要对请求进行异地分发并提供流量路由服务的异地冗余，跨多个区域进行部署 API 管理并使用 Azure Front Door 将流量定向到最近的 API 管理网关。 在此拓扑中，Azure Front Door使用源组、健康探测器以及适当的路由方法来将请求引导离开故障的 API 管理区域网关。 然后，API 管理会将路由通过租户到戳记的映射及其后端配置（或后端资源池）引导至适当的戳记，包括需要时戳记终结点之间的故障转移规则。 如果应用程序未通过 HTTP 或 HTTPS 公开，则可以使用 cross-region Azure 负载均衡器将传入调用分发到区域Azure负载均衡器。 使用 Azure Cosmos DB 的全球分布功能，在每个区域保持映射信息的更新。
如果解决方案包含流量路由服务，请考虑它是否充当 网关 ，并且可以对其他服务执行 网关卸载 ，例如令牌验证、限制和授权。
后续步骤
参与者
Microsoft维护本文。 以下贡献者撰写了本文。
主要作者：
- John Downs |首席软件工程师，Azure模式和实践
其他参与者：
- Federico Arambarri |Clarius 咨询高级软件开发人员
- Daniel Larsen | FastTrack for Azure 首席客户工程师
- Angel Lopez |高级软件工程师、Azure 模式和做法
- Paolo Salvatori | FastTrack for Azure 首席客户工程师
- Arsen Vladimirskiy | Azure FastTrack 首席客户工程师
若要查看非公开的领英个人资料，请登录领英。