在设计多租户SaaS应用程序时，必须仔细选择最适合应用程序需求的租户模型。租户模型确定每个租户的数据如何映射到数据库中。选择的租赁模式将影响应用程序的设计和管理，而后期修改的代价非常大。00如何正确选择租户模型

一般的，租户模型并不影响应用程序的功能，但是很可能会影响整个解决方案的其他方面，以下列出了评价模型的几个标准：

1、可扩展性租户数量每个租户的存储骨架存储负载

2、租户隔离性数据隔离和性能（一个租户的负载是否会影响到其他租户）

3、每个租户的费用数据库费用

4、开发复杂度schema的修改查询语句的修改

5、运维复杂度监控与管理性能schema管理租户数据恢复容灾

6、定制化易于支持特定于租户特定或租户类特定的模式定制。租户模型主要在数据层，但是应用层被视为单片实体。如果将应用程序划分为许多小组件，则租户模型的选择可能会改变。针对不同的租户，存储技术，或平台，你可以对不同的组件做相应的处理。01独立的单租户app和单租户数据库（应用程序级别隔离）

此模型下，整个应用程序需要给每个租户单独安装一次。每个应用程序的实例是独立的，所以它不会影响其它实例。

每个实例只有一个租户，因此只需要一个数据库。租户独享数据库。

例如，每个应用程序实例都安装在一个单独的Azure资源组中。

资源组可以属于软件供应商提供的订阅服务。

在这种情况下，供应商可以管理租户的软件。每个应用程序实例被配置为连接到其对应的数据库。

每个租户数据库部署为独立数据库。该模型提供了最大的数据库隔离。但是隔离需要将足够的资源分配给每个数据库来处理其峰值负载。

有一点重要的是，弹性池不能用于部署在不同资源组或不同订阅中的数据库。这个限制使得独立的单租户应用程序从整体数据库成本的角度来看是最昂贵的解决方案。

供应商管理

即使应用程序实例安装在不同的租户订阅中，供应商也可以访问所有独立应用程序实例中的所有数据库。访问是通过SQL连接实现的。这种跨实例访问可以使供应商集中模式管理和跨数据库查询以用于报告或分析目的。

如果需要这种集中管理，必须部署将租户标识符映射到数据库URI的目录。Azure SQL数据库提供了一个与SQL数据库一起使用以提供目录的共享库。共享库被正式命名为弹性数据库客户端库。02多租户应用程序，每个租户一个数据库

这种模式的应用程序是多租户共用，其中每个租户拥有单独的数据库，因此数据库数量非常多。供应商为每个新租户提供新的数据库。通过添加每个节点的资源，应用层被垂直放大。或者通过添加更多的节点水平地缩放应用程序。缩放基于负载，并且独立于单个数据库的数量或规模。

租户定制化

与独立的应用程序模式一样，单租户数据库的使用提供了强大的租户隔离。指定单租户数据库的应用程序中，任何一个给定数据库都可以为其租户定制和优化。此定制不会影响应用程序中的其他租户。也许租户可能需要超出所有租户所需的基本数据字段的数据。此外，额外的数据字段可能需要索引。

使用每个租户一个数据库的模式，为一个或多个单独租户做定制化是很容易实现的。应用程序供应商必须小心的控制定制化的规模在合理范围内。

弹性数据库池子

当数据库部署在同一资源组中时，它们可以被分组到弹性数据库池中。池子提供了跨多个数据库共享资源的低成本方式。这种方法比要求每个数据库足够大以适应使用峰值更划算。即使汇集起来的数据库共享同一资源，它们仍然可以实现高度的性能隔离。

Azure SQL数据库提供了配置、监视和管理共享所必需的工具。在Azure门户和日志分析中都有池级和数据库级性能度量。度量可以给出对聚合和租户特定性能的深刻洞察。单个数据库可以在池之间移动，以向特定租户提供保留资源。这些工具使您能够以成本有效的方式确保良好的性能。

单租户数据库操作规模

Azure SQL数据库平台具有许多管理功能，用于管理大量数据库，如超过100000个数据库。这些特性使得数据库对租户模式具有合理性。

例如，假设一个系统有1000个租户数据库作为它唯一的一个数据库。数据库可能有20个索引。如果系统转换为具有1000个单租户数据库，则索引的数量增加到20000个。在SQL数据库中，作为自动调整的一部分，默认情况下启用自动索引功能。自动索引为您管理所有20000个索引及其正在进行的创建和删除优化。这些自动化操作发生在单个数据库中，并且它们不被其他数据库中的类似动作协调或限制。自动索引在繁忙的数据库中比在不那么繁忙的数据库中处理索引的方式不同。如果要手动完成这个庞大的管理任务，这种类型的索引管理定制化在单租户数据库中是不切实际的。

此规模下其它管理特点如下：内置备份高可用性磁盘加密性能监测

自动化

管理操作可以脚本化，并通过DevOps模型提供。这些操作甚至可以在应用程序中自动化和公开。

