首先，在设计多租户SaaS APP应用程序时，必须仔细选择最适合APP应用程序需要的租户模式。 租户模型确定如何将每个租户的数据映射到存储。 选择的租户模式会影响APP应用程序的设计和管理。 以后切换到其他模型可能需要很高的成本。
关于可选择的租户模式的讨论如下。
答：如何选择合适的租户模式一般来说，租赁模式不会影响APP应用程序的功能，但可能会影响整个解决方案的其他方面。 以下标准用于评估每个模型：
可扩展性(Scalability )租户每个几个级别租户的存储级别整体存储工作负载租户隔离性(Tenant isolation )数据隔离性能(某个租户的负载是否会影响其他租户)辛opmentcompleter数据结构变化查询语句变化运维复杂度(Operational complexity )性能监控数据结构模式管理租户数据恢复可定制性(Customizability )基于租户需求的体系结构但是请考虑一下APP应用层。 APP应用层被视为整体实体。 将APP划分为许多小组件可能会改变租户模式的选择。 对于租户和存储技术，或者对于所使用的平台，您可以采取与其他组件不同的操作
b、独立单租户为独立单租户数据库应用层隔离
在此模式下，必须为每个租户重复安装一次整个APP应用程序。 APP应用程序的每个实例都是一个独立的实例，因此它不会与其他独立的实例进行交互。 每个APP应用实例只有一个租户，因此只需要一个数据库。 租户有自己的数据库。
每个APP应用程序实例安装在单独的Azure资源组中。 资源组可以属于软件供应商或租户拥有的订阅。 无论如何，供应商都可以为租户管理软件。 每个APP应用程序实例都配置为连接到相应的数据库。
每个租户数据库都部署为独立的数据库。 该模型提供了最大的数据库隔离。 但是，隔离要求为每个数据库分配足够的资源以处理cjdxy负载。 这里的关键是，灵活池不能用于部署在不同资源组或不同订阅上的数据库。 从整体数据库成本的角度看，这种独立的单租户APP模式是最昂贵的解决方案。
供应商管理
即使APP应用实例安装在不同租户的订阅上，供应商也可以访问所有独立APP应用实例中的所有数据库。 访问是通过SQL连接实现的。 通过这种实例间访问，供应商可以集中进行架构管理和数据库查询，用于报告和分析目的。 如果需要这种集中管理，则需要部署将租户标识符映射到数据库URI的目录。 Azure SQL数据库提供了一个分片库，可以与SQL数据库一起使用以提供编录。 分区库正式命名为elastic数据库客户端库。
c、用于支持多租户的APP租户独立数据库该模式使用具有多个数据库的多租户APP应用，所述数据库为每个租户一个数据库。 为每个新租户提供新的数据库。 通过向每个节点添加资源来垂直扩展APP应用层。 或者，添加更多节点以横向扩展APP应用层。 调整基于APP应用程序的工作负载，而不考虑单个数据库的数量或规模。
租户的可定制化
与独立的APP应用模式一样，单租户数据库可以实现强大的租户隔离。 您可以为租户定制和优化任何数据库的模式。 这种定制不会影响APP应用程序的其他租户。 租户可能需要的数据超出所有租户所需的基本数据字段。 此外，其他数据字段可能需要索引。
为每个租户使用一个数据库有助于为一个或多个独立租户定制体系结构。 APP应用程序提供者必须设计程序才能仔细管理模式定制。
弹性池
如果数据库部署在同一资源组中，则可以将其分组到灵活的数据库池中。 这些池为在多个数据库之间共享资源提供了一种经济高效的方法。 与每个数据库都需要足够大才能使用cjdxy的情况相比，此池选项更便宜。 即使可以访问聚合数据库共享资源，也可以实现高度的性能隔离。
Azure SQL数据库提供了监视和管理共享所需的工具。 池级和数据库级性能指标可从Azure门户和Log Analytics获得。 这些指标可以详细了解整体和租户特定的性能。 每个数据库都可以在池之间移动，为特定租户提供保留资源。 这些工具使您能够以经济高效的方式确保卓越的性能。
运维的可伸缩性
azure SQL数据库平台具有许多旨在管理大量数据库的管理功能，包括100，000多个数据库。 这些功能简化了每个租户的数据库模型。
例如，假设系统中只有一个1000租户的数据库。 数据库可能有20个索引。 当系统转换为1，000个单租户数据库时，索引数将增加到20，000个。 作为自动调整的一部分，SQL数据库缺省情况下启用自动索引功能。 自动索引管理所有20，000个索引及其修改
在进行的创建和删除优化。这些自动化操作发生在单个 数据库中，并且不会被其他数据库中的类似操作所协调或限制。自动索引处理繁忙数据库中的索引与繁忙数据库中的索引不同。如果这种巨大的管理任务必须手动完 成，那么这种类型的索引管理定制对于每租户数据库规模而言将是不切实际的。另外在可伸缩性管理上，还拥有以下特色：
* 内置备份
* 高可用
* 磁盘加密
* 性能遥测
自动化
管理操作可以通过devops模型编写和提供。这些操作甚至可以自动化并在应用程序中公开。
例如，您可以自动将单个租户恢复到较早的时间点。恢复只需要恢复存储租户的一个单租户数据库。这种恢复对其他租户没有影响，这证实了管理运营处于每个租户的细粒度级别。
D，支持多租户的单应用+支持多租户的单数据库另一种可用模式是将多租户存储在多租户数据库中。应用程序实例可以具有任意数量的多租户数据库。多租户数据库的模式必须具有一个或多个租户标识符 列，以便可以选择性地检索来自任何给定租户的数据。此外，该模式可能需要一些仅由租户子集使用的表或列。但是，静态代码和参考数据仅存储一次，并由所有租 户共享。
牺牲了租户的隔离
数据：多租户数据库必然会牺牲租户隔离。多个租户的数据一起存储在一个数据库中。在开发过程中，确保查询不会暴露来自多个租户的数据。 SQL数据库支持行级安全性，它可以强制将查询返回的数据限定为单个租户。
处理：多租户数据库跨所有租户共享计算和存储资源。数据库作为一个整体可以被监控，以确保它的性能可以接受。但是，Azure系 统没有内置的方法来监视或管理单个租户使用这些资源。因此，多租户数据库会增加遭遇嘈杂邻居的风险，其中一个过于活跃的租户的工作负载会影响同一数据库中 其他租户的性能体验。附加的应用程序层的监视可以监视租户层的性能。
更低的成本
一般来说，多租户数据库的租户成本最低。独立数据库的资源成本低于同等规模的弹性池。此外，对于租户只需要有限存储的情况，潜在的数百万租户可能存 储在单个数据库中。没有弹性池可以包含数百万个数据库。但是，每个池中包含1000个数据库的解决方案（包含1000个池）可能会达到数百万的规模，有可 能变得难以管理。
以下将讨论多租户数据库模型的两种变体，分片多租户模型是最灵活和可扩展的。
E，支持多租户的单应用+支持多租户的单数据库（不分片）最简单的多租户数据库模式使用单独的独立数据库来为所有租户托管数据。随着越来越多的租户被添加，数据库被扩大了更多的存储和计算资源。这种放大可能是所需要的，尽管总是有一个最终的限制。但是，在达到这个限制之前，数据库变得难以管理。
针对单个租户的管理操作在多租户数据库中实施起来要复杂得多。大规模的这些行动可能会变得无法接受地缓慢。一个很坏的例子就是尝试只恢复某一个租户的某一时间点的数据。
F，支持多租户的单应用+支持多租户的单数据库（分片）大多数SaaS应用程序一次只能访问一个租户的数据。此访问模式允许租户数据分布在多个数据库或分片中，其中任何一个租户的所有数据都包含在一个分片中。结合多租户数据库模式，分片模型允许几乎无限的规模。
管理分片
分片增加了设计和运营管理的复杂性。需要在其中维护租户和数据库之间的映射的目录。此外，还需要管理程序来管理碎片和租户人口。例如，必须设计程序 以添加和删除分片，并在分片之间移动租户数据。一种扩大规模的方法是添加一个新的分片并将其填入新租户。在其他时候，您可能会将人口稠密的分片分成两个密 度较小的分片。几个租户搬迁或停产后，可能会将人口稀少的分片合并在一起。合并将导致更具成本效益的资源利用率。租户也可能在分片之间移动以平衡工作量。
SQL数据库提供了一个拆分/合并工具，与分片库和目录数据库一起使用。提供的应用程序可以拆分和合并分片，并可以在分片之间移动租户数据。该 应用程序还在这些操作过程中维护目录，在移动它们之前将受影响的分片租户标记为离线。移动后，应用程序再次使用新映射更新目录，并将租户标记为重新联机。
更小的数据库更容易管理
通过将租户分布在多个数据库中，分片多租户解决方案可生成更轻松管理的小型数据库。例如，将特定租户恢复到以前的时间点现在涉及从备份恢复单个较小的数据库，而不是包含所有租户的较大数据库。可以选择数据库大小和每个数据库的租户数量来平衡工作负载和管理工作。
shema中的租户标识符ID
根据所使用的分片方法，可能会对数据库模式施加额外的约束。 SQL Database拆分/合并应用程序要求Schema包含分片KEY，通常是租户标识符ID。租户标识符ID是所有分片表主键中的主要元素。租户标识符使 分离/合并应用程序能够快速定位和移动与特定租户相关联的数据。
分片的弹性池
分片多租户数据库可以放置在弹性池中。一般来说，在一个池中拥有许多单租户数据库的成本效率与在少数多租户数据库中拥有许多租户相当。当有大量相对不活跃的租户时，多租户数据库是有利的。
G，混合分片多租户数据库在混合模型中，所有数据库在其Schema中都有租户标识符。这些数据库都能够存储多个租户，并且数据库可以被分割。所以在架构意义上说，它们都是多租户数据库。然而在实践中，其中一些数据库只包含一个租户。无论如何，存储在给定数据库中的租户数量对数据库架构没有影响。
移动租户
在任何时候，您都可以将特定租户迁移到自己的多租户数据库。在任何时候，您都可以改变主意并将租户移回包含多个租户的数据库。在供应新数据库时，您还可以将租户分配给新的单租户数据库。
当可识别的租户群体的资源需求存在较大差异时，混合模式就会发光。例如，假设参与免费试用的租户无法保证与订购租户相同的高性能水平。该政策可能适 用于免费试用阶段的租户存储在所有免费试用租户共享的多租户数据库中。当免费试用租户订阅基本服务级别时，租户可以转移到另一个租户较少的多租户数据库。 支付高级服务级别的用户可以转移到其新的单租户数据库。
池
在这种混合模式中，用户租户的单租户数据库可以放置在资源池中，以降低每个租户的数据库成本。这也是在数据库每租户模型中完成的。
H，租户模型的比较 指标独立应用单租户单数据库分片多租户可扩展性中等1-100s非常高1-100000s无限1-1000000s租户隔离性非常高高低每一个租户的数据库成本高低，使用池最低性能监控和管理只能一个一个租户进行综合和单个综合和单个（偏综合）开发复杂度低低中等运维复杂度从低到高，取决于租户规模从低到中等从低到高，单租户的管理比较复杂转载于:https://www.cnblogs.com/niuben/p/11063777.html