多租户解决方案的租赁模型

有多种方法可以考虑如何在解决方案中使用租户。 选择的方法在很大程度上取决于是否以及如何在租户之间共享资源。 直观地说，你可能希望避免共享 任何 资源，但随着业务规模和载入更多租户，这种方法会很快变得昂贵。

考虑多租户的各种模型时，首先考虑如何为组织定义租户、业务驱动因素以及计划缩放解决方案的方式会很有帮助。 本文提供指导来帮助技术决策者评估租赁模型及其权衡。

定义租户

首先，需要为组织定义 租户 。 考虑客户是谁。 换句话说，你向谁提供服务？ 有两种常见模型：

• 企业到企业 （B2B） 。 如果客户是其他组织，则可能将租户映射到这些客户。 但是，请考虑你的客户是否有部门（团队或部门），以及他们是否在多个国家/地区存在。 如果这些子组有不同的要求，可能需要将单个客户映射到多个租户。 同样，客户可能想要维护服务的两个实例，以便他们可以保持其开发和生产环境彼此分离。 通常，单个租户有多个用户。 例如，客户的所有员工都是单个租户中的用户。
• 企业对消费者（B2C）。 如果客户是使用者，则与客户、租户和用户关联通常更为复杂。 在某些情况下，每个使用者可能是单独的租户。 但是，请考虑你的解决方案是否可供家庭、朋友、俱乐部、协会或其他可能需要访问和管理其数据的其他组使用。 例如，音乐流式处理服务可能同时支持单个用户和家庭，在将每个帐户类型分成租户时，它可能会以不同的方式处理这些帐户类型。

租户的定义会影响构建解决方案时需要考虑或强调的一些事项。 例如，请考虑以下类型的租户：

• 如果你的租户是个人或家庭，你可能需要特别关心如何处理个人数据，以及你服务的每个司法管辖区内的数据主权法律。
• 如果你的租户是企业，则可能需要注意客户对法规合规性的要求、数据隔离以及确保满足指定的服务级别目标（SLO），例如运行时间或服务可用性。

如何确定要使用的模型？

选择租赁模型不仅仅是技术决策。 这也是一个商业决定。 需要考虑以下问题：

• 你的业务目标是什么？ 是否更有必要降低每个租户的资源成本或为每个租户提供最佳体验？
• 客户是否会接受所有形式的多租户？ 每个多租户模型如何影响合规性要求或客户的合规性要求？
• 单租户解决方案是否会扩展到未来的增长愿望？
• 运营团队有多大，基础结构管理可以自动化多少？
• 你的客户是否期望你满足服务级别协议（SLA），或者你是否拥有你要面向的 SLA？

如果希望企业能够扩展到大量客户，请务必部署共享基础结构。 否则，必须维护大量且不断增长的资源实例。 除非为每个租户预配和使用专用订阅，否则为每个客户部署单个 Azure 资源可能是不可持续的。 在多个租户之间共享同一 Azure 订阅时， Azure 资源配额和限制 可能会开始应用，并且部署和重新配置这些资源的运营成本会随每个新客户增加。

相反，如果希望业务只有少数客户，则可能需要考虑使用专用于每个客户的单租户资源。 此外，如果客户的隔离要求很高，即使单租户基础结构方法成本更高，也可能合适。

租户和部署

接下来，需要确定是否应区分逻辑租户和部署。

例如，请考虑音乐流式处理服务。 最初，你可以构建一个解决方案，该解决方案可以轻松处理数千（甚至数万）用户。 但是，随着你继续增长，你可能会发现需要复制解决方案或其某些组件，以便扩展到新的客户需求。 这意味着需要确定如何将特定客户分配到解决方案的特定实例。 你可以随机分配客户，或者按地理位置分配客户，或者填写单个实例，然后启动另一个（垃圾箱打包）。 但是，可能需要保留客户的记录及其数据和应用程序的可用基础结构，以便可以将流量路由到正确的基础结构。 在此示例中，可以将每个客户表示为单独的租户，然后将用户映射到包含其数据的部署。 租户与部署之间存在一对多映射，可以自行在部署之间移动租户。

相比之下，请考虑为律师事务所创建云软件的公司。 客户可能坚持使用自己的专用基础结构来保持符合法规要求。 因此，需要准备好从一开始就部署和管理解决方案的许多不同实例。 在此示例中，部署始终包含单个租户，租户映射到其自己的专用部署。