例如，您可以将单个租户的恢复自动化到较早的时间点。恢复只需要恢复存储租户的一个租户数据库。这种恢复对其他租户没有影响，这证实了管理操作处于每个个体租户的细粒度水平。03多租户数据库的多租户应用程序

另一种可用模式是将多租户数据存储在多租户数据库中。应用程序实例可以具有任意数量的多租户数据库。多租户数据库的架构必须具有一个或多个租户标识符列，以便可以选择性地检索来自任何给定租户的数据。

此外，该模式可能需要仅由租户子集使用的几个表或列。然而，静态代码和引用数据只存储一次，并由所有租户共享。

牺牲租户隔离性

数据：

多租户数据库必须牺牲租户隔离。多个租户的数据被存储在一个数据库中。在开发过程中，确保查询从不公开来自不止一个租户的数据。SQL数据库支持行级安全性，它可以强制将从查询返回的数据范围化为单个租户。

处理：

一般来说，多租户数据库的租户成本最低。独立数据库的资源成本低于等效大小的弹性池。此外，对于租户只需要有限存储的场景，潜在的数百万租户可以存储在单个数据库中。没有弹性池可以包含数以百万计的数据库。

然而，每个池包含1000个数据库的解决方案，有1000个池，可能达到数百万的规模，有可能变得难以管理。

下面讨论了多租户数据库模型的两种变体，其中多租户模型是最灵活和可扩展的。04多租户单数据库的多租户应用程序

最简单的多租户数据库模式使用一个独立的数据库来为所有租户提供数据。随着更多租户的加入，数据库被放大，存储和计算资源也更多。这个规模可能是所有需要的，虽然总是有一个最终的规模限制。然而，在达到该限制之前，数据库变得难以管理。

集中于单个租户的管理操作在多租户数据库中实现更为复杂。在规模上，这些行动可能变得缓慢得令人难以接受。一个例子就是一个租户的数据及时恢复。05分片的多租户数据库的多租户应用程序

大多数SaaS应用程序每次只访问一个租户的数据。这种访问模式允许租户数据分布在多个数据库或分片上，其中任何一个租户的所有数据都包含在一个分片中。结合多租户数据库模式，一个清晰的模型允许几乎无限的规模。

管理分片

共享增加了设计和操作管理的复杂性。需要一个目录来维护租户和数据库之间的映射。此外，需要管理程序来管理分片和租户数量。例如，必须设计程序来添加和移除分片，并在分片之间移动租户数据。一种扩大规模的方法是添加新的分片并用新的租户来填充。

在其他时候，你可能会把数量稠密的分片分割成两个不那么稠密的分片。在几个租户被搬走或停用之后，你可能会将人口稀少的分片合并在一起。合并将导致更具成本效益的资源利用率。租户也可以在分片之间移动以平衡负载。

SQL数据库提供了一个分割/合并工具，它可以与共享库和目录数据库一起工作。所提供的应用程序可以拆分和合并分片，并且可以在分片之间移动租户数据。应用程序还在这些操作期间维护目录，在移动之前将受影响的租户标记为脱机。移动之后，应用程序再次使用新的映射更新目录，并将租户标记为在线返回。

小型数据库更易于管理

通过将租户分布在多个数据库上，共享的多租户解决方案导致更小的数据库更易于管理。例如，将特定租户恢复到先前的时间点，包括备份恢复单个较小的数据库，而不是包含所有租户的更大的数据库。可以选择数据库大小和每个数据库租户的数量，以平衡负载和管理复杂度。

租户标识符

SQL数据库拆分/合并应用程序要求架构包含分割键，通常是租户标识符。租户标识符是所有共享表主键的主要元素。租户标识符使分割/合并应用能够快速定位和移动与特定租户相关联的数据。

分片弹性池

多个租户数据库可以被放置在弹性池中。一般来说，池中有许多单租户数据库，与多租户数据库中的许多租户一样具有成本效益。当有大量相对不活跃的租户时，多租户数据库是有利的。06混合式分片多租户数据库模型

在混合模型中，所有数据库在其模式中都有租户标识符。数据库都能够存储不止一个租户，并且数据库可以被共享。因此，在模式意义上，它们都是多租户数据库。然而在实践中，这些数据库中只有一个租户。无论如何，存储在给定数据库中的租户数量对数据库模式没有影响。

迁移

在任何时候，您可以将特定租户移动到其自己的多租户数据库中。在任何时候，你都可以改变主意，把租户移回包含多个租户的数据库中。在提供新数据库时，还可以将租户分配给新的单租户数据库。

当可识别的租户群体的资源需求存在很大差异时，混合模型优势明显。例如，假设参与免费试用的租户不能保证订阅租户的性能相同。

该策略可能是在免费试用阶段的租户被存储在多租户数据库中，该数据库是在所有免费试用租户之间共享的。当免费试用租户订阅基本服务级别时，租户可以移动到另一个租户数据库中，该租户可能租户较少。支付高级服务级别的订户可以移动到其自己的新租户数据库中。

资源弹性池

在混合模型中，单租户数据库可以被放置在资源池中以降低每个租户的数据库成本。

租户模式比较

下表总结了主要租户模式之间的差异。