你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

在多租户解决方案中组织 Azure 资源

Azure 提供了许多用于组织你的资源的选项。 在多租户解决方案中,规划资源组织策略时,需要考虑特定的权衡。 本文重点介绍 Azure 资源组织的两个核心元素:租户隔离和跨多个资源横向扩展。 它介绍了一些可支持不同租户隔离模型的常见部署方法。 本文还介绍如何使用 Azure 资源限制和配额,以及如何将解决方案扩展到这些限制之外。

关键考虑因素和要求

以下部分介绍在组织 Azure 资源时应做出的租户隔离和缩放注意事项。

租户隔离要求

在 Azure 中部署多租户解决方案时,需要确定是将资源专用于每个租户还是在多个租户之间共享资源。 本文中的多租户方法和服务特定指南部分介绍了许多类别的资源的选项和权衡因素。 一般情况下,租户隔离有一系列选项。 有关如何确定隔离模型的详细信息,请参阅 多租户解决方案的租赁模型

规模

大多数 Azure 资源、资源组和订阅都会施加限制,这些限制可能会影响缩放能力。 可能需要考虑“横向扩展”或“装箱”,以满足计划的租户数或计划的系统负载。

如果确定不会增长到大量租户或很高的负载,请不要过度设计你的横向扩展计划。 但是,如果是为要增长的解决方案进行计划,请仔细考虑你的横向扩展计划。 按照本文中的指南来确保你为了可扩展性构建架构。

如果你有自动化部署过程,并且需要跨资源进行缩放,请确定计划如何在多个资源实例之间部署和分配租户。 例如,考虑如何检测何时接近可以分配给特定资源的租户数量。 你可能打算在需要新资源时及时部署新资源。 或者,可以提前部署一个资源池,以便在需要资源时使用它们。

小窍门

在设计和开发的早期阶段,你可能不会选择实现自动化横向扩展过程。 你仍应考虑并清晰记录在增长时进行缩放所需的过程。 通过记录流程,可以更轻松地在将来出现需要时自动执行这些流程。

此外,请务必避免在整个代码和配置中做出任何假设,这可能会限制缩放能力。 例如,将来可能需要横向扩展到多个存储帐户。 生成应用程序层时,请确保它可以根据活动租户动态切换它连接到的存储帐户。

要考虑的方法和模式

规划 Azure 资源组织时,请考虑以下租户隔离、箱打包、资源标记和部署堆栈的方法。

租户隔离

Azure 资源是通过层次结构进行部署和管理的。 大多数资源都部署到订阅中包含的 资源组中。 管理组 在逻辑上将订阅分组在一起。 所有这些有关层次结构的层都与 Microsoft Entra 租户相关联。

确定如何为每个租户部署资源时,可能会在层次结构中的不同级别进行隔离。 每个选项都对特定类型的多租户解决方案有效,每个选项都有好处和权衡。 对解决方案的不同组件使用不同的隔离模型来组合方法也很常见。

共享资源中的隔离

可以选择在多个租户之间共享 Azure 资源,并在单个实例上运行其所有工作负荷。 有关可能很重要的特定注意事项或选项,请参阅有关你使用的 Azure 服务的 特定于服务的指南

运行资源的单个实例时,需要考虑缩放时可能达到的任何服务限制、订阅限制或配额。 例如,Azure Kubernetes 服务(AKS)群集支持的最大节点数,以及存储帐户支持的每秒事务数上限。 规划在接近这些限制时如何 扩展到多个共享资源

还需要确保应用程序代码完全了解多租户,并限制对特定租户的数据的访问。

作为共享资源方法的示例,假设 Contoso 正在构建包含 Web 应用程序、数据库和存储帐户的多租户软件即服务(SaaS)应用程序。 他们可能会决定部署共享资源来为其所有客户提供服务。 在下图中,所有客户共享一组资源。

显示所有客户共享的单个资源集的图表。

将资源分隔到资源组中

还可以为每个租户部署专用资源。 你可能会为单个租户部署解决方案的整个副本。 或者,你可能在租户之间共享某些组件,并将其他组件专用于特定租户。 此方法称为水平分区

