多租户解决方案部署和配置的体系结构方法

无论体系结构和用于实现它的组件如何，都需要部署和配置解决方案的组件。 在多租户环境中，请务必考虑如何部署 Azure 资源，尤其是在为每个租户部署专用资源时，或者根据系统中的租户数重新配置资源时。 在此页上，我们为解决方案架构师提供了有关部署多租户解决方案的指导，我们演示了在规划部署策略时要考虑的一些方法。

关键考虑因素和要求

在规划部署策略之前，必须清楚地了解你的要求。 具体注意事项包括：

• 预期缩放： 你希望支持少量租户（例如五个或更少），还是会增长到大量租户？
• 自动或受支持的载入： 当租户准备好加入时，他们能否按照自动化过程自行完成该过程？ 或者，新租户是否启动请求，并在收到请求后手动载入它们？ 团队是否需要手动审批步骤，例如防止滥用服务？
• 预配时间： 当租户准备好加入时，载入过程需要多长时间才能完成？ 如果没有明确的答案，请考虑是否应以秒、分钟、小时或天为单位来衡量。
• Azure 市场： 是否计划使用 Azure 市场启动部署？ 如果这样做， 则需要满足这些要求才能添加新租户。

还应考虑加入和预配步骤、自动化和资源管理责任。

载入和预配步骤

考虑在载入租户时需要执行的所有作，并记录此列表和工作流，即使手动执行。 载入工作流通常包括以下内容：

• 接受商业协议。
• 为新租户配置系统所需的信息的集合。
• 例如，手动审批步骤，以防止欺诈或滥用服务。
• 在 Azure 中预配资源。
• 创建或配置域名。
• 执行部署后配置任务，例如为租户创建第一个用户帐户，并安全地将其凭据传输到租户。
• 手动配置更改，例如 DNS 记录更改。

清楚地记录载入新租户所需的工作流。

此外，请考虑为租户预配的特定 Azure 资源。 即使未为每个租户预配专用资源，请考虑在载入新租户时是否有时需要部署资源。 如果租户要求其数据存储在特定区域，或者接近解决方案中的标记或组件的限制，并且需要为下一批租户创建另一个实例，则可能会出现这种情况。

考虑载入过程是否可能会对其他租户造成干扰，尤其是共享同一基础结构的用户。 例如，如果需要修改共享数据库，此过程是否会导致其他租户可能注意到的性能影响？ 请考虑是否可以避免这些影响，或者通过在正常工作时间之外执行载入过程来缓解这些影响。

自动化

对于云托管的解决方案，始终建议自动部署。 使用多租户解决方案时，由于以下原因，部署自动化变得更加重要：

• 规模： 随着租户填充的增加，手动部署过程变得越来越复杂且耗时。 随着租户数量的增长，自动化部署方法更易于缩放。
• 重复： 在多租户环境中，对所有租户的部署使用一致的过程。 手动过程引入了错误几率，或者某些租户而不是其他租户执行的步骤。 这些手动过程使环境处于不一致状态，这使得团队难以管理解决方案。
• 中断的影响： 与自动部署相比，手动部署的风险和容易中断的风险要大得多。 在多租户环境中，系统范围的服务中断（由于部署错误）的影响可能很高，因为每个租户都可能会受到影响。

部署到多租户环境时，应使用部署管道，并使用基础结构即代码（IaC）技术，例如 Bicep、JSON ARM 模板、Terraform 或 Azure SDK。

如果计划通过 Azure 市场提供解决方案，则应为新租户提供完全自动化的载入过程。 SaaS 履行 API 文档中介绍了此过程。

最大资源容量

以编程方式将租户资源部署到共享资源时，请考虑每个资源的容量限制。 接近该限制时，可能需要创建另一个资源实例来支持进一步缩放。 请考虑部署的每个资源的限制，以及将触发部署另一个实例的条件。

例如，假设解决方案包含一个 Azure SQL 逻辑服务器，并且解决方案为每个租户预配该服务器上的专用数据库。 单个逻辑服务器有限制，其中包括逻辑服务器支持的最大数据库数。 接近这些限制时，可能需要预配新服务器，以便可以继续加入租户。 请考虑是自动执行此过程还是手动监视增长。

