SaaS模式实现架构

SaaS模式实现架构

https://blog.csdn.net/xwq911/article/details/50630266

1、 数据库层：

数据库这一层的设计模式是很清晰的，无外乎只有3种方案：

（1） 所有客户的数据都存放在一个数据库的同一套表中， 在表中增加Company_id等标志字段，表明该记录是属于哪个客户的。

  优点：数据源和数据库的管理都比较简单。和原来的应用没有差别。

缺点：数据权限比较复杂，增加程序的复杂性。如果应用比较复杂，很多数据表都需

要加入客户标志字段，很多查询都需要包括该字段，会比较麻烦。如果有遗漏，、特别是查询条件中遗漏该字段，就会造成一个客户看到另一个客户的数据。

（2） 每个客户独立一个数据库：

在应用服务器中配制不同的数据源，或者使用不同的连接池。

优点：不同客户的数据物理分离，安全性比较好。

  缺点：数据库连接的利用效率不高。Performance 问题会很大

(3) 多Schema，单数据源

这个方案基本是方案2的变种。同一个数据库下可以有多个Schema

优点：除了方案2的优点以外，共享数据源或连接池，效率更高。

缺点：和方案一比较起来，数据库连接池开销会比较大

所有以上方案都是所有客户共享同一个应用（WAR或EAR）。

这里我选择方案三,并结合了方案一，对于登陆/验证/权限，所有的客户共享一个Schema,而对于业务数据，则每个客户一个Schema.

我做了200个不同的Schema，用户名和密码分别是demo1/demo1 到demo200/demo200,大家可以按照不同的用户名和密码登陆。

这台机器就是一台式机，不是专用服务器，网络也是放在我家里的小区宽带上，是通过无线路由器上的网，所以网速可能不太稳定。

原文地址

https://docs.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns

前言

在设计多租户SaaS应用程序时，您必须仔细选择最适合您应用程序需求的租户模型。租户模型确定每个租户的数据如何映射到存储。您选择的租户模式会影响应用程序设计和管理。以后切换到另一个模型有时代价昂贵。

关于可选择的租户模型的讨论如下。

A，怎么选择一个合适的租户模型

一般来说，租赁模式不会影响应用程序的功能，但它可能会影响整体解决方案的其他方面。以下标准用于评估每个模型：

可扩展性（Scalability）

租户的数量级

每个租户的存储级别

整体存储

工作负载

租户隔离性（Tenant isolation）

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

单租户成本（Per-tenant cost）

数据库成本

开发复杂度（Development complexity）

数据结构的变化

查询语句的变化

运维复杂度（Operational complexity）

性能监控

数据结构schema管理

租户数据恢复

灾备

可定制化程度（Customizability）

根据租户的需求自定义架构的容易程度

这个租户的讨论集中在数据层。但考虑一下应用层。应用程序层被视为一个整体实体。如果将应用程序划分为许多小型组件，您的租户模型选择可能会发生变化。对于租户和存储技术或使用的平台，您可以对其他组件进行不同的处理

B，独立的单租户应用+独立的单租户数据库

应用层隔离



在这个模型中，对于每一个租户，整个应用程序需要重复安装一次。应用程序的每个实例都是独立实例，因此它不会与任何其他独立实例交互。每个应用程序实例只有一个租户，因此只需要一个数据库。租户拥有自己的数据库。

这里写图片描述

每个应用程序实例都安装在独立的Azure资源组中。资源组可以属于软件供应商或租户拥有的订阅。无论哪种情况，供应商都可以为租户管理软件。每个应用程序实例都配置为连接到其相应的数据库。

每个租户数据库都作为独立数据库进行部署。该模型提供了最大的数据库隔离。但隔离需要为每个数据库分配足够的资源来处理其高峰负载。这里重要的是，弹性池不能用于部署在不同资源组或不同订阅中的数据库。这种限制使得这种独立的单租户应用程序模型成为从整体数据库成本角度来看最昂贵的解决方案。

供应商管理

即使应用程序实例安装在不同的租户订阅中，供应商也可以访问所有独立应用程序实例中的所有数据库。访问是通过SQL连接实现的。这种跨实例访问可以使供应商能够集中化架构管理和跨数据库查询以用于报告或分析目的。如果需要这种集中式管理，则必须部署一个目录，将租户标识符映射到数据库URI。 Azure SQL数据库提供了与SQL数据库一起使用以提供目录的分片库。分区库被正式命名为弹性数据库客户端库（ Elastic Database Client Library）。

C，支持多租户的应用+每一个租户独立数据库

这个模式使用具有多个数据库的多租户应用程序，均为一个租户一个数据库。为每个新租户提供一个新的数据库。通过为每个节点添加更多资源来垂直扩展应用程序层。或者通过添加更多节点来横向扩展应用程序层。缩放基于应用程序的工作负载，并且与个体数据库的数量或规模无关。

这里写图片描述



租户的可定制化

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

使用每个租户一个数据库，为一个或多个独立租户定制架构很容易实现。应用程序供应商必须设计程序来小心管理架构自定义。

弹性池

当数据库部署在同一资源组中时，可以将它们分组为弹性数据库池。这些池提供了跨多个数据库共享资源的具有成本效益的方式。该池选项比要求每个数据库足够大以容纳它所经历的使用高峰要便宜。即使汇集的数据库共享资源访问权限，他们仍然可以实现高度的性能隔离。

这里写图片描述

Azure SQL数据库提供了配置，监视和管理共享所需的工具。池级别和数据库级别的性能指标均可在Azure门户中以及通过Log Analytics获得。这些指标可以深入了解总体和租户特定的性能。各个数据库可以在池之间移动，为特定租户提供预留资源。这些工具使您能够以经济高效的方式确保良好的性能。

运维的可伸缩性

Azure SQL Database平台具有许多旨在管理大量数据库的管理功能，例如超过100,000个数据库。这些功能使每租户数据库模式合理。

例如，假设系统只有一个1000租户数据库作为其唯一的一个数据库。数据库可能有20个索引。如果系统转换为拥有1000个单租户数据库，则索引数量将增至20,000。在SQL Database中，作为自动调整（Automatic tuning）的一部分，默认情况下启用自动索引功能。自动索引为您管理所有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

租户隔离性 非常高 高 低

每一个租户的数据库成本 高 低，使用池 最低

性能监控和管理 只能一个一个租户进行 综合和单个 综合和单个（偏综合）

开发复杂度 低 低 中等

运维复杂度 从低到高，取决于租户规模 从低到中等 从低到高，单租户的管理比较复杂