建议使用资源组来管理具有相同生命周期的资源。 在某些多租户系统中,将多个租户的资源部署到单个资源组或一组资源组是很有意义的。

务必考虑如何部署和管理这些资源,包括是由部署管道还是由应用程序启动特定于租户的资源部署。 还需要确定如何 明确确定特定资源是否与特定租户相关。 请考虑使用明确的命名约定策略资源标记或租户目录数据库。

最好对在多个租户之间共享的资源和为单个租户部署的资源使用单独的资源组。 但是,对于某些资源,Azure 会限制可部署到资源组的单个类型的资源数。 此限制意味着在增长时可能需要 跨多个资源组进行缩放

假设 Contoso 有三个客户或租户:Adventure Works、Fabrikam 和 Tailwind。 他们可能会选择在三个租户之间共享 Web 应用程序和存储帐户,然后为每个租户部署单独的数据库。 下图显示了一个包含共享资源的资源组,以及一个包含每个租户的数据库的资源组。

此图显示了一个资源组,其中包含共享资源,另一个资源组包含每个客户的数据库。

将资源组分隔到订阅中

为每个租户部署一组资源时,请考虑使用专用的特定于租户的资源组。 例如,遵循 部署标记模式时,应将每个标记部署到其自己的资源组中。 可以考虑将多个特定于租户的资源组部署到共享 Azure 订阅中。 使用此方法可以轻松配置策略和访问控制规则。

可以选择为每个租户创建一组资源组,并为任何共享资源创建共享资源组。

将特定于租户的资源组部署到共享订阅时,请注意每个订阅中资源组的最大数量,以及适用于部署的资源的其他订阅级别限制。 接近这些限制时,可能需要跨多个订阅进行扩展

在此示例中,Contoso 可能选择为每个客户部署一个戳记,并将戳记放在单个订阅中的专用资源组中。 在下图中,为每个客户都创建了一个包含三个资源组的订阅。

显示包含三个资源组的订阅的关系图。每个资源组都是特定客户的完整资源集。

单独的订阅

可以部署特定于租户的订阅,以完全隔离特定于租户的资源。 还可以通过为每个租户使用单独的订阅来确保每个租户完全使用任何适用的配额,因为订阅中大多数配额和限制都适用。 对于某些 Azure 计费帐户类型,可以采用编程方式创建订阅。 还可以跨订阅使用 Azure 预留适用于计算的 Azure 节省计划

请确保知道可以创建的订阅数。 根据与Microsoft或Microsoft合作伙伴的商业关系,订阅的最大数量可能会有所不同,例如,如果你有 企业协议

在处理大量订阅时,请求增加配额可能更困难。 配额 API 为某些资源类型提供编程接口。 但是,对于许多资源类型,必须通过启动支持案例来请求增加配额。 处理许多订阅时,协调 Azure 支持协议和支持案例也可能很有挑战性。

考虑将特定于租户的订阅分组到 管理组 层次结构中,以便轻松管理访问控制规则和策略。

例如,假设 Contoso 决定为每个客户创建单独的 Azure 订阅,如下图所示。 每个订阅都包含一个资源组,其中包含该客户的完整资源集。

显示三个特定于客户的订阅的关系图。每个订阅都包含一个资源组,其中包含该客户的完整资源集。

每个订阅都包含一个资源组,其中包含该客户的完整资源集。

在此示例中,Contoso 使用管理组来简化其订阅的管理。 通过在管理组的名称中包含 生产 ,它们可以清楚地区分任何生产租户与非生产租户或测试租户。 不同的 Azure 访问控制规则和策略适用于非生产租户。

所有 Contoso 订阅都与单个 Microsoft Entra 租户相关联。 使用单个 Microsoft Entra 租户时,Contoso 可以在其整个 Azure 资产中使用其团队的标识,包括用户和服务主体。

将订阅隔离到单独的 Microsoft Entra 租户中

