Saas
多租户意味着同一个应用上有不用的用户隔离。这是非常典型的saas模型。你可以用不同的隔离级别来实现多租户。
1. 行级别： 在每个数据库表里添加tenat_id字段，然后在每个查询语句也添加相应的tenant_id
2. schema 级别： 每个租户有在同一个数据库内自己独立命名空间。 可以容易使用 PostgreSQL schemas 来实现. 后续会介绍使用Mysql如何实现。
3. 数据库级别：每个租户创建独立的数据库。 非常少用到。
下面是比较这几种实现方式的优缺点：
| 行级别 | schema级别 | db级别 | |
|---|---|---|---|
| 租户创建时间 | ⚡️ 新增一条记录 | 🐢 慢 (需要创建schema和表 ) | 🐌 非常慢 + 可能需要运维支持 |
|
租户间泄漏数据风险 |
💥 忘记添加 WHERE |
✅ 比较安全 | ✅ 非常安全 |
| 侵入性 | 🍝 所有代码需要添加tenant_id 列条件 |
👍 一般 | 👍 非常少 |
|
Need shared tables or merging data across tenants 不同租户间共享和合并数据 |
✅ 没任何问题 | 👍sql可以跨数据查询 | 🚫 sql无法实现，只能应用代码实现 |
|
Running DB migrations 数据库迁移 |
⚡️ O(1) | 🐢 O(n) | 🐌 O(n) |
| Conventionality | 👍 Standard Rails | 🛠 Occasionally at odds with Rails assumptions | 🤔 |
|
Additional costs 其它成本 |
👍 无 | 👍 无 | ❓ 创建大量数据成本 |
|
Operational overhead 额外运维成本 |
✅ 无 | 👍有可能，需要维护大量表 | 🛠 需要维护大量数据库 |
|
Complexity 复杂度 |
🍝 到处添加tenant_id |
🌴 利用PG特性 search_path |
🤔 |
|
Where possible 可行性 |
🌍 非常容易实现 | ⚠️ 确认是否是托管数据库。是否有权限 | ⚠️ 是否能按需创建数据库 |
|
Cost of switching 切换租户成本 |
⚡️ 设置变量。tenant_id =? | ⚡️ 需要设置search_path |
🐢 需要创建独立数据库连接 |
|
Extract a single tenant’s data 抽取独立租户数据 |
🛠 有点麻烦 | 👍 容易 | 👍 非常容易 |
MySQL vs PostgreSQL schemas
Mysql没有类似PostgreSQL schemas功能，但Mysql数据库可以实现类似方式使用。切换数据库时候不需要创建独立数据库连接，在Mysql可是通过use 语句来选择数据库。类型在 PG数据库使用search_path功能。类似方案，可以在表名前在租户数据库前缀。
Mysql缺点：是你需要保证数据库间没有名字冲突。创建租户时候，需要有创建数据库的权限。如果你没有需要。而PG只需要在当前数据库创建schemas的权限，并且不用关系名字冲突。即使在托管的数据库服务，也能很方便实现。
常见的架构模式有以下几种：
这个模型中，应用层和数据层都是隔离的。
应用程序的每个实例都是独立实例。
租户拥有自己独立的数据库，每个应用程序实例只需要一个数据库。
对租户的管理独立于系统之外，对于每一个租户，整个应用程序需要重复安装一次。供应商都可以为租户管理软件。每个应用程序实例都配置为连接到其相应的数据库。
优点：为不同的租户提供独立的应用实例和数据库，有助于简化数据模型和业务模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复系统或数据均比较简单，系统间也不会相互影响。
问题：数据库层面，每个租户数据库都作为独立数据库进行部署。该模型提供了最大的数据库隔离。但隔离需要为每个数据库分配足够的资源来处理其高峰负载。这里重要的是， 弹性池不能用于部署在不同资源组或不同订阅中的数据库。这种限制使得这种独立的单租户应用程序模型成为从整体数据库成本角度来看最昂贵的解决方案；应用层面，每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题。运维层面，应用和数据库的安装数量会随租户的数量线性递增，随之带来维护成本和购置成本的增加。
这个模型中，应用层是共享的，数据层都是隔离的。
应用程序仅部署一套，所有租户实例共享。
租户仍拥有自己独立的数据库，应用程序需对接多个租户的数据库。
对租户的管理由配置中心（Config Server）管理，配置中心提供了配置，监视和管理共享所需的功能，供应商使用这些工具为租户管理软件。对于每一个租户，整个应用程序仅需要安装一次，应用程序实际请求结合配置中心请求相应的数据库。
优点：为不同的租户提供独立数据库，有助于简化数据模型扩展设计，满足不同租户的独特需求；如果出现故障，数据恢复均比较简单，也可以自动将单个租户恢复到较早的时间点。因为恢复只需要恢复存储租户的一个单租户数据库。这种恢复对其他租户没有影响，这证实了管理运营处于每个租户的细粒度级别。应用层面的维护成本和购置成本有所减少。
问题：数据库层面，同模型一；应用层面，每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题。运维层面，数据库的运维问题同模式一，应用层面的运维在版本控制的问题上难度有所增加。
这个模型中，应用层是共享的，数据库共享，但数据是隔离的。
应用程序和数据库仅部署一套，所有租户共享。
多个或所有租户共享Database，也就是说共同使用一个数据库，但是每个租户一个Schema（也可叫做一个user），使用表进行数据隔离数据库。底层库比如是：DB2、ORACLE等，一个数据库下可以有多个SCHEMA。
应用程序需对接多个租户的数据库。
对租户的管理由配置中心（Config Server）管理，同模式二。
优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。
问题：数据库层面，如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据；应用层面，配置中心需要对租户信息进行完整且合理的分配和维护。
模型与模型三的差别在于共享数据库，共享 Schema，共享数据表。也就是说共同使用一个数据库一个表使用字段进行数据隔离。如表中增加TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的模式。
简单来讲，即每插入一条数据时都需要有一个客户的标识。这样才能在同一张表中区分出不同客户的数据，这也是我们系统目前用到的(tenant_id)。
优点：方案的维护和购置成本低，允许每个数据库支持的租户数量最多。
缺点：隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；数据备份和恢复最困难，需要逐表逐条备份和还原。
模式五与之前的模式的最大区别是，在原有的web Service进行细化拆分，优化成 网关+前台+中台+数据存储的模式。
网关用于接收租户的请求，并发送给前台。
前台的数量与租户一致，每一个租户对应一个前台服务，方便针对租户进行个性化定制。
中台负责提供处理所有的业务请求，中台不关心租户是谁，将重心关注在业务的处理上。配置中心用于配置租户的接口权限、流程定制等相关配置信息。结合业务逻辑返回给前台特定租户的相关信息。
数据库模式参考模式四。
优点：有利于定制不同租户的个性化需求。例如：交互界面不同、工作流不同等等。
服务只需要根据用户需求在前台做相应的横向扩展即可；
不同租户间服务相互独立，互不影响。
缺点：模块划分需要做好划分，重点注重业务之间的低耦合；
调用链路变长，需要做一定的优化处理；
模块纵向拆分后，后期研发和运维难度均会有所增加；
原文链接：https://www.cnblogs.com/codemind/p/13081336.html ; https://blog.csdn.net/haponchang/article/details/104246317
