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

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

关键考虑因素和要求

在规划部署策略之前，请明确定义要求。 请考虑下列因素：

• 预期缩放： 确定你希望仅支持少数租户，例如 5 个或更少租户，还是增长到大量租户。 随着租户数量的增长，自动化变得越来越重要。

• 自动或受支持的载入： 指定租户是否应通过自动化过程完成载入，还是启动需要手动载入的请求。 定义团队的任何手动审批步骤，例如防止滥用服务。

• 预配时间： 确定载入过程必须完成的速度。 如果没有明确的答案，请定义此步骤是否应以秒、分钟、小时或天为单位进行度量。

• Azure 市场： 确认是否计划使用 Azure 市场启动部署。 如果这样做，请满足 添加新租户所需的要求。

另请考虑载入和预配步骤、自动化和资源管理责任。

载入和预配步骤

定义并记录载入租户所需的每个任务，即使该过程是手动的。 载入工作流通常包括以下步骤：

1. 接受商业协议。
2. 完成手动审批步骤，例如防止欺诈或滥用服务。
3. 在 Azure 中预配资源。
4. 创建或配置域名。
5. 执行部署后配置任务，例如为租户创建第一个用户帐户，并安全地将其凭据传输到租户。
6. 应用手动配置更改，例如域名系统（DNS）记录更改。

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

请考虑需要为租户预配的特定 Azure 资源。 即使未为每个租户预配专用资源，请考虑在载入新租户时是否有时需要部署资源。 当租户需要特定区域中的数据存储时，可能会出现这种情况。 使用 装箱包装方法时，也可能发生此情况。 在装箱中，在解决方案中接近印花或组件的限制时，将为下一批租户创建另一个实例。

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

自动化

应对云托管解决方案使用自动部署。 在多租户解决方案中，由于以下原因，自动化变得更加重要：

• 规模： 随着租户总体的增加，手动部署过程变得越来越复杂且耗时。 随着租户数量的增长，自动化部署方法更易于缩放。

• 重复： 在多租户环境中，对所有租户的部署使用一致的过程。 手动过程会导致租户之间出现错误或不一致的步骤。 然后，你的环境可能处于不一致的状态，这使得你的团队更难管理解决方案。

• 中断的影响： 与自动部署相比，手动部署的风险更大，并且容易发生中断。 在多租户环境中，部署错误可能会导致影响每个租户的系统范围的中断，从而增加整体影响。

部署到多租户环境时，请遵循以下做法：

• 使用部署管道部署常见资源。

• 使用基础结构即代码（IaC）技术，例如 Bicep、JSON Azure 资源管理器模板（ARM 模板）或 Terraform。

• 如果适用，请使用代码调用 Azure SDK。

如果计划通过 Azure 市场提供解决方案，则应 为新租户提供完全自动化的载入过程。

最大资源容量

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

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

资源管理责任

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

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

• 将租户视为已部署资源的 配置 ，并使用部署管道来部署和配置这些资源。

• 将租户视为 数据，并为租户配置 控制平面 预配和配置基础结构。

以下部分进一步介绍了这些方法。

正在测试

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

要考虑的方法和模式

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

部署戳模式

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

部署圈

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

功能标志

使用 功能标志 逐步向不同租户或用户公开解决方案的新功能或版本，而无需重新部署代码。 请考虑使用 Azure 应用配置 来管理功能标志。 有关详细信息，请参阅 功能标志。

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

要避免的反模式

部署和配置多租户解决方案时，请避免阻止缩放的情况。 以下示例突出显示了常见的反模式：

• 手动部署和测试： 手动部署过程会增加风险并降低部署能力。 请考虑使用管道进行自动部署，以编程方式从解决方案的代码创建资源，或同时使用这两者。

• 租户的专用自定义： 避免部署仅适用于单个租户的功能或配置。 此方法会增加部署和测试过程的复杂性。 请改用每个租户的相同资源类型和代码库。 对临时更改或逐步推出的功能使用 功能标志 等策略。 或者对许可证权利 使用不同的定价层 ，以选择性地为需要它们的租户启用功能。 使用一致的自动化部署过程，即使对于具有隔离或专用资源的租户也是如此。

租户列表作为配置或数据

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

• 使用自动化部署管道部署每个资源。 添加新租户时，请重新配置管道，为每个租户预配资源。

• 使用自动化部署管道部署不依赖于租户数的共享资源。 在应用程序中创建特定于租户的资源。

考虑这两种方法时，请区分将租户列表视为 配置 或 数据。 这种区别还影响如何为系统生成 控制平面 。

租户列表作为配置

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

新租户的载入过程通常包括以下步骤：

1. 通过配置管道或修改管道配置中包含的参数文件手动更新租户列表。

2. 触发要运行的管道。

3. 管道重新部署完整的 Azure 资源集，包括任何特定于租户的新资源。

此方法适用于共享所有资源的少量租户和体系结构。 单个过程部署并配置所有 Azure 资源，从而简化了整体方法。

但是，随着租户数的增加（通常约为 10 个或更多），在添加租户时重新配置管道会变得麻烦。 运行部署管道所需的时间也会增加。 此方法也不容易支持自助租户创建，并且租户载入前的潜在客户时间可能更长，因为需要触发管道运行。

租户列表作为数据

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

载入过程通常包括以下异步步骤：

1. 请求载入租户，例如向系统的控制平面发起 API 请求。

2. 工作流组件接收创建请求并协调剩余步骤。

3. 工作流启动将特定于租户的资源部署到 Azure。 可以使用命令性编程模型（例如 Azure SDK），或者强制触发 Bicep 文件或 Terraform 模板的部署。

4. 部署完成后，工作流会将新租户的详细信息保存到中央租户目录。 为每个租户存储的数据可能包括工作流创建的所有特定于租户的资源的租户 ID 和资源 ID。

此方法为新租户启用资源预配，而无需重新部署整个解决方案。 预配时间通常较短，因为仅部署特定于租户的资源。

但是，这种方法通常更耗时地进行生成。 你的努力需要由租户数或你需要满足的预配时间范围来证明。

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

示例：

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

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

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

如果 Contoso 遵循此模型，则必须执行以下步骤：

1. 在载入新租户时更新其参数文件。

2. 重新运行其管道。

3. 手动跟踪资源限制，例如它们是否以意外的高速率增长，并接近单个 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 |Azure 模式和做法的主要软件工程师

其他参与者：

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

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

相关资源

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