还可以为每个租户手动创建单个Microsoft Entra 租户,或者将资源部署到客户的Microsoft Entra 租户中的订阅中。 但是,使用多个 Microsoft Entra 租户使得进行身份验证、管理角色分配、应用全局策略和执行许多其他管理操作更加困难。

警告

对于大多数多租户解决方案,我们都建议不要创建多个 Microsoft Entra 租户。 跨 Microsoft Entra 租户工作引入了额外的复杂性,并且降低了缩放和管理资源的能力。 通常,此方法仅由代表其客户运营 Azure 环境的托管服务提供商(MSP)使用。

在努力部署多个Microsoft Entra 租户之前,请考虑是否可以在单个租户中改用管理组或订阅来满足要求。

如果需要在绑定到多个 Microsoft Entra 租户的订阅中管理 Azure 资源,请考虑使用 Azure Lighthouse 来帮助跨 Microsoft Entra 租户管理资源。

例如,Contoso 可以为每个客户创建单独的Microsoft Entra 租户和单独的 Azure 订阅,如下图所示。

示意图显示了每个 Contoso 租户的 Microsoft Entra 租户。每个租户都包含一个订阅以及每个客户所需的资源。Azure Lighthouse 连接到每个 Microsoft Entra 租户。

为其中每个 Contoso 租户配置了 Microsoft Entra 租户。 每个租户都包含一个订阅以及每个用户需要的资源。 Azure Lighthouse 已连接到每个 Microsoft Entra 租户。

装箱

无论资源隔离模型如何,请务必考虑何时以及如何计划跨多个资源扩展解决方案。 当系统上的负载增加或租户数量增加时,可能需要缩放资源。 请考虑“装箱”,以便针对你的需求部署最佳数量的资源。

小窍门

在许多解决方案中,可以更轻松地将整个资源集一起缩放,而不是单独缩放资源。 请考虑遵循“部署缩放单元”模式

资源限制

Azure 资源在解决方案规划中有必须考虑的 限制和配额。 例如,资源可能支持一个并发请求数量上限或特定于租户的配置设置。

配置和使用每个资源的方式也会影响该资源的可伸缩性。 例如,假设应用程序可以在特定数量的计算资源可用时成功响应每秒定义的事务数。 除此之外,可能需要横向扩展。性能测试可帮助你确定资源不再满足要求的时间点。

注释

即使你使用支持多个实例的服务,扩展到多个资源的原则也适用。

例如,Azure 应用程序服务支持横向扩展计划的实例数,但对单个计划的扩展范围有限制。 在大规模多租户应用中,可能会超出这些限制,并需要部署更多应用服务计划以匹配增长情况。

在租户之间共享某些资源时,应首先根据要求确定资源所支持的租户数。 然后,根据你需要为其提供服务的租户总数来部署所需数量的资源。

例如,假设你要部署 Azure 应用程序网关,作为多租户 SaaS 解决方案的一部分。 你查看应用程序设计,在负载下测试应用程序网关的性能,并查看其配置。 然后,确定单个应用程序网关资源可以在 100 个客户之间共享。 根据组织的增长计划,你预计第一年加入 150 个客户,因此你需要计划部署多个应用程序网关来为预期负载提供服务。

此图显示了专用于客户 1 到 100 的应用程序网关,另一个专用于客户 101 到 200 的应用程序网关。

此图显示了两个应用程序网关。 第一个网关专用于第 1 到第 100 个客户,第二个网关专用于第 101 到第 200 个客户。

资源组和订阅限制

无论是使用共享资源还是专用资源,请务必考虑到限制。 Azure 限制了可部署到资源组和可部署到 Azure 订阅的资源数。 接近这些限制时,需要计划跨多个资源组或订阅进行扩展。

例如,假设将每个客户的专用应用程序网关部署到共享资源组中。 对于某些资源,Azure 支持将最多 800 个相同类型的资源部署到单个资源组中。 因此,达到此限制时,需要将任何新的应用程序网关都部署到另一个资源组中。 在下图中,有两个资源组。 每个资源组包含 800 个应用程序网关。