资源管理责任

在某些多租户解决方案中，为每个租户部署专用的 Azure 资源，例如每个租户的数据库。 或者，可以决定将一组租户托管在资源的单个实例上，因此你已决定部署到 Azure 的资源集的租户数。 在其他解决方案中，部署一组共享资源，然后在载入新租户时重新配置资源。

每个模型都需要以不同的方式部署和管理资源，必须考虑如何部署和管理预配的资源的生命周期。 以下两种常见方法如下：

• 将租户视为部署的资源 的配置 ，并使用部署管道来部署和配置这些资源。
• 将租户视为 数据，并为租户配置 控制平面 预配和配置基础结构。

下面提供了对这些方法的进一步讨论。

正在测试

计划在每个部署期间和之后全面测试解决方案。 可以使用自动测试来验证解决方案的功能和非功能行为。 确保测试租户隔离模型，并考虑使用 Azure Chaos Studio 等工具来故意引入模拟实际中断的故障，并验证解决方案是否正常工作，即使组件不可用或出现故障。

要考虑的方法和模式

Azure 体系结构中心和更广泛的社区中的多个设计模式与多租户解决方案的部署和配置相关。

部署戳模式

部署标记模式涉及为租户或租户组部署专用基础结构。 单个模具可能包含多个租户，或者它可能专用于单个租户。 可以选择部署单个标记，也可以跨多个标记协调部署。 如果为每个租户部署专用戳记，还可以考虑以编程方式部署整个图章。

部署圈

部署通道 使你能够在不同时间向不同基础结构组推出更新。 此方法通常用于 部署标记模式，可以根据租户首选项、工作负荷类型和其他注意事项将图章组分配给不同的通道。 有关详细信息，请参阅 部署圈。

功能标志

使用功能标志 可以逐步向不同的租户公开解决方案的新功能或版本，同时维护单个代码库。 请考虑使用 Azure 应用配置 来管理功能标志。 有关详细信息，请参阅 功能标志。

有时，你需要有选择地为某些客户启用特定功能。 例如，你可能有不同的 定价层 ，允许访问某些功能。 功能标志通常不是这些方案的正确选择。 相反，请考虑构建一个过程来跟踪和强制执行每个客户拥有 的许可证权利 。

要避免的反模式

部署和配置多租户解决方案时，请务必避免阻止缩放的情况。 其中包括：

• 手动部署和测试。 如上所述，手动部署过程会增加风险并降低部署能力。 请考虑使用管道进行自动化部署，以编程方式从解决方案的代码创建资源，或同时使用这两者。
• 租户的专用自定义。 避免部署仅适用于单个租户的功能或配置。 此方法会增加部署和测试过程的复杂性。 请改用每个租户的相同资源类型和代码库，并针对临时更改或逐步推出的功能使用 功能标志 等策略，或者对许可证权利 使用不同的定价层 来选择性地为需要它们的租户启用功能。 使用一致的自动化部署过程，即使对于具有隔离或专用资源的租户也是如此。

租户列表作为配置或数据

在多租户解决方案中部署资源时，可以考虑以下两种方法：

• 使用自动化部署管道部署每个资源。 添加新租户时，请重新配置管道，为每个租户预配资源。
• 使用自动化部署管道部署不依赖于租户数的共享资源。 对于为每个租户部署的资源，请在应用程序中创建它们。

考虑这两种方法时，应区分将租户列表视为 配置 或 数据。 在考虑如何为系统生成 控制平面 时，此区别也很重要。

租户列表作为配置

将租户列表视为配置时，请从集中式部署管道部署所有资源。 载入新租户时，可以重新配置管道或其参数。 通常，重新配置通过手动更改进行，如下图所示。

载入新租户的过程可能类似于以下内容：

1. 更新租户列表。 这通常是通过配置管道本身或通过修改管道配置中包含的参数文件来手动发生的。
2. 触发要运行的管道。
3. 管道重新部署完整的 Azure 资源集，包括任何特定于租户的新资源。

此方法通常适用于少量租户，以及共享所有资源的体系结构。 这是一种简单的方法，因为可以使用单个过程部署和配置所有 Azure 资源。