租户和部署之间的主要区别在于如何强制实施隔离。 当多个租户共享单个部署（一组基础结构）时，通常依赖于应用程序代码和数据库中的租户标识符来保持每个租户的数据分开。 如果租户具有自己的专用部署，则它们具有自己的基础结构，因此代码在多租户环境中运行可能不太重要。

部署有时称为 超级租户 或 邮票。

收到特定租户的请求时，需要将其映射到保存该租户数据的部署，如下所示：

若要了解详细信息，请参阅 将请求映射到租户。

租户隔离

多租户体系结构设计中最大的注意事项之一是每个租户所需的隔离级别。 隔离可能意味着不同的内容：

• 拥有单个共享基础结构，每个租户都有单独的应用程序实例和单独的数据库。
• 共享一些常见资源，但为每个租户保留其他资源。
• 将数据保留在单独的物理基础结构上。 在云中，此配置可能需要为每个租户使用单独的 Azure 资源。 在极端情况下，它甚至可能意味着使用 专用主机部署单独的物理基础结构。

不应将隔离视为离散属性，而应该将其视为连续属性。 可以根据要求，部署与同一体系结构中的其他组件相比隔离的体系结构的组件或多或少。 下图演示了隔离的连续性：

隔离级别会影响体系结构的许多方面，包括：

• 安全性。 如果在多个租户之间共享基础结构，则返回对另一个租户的响应时，需要特别小心不要从一个租户访问数据。 你需要为标识策略提供坚实的基础，并且需要在授权过程中考虑租户和用户标识。
• 成本。 共享基础结构可由多个租户使用，因此成本更低。
• 性能。 如果共享基础结构，则系统的性能可能会因为更多的客户使用它而受到影响，因为资源可能消耗得更快。 使用模式异常的租户可能会加剧性能问题。
• 可靠性。 如果使用单个共享基础结构集，则一个组件出现问题可能会导致所有租户中断。
• 响应单个租户需求。 部署专用于一个租户的基础结构时，可能能够将资源的配置适应该特定租户的要求。 你甚至可以在定价模型中考虑此功能，从而允许客户为独立部署支付更多费用。

解决方案体系结构可能会影响可用的隔离选项。 例如，请考虑三层解决方案体系结构：

• 用户界面层可能是共享多租户 Web 应用，所有租户都访问单个主机名。
• 中间层可以是具有共享消息队列的共享应用程序层。
• 数据层可以是独立的数据库、表或 Blob 容器。

可以考虑在每个层上使用不同级别的隔离。 应根据许多注意事项（包括成本、复杂性、客户要求以及可在达到 Azure 配额和限制之前部署的资源数量）来决定共享的内容和隔离内容。

常见租赁模型

建立要求后，请根据一些常见的租赁模型和相应的部署模式评估它们。

自动单租户部署

在自动化单租户部署模型中，为每个租户部署一组专用基础结构，如以下示例所示：

应用程序负责启动和协调每个租户资源的部署。 通常，使用此模型的解决方案使用基础结构即代码（IaC）或 Azure 资源管理器 API。 如果需要为每个客户预配完全独立的基础结构，则可以使用此方法。 规划部署时，请考虑使用 部署标记模式 。

好处： 此方法的主要好处是隔离每个租户的数据，从而减少意外泄露的风险。 这种安全措施对于一些具有高法规合规性开销的客户来说非常重要。 此外，租户不太可能影响彼此的系统性能，有时称为 干扰邻居 问题的问题。 可以在租户之间逐步推出更新和更改，从而减少系统范围的服务中断的可能性。

风险： 如果使用此方法，则成本效率较低，因为不会在租户之间共享基础结构。 如果单个租户需要特定的基础结构成本，则 100 个租户可能需要 100 倍的成本。 此外，持续维护（如应用新配置或软件更新）可能非常耗时。 考虑自动执行作过程，并考虑逐步通过环境应用更改。 还应考虑其他跨部署作，例如整个车队中的报告和分析。 同样，请务必规划如何跨多个部署查询和作数据。

完全多租户部署

