Saas.数据隔离持久化方案_saas大客户部署隔离

为什么要进行数据隔离

有人把Saas和传统软件提供服务模式比喻为：打井和自来水，打井是一次性花钱以后想怎么用随便，自来水嘛则用多少给多少钱，不是那么自由了。

同样：原来冬天吃不上菜，每家自己都有腌菜瓮，这个瓮只有冬天用，浪费地方。有人就开始建一个存储腌菜场所，那这个腌菜容器必须要区别哪些是哪家的。Saas产品在做微服务共享的时候，各个租户自己的数据是不能共享的，需要隔离。

隔离方案

存储数据以关系数据库为主，其他NoSql数据库为功能性辅助，可以分为：

1. 分库： 不同租户使用不同库

2. 分表：不同租户使用不同表

3. 表内添加TenantID进行区分

4. 混合方案

隔离数据库：分库

适用场景： 独立部署要求，大客户

优点：编码简单，单租户项目制系统开发一样； 数据库性能优化可以根据租户不同方案区分； 数据备份容易；

缺点：成本比较高，需要单独部署数据库。

技术实现：Sping中的AbstractRoutingDataSource；Mycat中间件。具体实现参考：

中间件.Mycat 初体验_闲猫的博客-CSDN博客

Spring.动态数据源AbstractRoutingDataSource_闲猫的博客-CSDN博客

共享数据库，隔离数据结构：分表

不同的租户使用不同的表，当然还有业务维度。比如：学生表，老师表

租户1：student_1, teacher_1

租户2：student_2, teacher_2

优点：分库成本太高，分表兼具优化和备份的方便，而且不需要那么大的成本

缺点：创建租户需要生成表即DDL操作，如：根据student的Schema创建student_1表，功能上能复杂点：1. 表什么时候创建；2. 创建哪些表；3. 增购功能时怎么区分不同的表； 4. Base表Schema怎么存储 都需要设计好。参考方案是：设计功能权限时，将表和功能关联，在新建租户的时候创建涉及的表，根据开通的功能找到映射的表。

难点：开发在写代码的时候不清楚租户ID，sql只会写student，而实际执行的sql需要修改：student_1，参考方案：Saas.数据权限控制（Sql解析）_闲猫的博客-CSDN博客

扩展：student和teacher都是表，是否也可以抽象为一张表，root表为只有id，updateby, updatetime ,createby ,createtime ,isdeleted ,remark等系统字段，student表是业务key为“student”的root的分表，root_student_1 （租户1的学生表）

适用场景：一般不单独使用，不符合产品开发递进法则(刚开发成本比较高，刚开始项目资源不足)，实际开发都是先开发单系统，经过验证业务后再进行多租户改造，所以这个阶段分库成本最低。

共享数据结构：表内添加TenantID

方案描述

说起来很简单，任何系统似乎加个tenant_id(租户id)就变成saas系统了。比如原来的用户登录是：

select * from student where email='abc@qq.com'

改成

select * from student where email='abc@qq.com' and tenant_id =1;

对于复杂业务的saas系统，这样做法非常危险，而且开发效率很低。你想想如果那个程序员写sql时候忘了加 “ and tenant_id =1” . 结果不堪设想。

场景：适合数据量小的场景，中小企业，免费获取客户场景

优点： 不需要额外资源，只需要增加一个字段，然后修改Sql就行

缺点： 没办法按照租户优化优化，按照租户备份数据复杂，故障隔离难

难点： 框架层面需要解决tenant_id条件添加以及insert的时候value中的数据添加。参考博文：Saas.数据权限控制（Sql解析）_闲猫的博客-CSDN博客

混合方案

一个系统比较大， 基本不会所有的都按照一种方案。比如：

1. 数据量较小的登录日志 就没必要分库，分表。 添加一个tenantid很容易解决

2. 数量超大的日志，操作行为表，必须分表，可能还得从多个维度分表,如：时间段，租户ID

3. 不同业务场景： 一般都会按照组拆分，为了各自维护简单，都进行分库了。而每个库内按照实际情况又会进行分表或者添加tenantid方案

4. 扩展：元数据驱动方案，上面几种方案是从：业务，运维，成本，开发等方面考虑，容易想到，如果是Saas中前期都可以支撑，但要想接KA大客户，就比如会有特性化开发，表现为：对原有功能扩展如表字段的扩展，也有完全单独定制的页面。 怎么搞？ 元数据，在【分表.扩展】一栏再继续抽象，简单说就是把Mysql中的Schema表和数据表，全部搬到Saas平台自助控制，这个方案并不是单单数据持久化方案，也需要囊括其他需求，这就是Saas的难点，既要有全局视野，也需要专注一点。

附录

术语

DB：DataBase简称，数据库

DS：DataSource简称，数据源

TenantID：多租户中的租户ID ，唯一来标识一个租户的

Schema：定义，本文指的是数据表的定义

懒加载：在使用资源的时候才进行加载