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

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

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

定义租户

首先需要为组织定义 租户 。 请考虑谁是您的客户，或者谁接收您的服务。 有两种常见模型：

• 企业到企业（B2B）： 如果客户是其他组织，则可能将租户映射到这些客户。 但是，请考虑你的客户是否有部门（如团队或部门）以及他们是否在多个国家或地区存在。 如果这些子分组有不同的要求，你可能需要将单个客户映射到多个租户。 同样，客户可能想要维护服务的两个实例，以便他们可以保持其开发和生产环境彼此分离。 单个租户通常有多个用户。 例如，客户的所有员工都是单个租户中的用户。

• 企业对消费者（B2C）： 如果客户是使用者，则与客户、租户和用户关联通常更为复杂。 在部分情况下，每位消费者可能都使用单独的租户。 但是，请考虑你的解决方案是否可供家庭、朋友团体、俱乐部、协会或其他可能需要共同访问和管理其数据的团体使用。 例如，一个音乐流媒体服务可能同时支持个人用户和家庭，当涉及到将每个帐户类型分离成租户时，可能会以不同的方式进行处理。

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

• 如果你的租户是个人或家庭，你可能需要考虑如何处理个人数据，以及你服务的每个司法管辖区的数据主权法律。

• 如果你的租户是企业，则可能需要注意客户对法规合规性的要求及其数据的隔离。 确保满足指定的服务级别目标（SLO），例如运行时间或服务可用性。

确定要使用的模型

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

• 业务目标： 考虑是降低每个租户的成本，还是最大程度地提高租户体验与战略目标保持一致。

• 合规： 考虑客户是否会接受所有形式的多租户架构。 每个多租户模型如何影响合规要求或客户的合规要求？

• 规模： 考虑单租户解决方案是否能够满足未来增长的需求。

• 自动化： 考虑运营团队的大小以及可以自动执行多少基础结构管理。

• 服务级别协议 (SLA)：考虑您的客户是否期望您满足 SLA，或者您是否有面向的 SLO。

如果预计自己的业务将扩展至拥有大量客户，请务必部署共享的基础结构。 否则，你必须维护大量且不断增加的资源实例。 除非为每个租户预配和使用专用订阅，否则为每个客户部署单独的 Azure 资源可能不可持续。 在多个租户之间共享同一 Azure 订阅时， Azure 资源配额和限制 可能会适用，并且部署和重新配置这些资源的运营成本会随每个新客户一起增加。

相反，如果你预计自己的业务只会有少许客户，那么可以考虑采用专用于每个客户的单租户资源。 同样，如果客户的隔离要求很高，则即使成本更高，单租户基础结构方法可能也比较合适。

租户和部署

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

例如，请考虑音乐流式处理服务。 最初，你可以构建一个解决方案，该解决方案可以轻松处理数千甚至数万个用户。 但是，随着组织的不断发展，你可能会发现需要复制解决方案或其某些组件，以扩展到新的客户需求。 若要完成此任务，需要确定如何将特定客户分配到解决方案的特定实例。 可以通过随机分配、按地理位置分配或先填满一个实例再启动另一个实例（也称为箱打包）来分配客户。 但是，可能需要保留客户及其数据和应用程序所在的基础结构的记录，以便可以将流量路由到正确的位置。 在此示例中，可以将每个客户表示为单独的租户，并将用户映射到包含其数据的部署。 这方法在租户与部署之间创建了一对多关系，您可以根据需要在不同部署之间灵活迁移租户。

作为对照，我们以为律师事务所创建云软件的公司为例。 客户可能坚持使用自己的专用基础结构来维护其合规性监管要求。 因此，需要从一开始就准备好部署和管理解决方案的许多不同实例。 在此示例中，部署始终包含单个租户，而租户映射到其自己的专用部署。

租户和部署之间的一个重要差别是如何强制实施隔离。 当多个租户共享单个部署（一组基础结构）时，你通常依赖于应用程序代码和数据库中的租户标识符来使每个租户的数据保持独立。 当租户有自己的专用部署时，他们有自己的基础结构，因此代码考虑多租户环境可能不太重要。

有时会看到被称为超级租户或缩放单元的部署。

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

有关详细信息，请参阅将请求映射到租户。

租户隔离

多租户体系结构设计中最大的注意事项之一是每个租户所需的隔离级别。 隔离可以引用以下配置：

• 具有单个共享基础结构，其中包括应用程序的单独实例和每个租户的独立数据库。

• 共享一些常见资源，又为每个租户保持其他资源的独立性。

• 将数据保留在独立的物理基础结构上。 在云中，此配置可能需要为每个租户使用单独的 Azure 资源。 在极端情况下，甚至可以要求使用 专用主机部署单独的物理基础结构。

不要将隔离视为离散属性，而是将其视为光谱。 可以根据您的要求，部署比同一体系结构中的其他组件更隔离或更开放的组件。 下图展示了隔离的连续体：

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

• 安全： 如果在多个租户之间共享基础结构，在返回对另一个租户的响应时，请注意不要从一个租户访问数据。 你需要为标识策略提供坚实的基础，并且在授权过程中需要同时考虑租户和用户标识。

• 成本： 多个租户可以使用共享基础结构，因此成本更低。

• 性能： 如果共享基础结构，则随着更多客户使用它，系统的性能可能会下降，因为资源可能消耗得更快。 具有异常使用模式的租户可能会恶化性能问题。

• 可靠性： 如果使用单个共享基础结构集，则一个组件出现问题可能会导致所有租户中断。

• 对单个租户需求的响应能力： 部署专用于一个租户的基础结构时，可能能够将资源的配置适应该特定租户的要求。 你甚至可以在定价模型中考虑此功能，以允许客户为独立部署支付更多费用。

解决方案体系结构可能会影响可用的隔离选项。 以三层式解决方案体系结构为例：

• 用户界面层可能是共享的多租户 Web 应用。 所有租户都访问单个主机名。

• 中间层可以是具有共享消息队列的共享应用程序层。

• 数据层可以是独立的数据库、表或 Blob 容器。

可以对每个层使用不同的隔离级别。 您应该根据多个因素，决定哪些内容需要共享，哪些需要隔离，这些因素包括成本、复杂性、客户要求，以及在达到 Azure 配额和限制之前您可以部署的资源数量。

常见租户模型

确定要求后，请根据一些常见租户模型和相应部署模式对其进行评估。

自动单租户部署

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

应用程序负责启动和协调各租户资源的部署。 通常，使用此模型生成的解决方案广泛使用基础结构即代码 或 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。

后续步骤

考虑 租户的生命周期。