1.简介
在多租户环境中，多个客户（租户）共享相同的应用程序，它们在相同的操作系统上，相同的硬件上以相同的数据存储机制运行。客户之间的区别是在应用程序设计期间实现的。客户不会共享或看到彼此的数据。与每个用户都有自己专用环境的专用系统相比，这样做的主要动机是降低每位用户的成本。
> In a multi-tenant application, most of the software stacks — up until the application itself, — are shared by the different tenants.
软件即服务（SaaS）应用程序经常使用多租户。SaaS的本质归结为以下事实：供应商开发软件，将其放置在服务器上，维持其性能，安全性，客户可用性（通常为复数形式），支付服务器费用和其他费用。对于客户而言，这种方法更便宜，而对于卖方而言则是值得的（因为它解决了许可和盗版问题，而且最重要的是，可以为多个客户提供一项服务）。
2.单租户vs多租户
2.1单租户
该软件和支持基础结构的单个实例为单个客户提供服务。通过单一租赁，每个客户都有自己的独立数据库和软件实例。本质上，此选项不会发生共享。
2.2多租户
多租户意味着该软件及其支持基础结构的单个实例为多个客户提供服务。每个客户共享该软件应用程序，还共享一个数据库。每个租户的数据都是孤立的，其他租户看不到。
> Single-Tenant and Multi-Tenant architectures comparison
3.数据库和多租户
3.1一个通用数据库，一个通用模式
一切都存储在一个数据库和公用表中。要实现此选项，先决条件是引入一个附加的字段TenantID（或您喜欢的CustomerID）以分隔客户之间的信息。
好处：
- 当我们将所有信息存储在一组表中时，更易于开发，更新和维护
- 添加客户就像在客户表中创建新记录一样简单
缺点：
- 没有灵活性，所有客户端都使用同一组表和列。出现了非典型客户会导致问题和打补丁。
- 浪费人力和精力开发自己的权限分离系统：(
- 备份和恢复问题。一个表不能简单地删除和创建，因为它包含其他客户端的数据。您必须查找所需的行并将其覆盖，这很麻烦。
解析度：
如果您有很多客户并且缺乏资金/服务器，并且所有硬盘驱动器不会同时消失，那么这是个不错的选择。
3.2一个通用的数据库，不同的模式
来自不同客户端的信息存储在不同的表中。模式是包含某些资源（例如表）的“命名空间”，可以在其上授予某些权限。
好处：
- 由于有了这些架构，访问共享发生在DBMS级别，因此不需要我们进行其他开发（我们节省了工时）
- 更少的数据库-更少的硬件资源，再次保存
- 可扩展性不错-在添加客户端时，我们会基于标准架构创建一个新架构，配置访问权限，然后完成。尽管所有架构都基于标准架构，但由于保留了隔离性，因此它们可能会发生一些更改，因此可以编辑列，表等。
缺点：
- 由于表在逻辑上而不是物理上分开，因此不同客户的数据存储在一起。
- 备份和恢复存在问题。因为只有一个数据库，所以如果来自一个客户端的表已折叠，则数据库的简单回滚将把所有客户端的数据返回到过去，这是不可接受的。在这里，您将需要选择性地回滚以及合并新旧数据。该过程比仅回滚整个数据库要复杂一些。
解析度：
如果客户准备好生活在共享环境中，则选择均衡的方案。
3.3分开的数据库
代码在客户端之间共享（使用通用的UI和业务逻辑），数据在逻辑上（可能物理上）在客户端之间共享。
好处：
- 简单的可扩展性（添加客户端足以创建和配置新数据库）
- 轻松扩展-您可以在不同的服务器上分发不同客户端的数据库
- 个性化-您可以为某些客户端进行个别设置（甚至将数据库放置在另一个DBMS上）
- 简单备份-如果某个客户端在数据库回滚期间发生故障，则其他客户端不会受到任何影响；
缺点：
- 昂贵。一台服务器支持的数据库数量有限，这意味着这种解决方案将需要更多的硬件（而不是将所有内容存储在一个数据库中的方法），更多的硬件-更多的管理员，服务器机房空间和电费
- 再次昂贵。当一台服务器上有多个数据库，其总容量大于RAM大小时，数据将被转储到交换文件中，因此访问硬盘非常慢。出路是购买更多服务器
解析度：
对于主要目标是安全性且愿意付款的客户（例如银行），这是最佳解决方案。
4.实际例子
> Serverless single database multi-tenant architecture on Google Cloud
5.优势
- 节省成本：共享环境成本，这些节省（来自供应商）通常转移到软件成本中。
- 数据聚合：不是从可能具有不同数据库模式的多个数据源收集数据，而是将所有客户的所有数据存储在单个数据库模式中。因此，在客户之间运行查询，挖掘数据并寻找趋势要简单得多。
- 简化版本管理：该软件包仅需要安装在单个服务器上。相同的软件版本对所有客户可用。
- 供应商利用的维护和更新：客户无需支付昂贵的维护费用即可保持软件最新。供应商推出新功能和更新。
6.缺点
- 开发的复杂性增加：由于额外的自定义（自定义品牌，工作流程中的差异，数据模型的扩展，访问控制），以及维护每个租户元数据的需求，因此多租户应用程序需要进行更大的开发工作。
- 增加的新发行版风险：由于只有一个软件实例为多个租户服务，因此即使请求更新并且仅对一个租户有用，对该实例的更新也可能导致所有租户停机。此外，应用新版本导致的一些错误和问题可能会在其他租户对应用程序的个性化视图中体现。
- 有限的自定义：虽然您确实增加了集成优势，但是对数据库的自定义更改通常不是一个选项，因为它在多个用户之间共享。
- 降低的安全性：由于在同一数据库上允许多个用户（与您的组织不相关），因此这种更广泛的访问降低了对安全性的控制。示例如下：一个租户可以访问邻居的数据，数据被意外返回给错误的租户，或者一个租户在资源共享方面给另一个租户带来了负面影响。可以利用这些漏洞谋取个人利益。
- 糟糕的性能：您的共同租户可能正在消耗共享资源并拖慢了速度。容量应该具有弹性并可以根据需要扩展，但并非总是如此。
- 更新：如果您依赖与其他SaaS产品的集成并且更新了其系统，则可能会导致这些连接的应用程序出现问题。
7.用例
- 软件即服务（SaaS）/应用即服务（AaaS）
- 平台即服务（PaaS）
- 基础架构即服务（IaaS）[可用于服务的硬件和软件]
- 通常，多个客户使用相同的算法，数据，应用程序堆栈。核心功能可以相同或模块化，并且可以基于每个客户端进行自定义。
8.总结
- 多租户=该软件及其支持基础结构的单个实例为多个客户提供服务。每个客户共享该软件应用程序，还共享一个数据库。每个租户的数据都是孤立的，其他租户看不到。
- 使用一个数据库，一种通用模式可以节省金钱（使用更少的服务器），但代价是更大的安全性和备份风险以及更大的开发工作量。除非您知道分区是什么，否则;）使用一个数据库和多个模式作为成本与开发工作/安全性和备份风险之间的平衡平衡。对于主要目标是安全性并准备为此付费的客户，请使用单独的数据库。
- 好处包括简化的数据聚合，发布，更新，维护管理；他们通常更具成本效益
- 缺点包括复杂的开发，发行和更新风险，有限的自定义，降低的安全性和较差的性能。
- 当多个客户使用相同的算法，数据和应用程序堆栈时，可用于SaaS，PaaS，IaaS应用程序。核心功能可以相同或模块化，并且可以基于每个客户端进行自定义。