但是，当你接近更多租户（例如 5 到 10 或更多）时，添加租户时重新配置管道会变得繁琐。 运行部署管道所需的时间通常也会显著增加。 此方法也不容易支持自助租户创建，并且租户载入前的潜在客户时间可能更长，因为需要触发管道运行。

租户列表作为数据

将租户列表视为数据时，仍使用管道部署共享组件。 但是，对于需要为每个租户部署的资源和配置设置，必须部署或配置资源。 例如，控制平面可以使用 Azure SDK 创建特定资源或启动参数化模板的部署。

载入新租户的过程可能类似于以下内容，并且会异步执行：

1. 请求加入租户，例如，通过向系统的控制平面发起 API 请求。
2. 工作流组件接收创建请求并协调剩余步骤。
3. 工作流启动将特定于租户的资源部署到 Azure。 这可以通过使用命令性编程模型（例如，使用 Azure SDK）或强制触发 Bicep 或 Terraform 模板的部署来实现。
4. 部署完成后，工作流会将新租户的详细信息保存到中央租户目录。 为每个租户存储的数据可能包括工作流创建的所有特定于租户的资源的租户 ID 和资源 ID。

通过执行此作，可以预配新租户的资源，而无需重新部署整个解决方案。 为每个租户预配新资源所需的时间可能较短，因为只需要部署这些资源。

但是，这种方法通常需要更耗时的构建，并且花费的努力需要由租户数量或需要满足的预配时间范围来证明。

有关此方法的详细信息，请参阅 多租户控制平面的注意事项。

示例：

Contoso 为其客户运行多租户解决方案。 目前，他们拥有 6 个租户，预计在未来 18 个月内将增长到 300 个租户。 Contoso 遵循 具有每个租户方法的专用数据库的多租户应用 。 他们部署了一组应用服务资源和在其所有租户之间共享的 Azure SQL 逻辑服务器，并为每个租户部署专用的 Azure SQL 数据库，如下图所示。

Contoso 使用 Bicep 部署其 Azure 资源。

选项 1 - 对一切使用部署管道

Contoso 可能考虑使用部署管道部署其所有资源。 其管道部署一个 Bicep 文件，其中包含其所有 Azure 资源，包括每个租户的 Azure SQL 数据库。 参数文件定义租户列表，Bicep 文件使用 资源循环 为每个列出的租户部署数据库，如下图所示。

如果 Contoso 遵循此模型，则需要更新其参数文件作为新租户加入的一部分。 然后，他们需要重新运行其管道。 此外，他们需要手动跟踪它们是否接近任何限制，例如它们是否以意外的高速率增长，并接近单个 Azure SQL 逻辑服务器上支持的最大数据库数。

选项 2 - 结合使用部署管道和命令性资源创建

或者，Contoso 可能会考虑分离 Azure 部署的责任。

Contoso 使用 Bicep 文件来定义应部署的共享资源。 共享资源支持其所有租户并包括租户映射数据库，如下图所示。

然后，Contoso 团队生成一个控制平面，其中包括租户载入 API。 当销售团队完成向新客户的销售后，Microsoft Dynamics 会触发 API 开始载入过程。 Contoso 还提供自助服务 Web 界面供客户使用，并触发 API。

API 异步启动载入新租户的工作流。 工作流启动新的 Azure SQL 数据库的部署，这可以通过以下方法之一完成：

• 使用 Azure SDK 启动定义 Azure SQL 数据库的第二个 Bicep 文件的部署。
• 使用 Azure SDK 通过 管理库命令性地创建 Azure SQL 数据库。

部署数据库后，工作流会将租户添加到租户列表数据库，如下图所示。

正在进行的数据库架构更新由其应用程序层启动。

供稿人

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

主要作者：

• John Downs | 首席软件工程师

其他参与者：

• Bohdan Cherchyk |适用于 Azure 的高级客户工程师 FastTrack
• 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure

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

后续步骤

• 查看 更新多租户解决方案的注意事项。
• 考虑 存储和数据的体系结构方法。
• 请考虑 如何在多租户解决方案中使用 Azure 资源管理器。