显示两个资源组的关系图。每个资源组包含 800 个应用程序网关。

跨资源组和订阅将租户装箱

还可以跨资源、资源组和订阅应用装箱概念。 例如,当你有几个租户时,你可能能够部署单个资源并在所有租户之间共享它。 下图显示了装箱到单个资源中。

该图显示了装箱到单个资源中。

随着增长,可能会接近单个资源的容量限制,并横向扩展到多个资源(R)。 下图显示了跨多个资源装箱。

该图显示了跨多个资源装箱。

如果达到单个资源组中资源数的限制,则可以将多个资源(R)部署到多个资源组(G)。 下图显示了在多个资源组中跨多个资源装箱。

该图显示了在多个资源组中跨多个资源装箱。

随着规模的增长,可以跨多个订阅(S)部署资源,每个订阅都包含多个资源组(G),这些资源组具有多个资源(R)。 下图显示了在多个资源组和订阅中跨多个资源装箱。

该图显示了在多个资源组和订阅中跨多个资源装箱。

通过规划横向扩展策略,可以扩展到大量租户并保持较高的负载水平。

标记

使用资源标记可将自定义元数据添加到 Azure 资源。 可以使用此元数据来管理资源和跟踪成本。 有关详细信息,请参阅 使用资源标记分配成本

部署堆栈

利用部署堆栈,你能够根据常见生存期将资源分组在一起,即使它们跨越多个资源组或订阅也是如此。 部署特定于租户的资源时,部署堆栈非常有用,尤其是在部署方法要求将不同类型的资源部署到不同位置时,因为存在规模或符合性问题。 部署堆栈还可以在迁出某个租户时,通过一次操作轻松删除与该租户相关的所有资源。 有关详细信息,请参阅 创建和部署 Azure 部署堆栈

要避免的反模式

  • 未针对扩展进行计划。 确保了解所部署的资源的限制。 知道随着负载或租户数的增加,哪些限制可能变得重要。 规划如何在缩放和测试该计划时部署更多资源。

  • 未计划装箱。 即使不需要立即增长,也应计划随着时间的推移而跨多个资源、资源组和订阅扩展 Azure 资源。 避免在应用程序代码中做出假设,比如假设只需要单个资源,尽管将来可能需要扩展到多个资源。

  • 扩展许多单个资源。 如果有复杂的资源拓扑,则很难逐个缩放每个组件。 遵循 部署标记模式,将解决方案缩放为一个单元通常更简单。

  • 在没有必要的情况下,不要为每个租户部署独立资源。 在许多解决方案中,为多个租户部署共享资源更具成本效益且更高效。

  • 无法跟踪租户特定资源。 如果部署特定于租户的资源,请确保了解分配给哪些租户的资源。 此信息对于合规性目的、跟踪成本以及取消预配资源(如果已将租户登出)非常重要。 请考虑使用资源标记来跟踪有关资源的租户信息,并考虑使用部署堆栈将租户特定资源一起组合到逻辑单元中,而不考虑它们所在的资源组或订阅。

  • 使用单独的 Microsoft Entra 租户。 一般来说,预配多个 Microsoft Entra 租户是不明智的。 跨 Microsoft Entra 租户管理资源很复杂。 跨已链接到单个 Microsoft Entra 租户的多个订阅进行缩放更简单。

  • 在不需要扩展时设计复杂的扩展架构。 在某些解决方案中,你确信不会扩展超出特定的规模。 在这些方案中,无需构建复杂的扩展逻辑。 但是,如果你的企业计划增长,则需要做好准备快速扩大规模。

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者:

  • John Downs |Azure 模式和做法的主要软件工程师

其他参与者:

  • Jason Beck | FastTrack for Azure 高级客户工程师
  • Bohdan Cherchyk | FastTrack for Azure 高级客户工程师
  • 劳拉·尼古拉斯 | Azure FastTrack 项目的高级客户工程师
  • 阿森·弗拉基米尔斯基 | 客户首席工程师,FastTrack for Azure
  • Joshua Waddell | FastTrack for Azure 高级客户工程师

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