相反，可以考虑完全多租户部署，其中所有组件都共享。 只有一组基础结构可以部署和维护，并且所有租户都使用它，如下图所示：

好处： 此模型很有吸引力，因为作具有共享组件的解决方案比为每个租户使用单个资源的成本更低。 即使需要部署较高层或资源的 SKU 来考虑负载增加，总体部署成本通常仍低于一组单租户资源的成本。 此外，如果用户或租户需要将数据移动到另一个租户，则你也许能够更新租户标识符和密钥，并且可能不必在两个单独的部署之间迁移数据。

风险：

• 请务必为每个租户分隔数据，不要在租户之间泄露数据。 可能需要管理分片数据。 此外，可能需要关注单个租户对整个系统的影响。 例如，如果大型租户尝试执行大量查询或作，则可能会影响其他租户。

• 如果这样做对你很重要，请确定如何 跟踪 Azure 成本并将其关联到租户。

• 对于单个部署，维护可能更简单，因为只需更新一组资源。 但是，这通常更危险，因为更改可能会影响整个客户群。

• 可能还需要考虑缩放。 如果拥有一组共享的基础结构，则更有可能达到 Azure 资源规模限制 。 例如，如果使用存储帐户作为解决方案的一部分，随着规模的增加，对该存储帐户的请求数可能会达到存储帐户可以处理的限制。 为了避免达到资源配额限制，可以考虑部署多个资源的实例池（例如，多个 AKS 群集或存储帐户）。 甚至可以考虑在部署到多个 Azure 订阅的资源之间分配租户。

• 可以缩放单个部署的距离可能有限制，这样做的成本可能会以非线性方式增加。 例如，如果有单个共享数据库，则以非常高的规模运行时，可能会耗尽其吞吐量，并且需要为增加的吞吐量支付更多费用，以满足需求。

垂直分区部署

无需选择这些缩放的极端值之一。 相反，可以采用此方法来考虑垂直分区租户：

• 使用单租户部署和多租户部署的组合。 例如，你可能在多租户基础结构上拥有大多数客户的数据和应用程序层，但为需要更高性能或数据隔离的客户部署单租户基础结构。
• 在地理上部署解决方案的多个实例，并将每个租户映射到特定的部署。 当你在不同的地理位置拥有租户时，此方法特别有效。

以下示例演示了某些租户的共享部署，以及另一个租户的单租户部署：

好处： 由于你仍在共享某些基础结构，因此可以使用共享多租户部署获得一些成本优势。 你可以为某些客户部署更便宜的共享资源，例如正在试用评估服务的客户。 你甚至可以向客户收取更高的费率来使用单租户部署，这有助于你恢复一些成本。

风险： 代码库需要设计为支持多租户部署和单租户部署。 如果计划允许在部署之间进行迁移，则需要考虑如何将客户从多租户部署迁移到其自己的单租户部署。 还需要了解每个部署中的哪些租户，以便可以传达有关系统问题的信息或向相关客户升级。

水平分区部署

还可以考虑水平分区部署。 在水平部署中，你有一些共享组件，但使用单租户部署维护其他组件。 例如，可以生成单个应用程序层，然后为每个租户部署单个数据库，如下图所示：

好处： 水平分区部署有助于缓解干扰性邻居问题：如果确定系统上的大部分负载是由特定组件引起的，则可以为每个租户部署单独的组件。 例如，数据库可能会吸收系统的大部分负载，因为查询负载很高。 如果单个租户向解决方案发送大量请求，则数据库的性能可能会受到负面影响，但其他租户的数据库（和共享组件（如应用程序层）仍然不受影响。

风险： 使用水平分区的部署，仍需要考虑组件的自动部署和管理，尤其是单个租户使用的组件。

测试隔离模型

无论选择哪种隔离模型，请务必测试解决方案，以验证一个租户的数据是否不会意外泄露到另一个租户，并且任何 干扰邻居 的影响都是可接受的。 请考虑使用 Azure Chaos Studio 故意引入模拟实际中断的故障，并验证解决方案的复原能力，即使组件出现故障也是如此。

供稿人

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

主要作者：

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

其他参与者：

• 查德·基特尔 |Azure 模式和做法的主要软件工程师
• Paolo Salvatori | FastTrack for Azure 首席客户工程师
• 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure

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

后续步骤

考虑 租户的生命周期