多租户结构模型

平台Tenant1 Schema

data

分销商主租户

模式3：共享数据库，共享数据表

平台客户Tenant1.2Schema

DB

平台客户Tenant3.2Schema

平台客户Tenant2.3Schema

模式2：应用层共享一套，平台级租户、客户级租户共享数据库，均使用独立的schema

模式2暂不考虑，结合目标客户数据和部署要求，建议考虑兼容模式1和模式3的方式支持

平台 顶级租户 data

平台客户Tenant2.2Schema

平台型分销商

1

平台客户Tenant3.1Schema

Tenant data

平台客户Tenant2.1Schema

中小微企业或业务体量小客户

每个业务单元一个租户

C平台 顶级租户 data

分销商类租户

平台客户Tenant1.3Schema

销售、商务、门户、流量渠道

N

客户群体

Schema

模式1：应用层共享一套，平台租户独立数据库，平台租户下的客户租户与平台租户共享数据库，独立的schema这个模型中，平台应用层是共享的，平台租户级的数据层都是数据库级隔离的。应用程序仅部署一套，所有租户实例共享，应用程序需对接多个平台级租户的数据库。平台级租户的数据量大，对安全要求和数据敏感度高，使用独立数据库：优点：1、提供独立数据库，有助于简化数据模型扩展设计，满足不同租户的独特需求；2、出现故障，数据恢复均比较简单，也可以自动将单个租户恢复到较早的时间点。因为恢复只需要恢复存储租户的一个单租户数据库。这种恢复对其他租户没有影响；缺点：数据库层面，每个租户数据库都作为独立数据库进行部署。该模型提供了最大的数据库隔离。但隔离需要为每个数据库分配足够的资源来处理其高峰负载。这里重要的是， 弹性池不能用于部署在不同资源组或不同订阅中的数据库。这种限制使得这种独立的单租户应用程序模型成为从整体数据库成本角度来看最昂贵的解决方案；应用层面，每个租户若存在个性化定制，则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题；运维层面，应用和数据库的安装数量会随租户的数量线性递增，随之带来维护成本和购置成本的增加。

销售、商务

集团主租户

平台客户Tenant3.3Schema

平台客户Tenant1

模式1：应用层共享一套，平台租户独立数据库，平台租户下的客户租户与平台租户共享数据库，独立的schema

客户群体归属（客户关系、收入）

数据库

大型、集团型企业或业务存在多业务单元大体量业务

平台客户类租户

单个分销客户租户

租户模型

平台型分销商客户

大型、集团型企业或业务存在多业务单元大体量业务高价值有私有化部署诉求

分销客户类租户

平台客户Tenant1.1Schema

平台Tenant3 data

模式2：应用层共享一套，平台级租户、客户级租户共享数据库，均使用独立的schema平台级租户下客户级租户的数据量相对较小，与平台级租户共享数据库，但一个Tenant一个Schema。将每个租户关联到同一个数据库的不同 Schema，租户间数据彼此逻辑不可见，上层应用程序的实现和独立数据库一样简单，但备份恢复稍显复杂；这个模型中，平台应用层和数据库是共享的，即多个或所有租户共享Database，但一个Tenant一个Schema。将每个租户关联到同一个数据库的不同 Schema，租户间数据彼此逻辑不可见，上层应用程序的实现和独立数据库一样简单，但备份恢复稍显复杂；优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。数据库成本、运维成本相对较低；缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；如果需要跨租户统计数据，存在一定困难。

租户数据存储策略

平台客户Tenant2

平台Tenant2 data

分销商

一个客户一个租户

平台客户Tenant3

大型、集团型企业或业务存在多业务单元大体量业务或者地区有GDPR要求

分销客户集团主租户

模式3：共享数据库，共享数据表所有的租户都用同一个数据库，共同用相同的表，使用不同的租户id来标识优点： 维护和购置成本最低，允许每个数据库支持的租户数量最多缺点： 隔离级别最低，安全性最低，数据备份和数据恢复最困难，需要逐表来备份和还原，以牺牲隔离级别换取降低成本

租户部署策略