多租户的多种实现方案

To 个人主页 关注不迷路

应对不同复杂程度的 Web 业务，如何实现多租户，使得不同组织之间的数据完全隔离。即，不同组织的人员仅能读写自身组织的数据。大致有以下两种方案：

• 部署类
• 数据隔离类

一、业务场景

简单的 Web 业务，可能一个 WAR 包 + Tomcat + 数据库，即可部署完成。

稍微复杂点的，可能会在此基础上引入 Nginx、多个数据库（比如 Postgre、MongoDB、ES 等）、队列等。

更复杂些的，可能会支持分布式部署。即数据库服务、队列服务等各自占用一个服务器。

面对不同的需求，大致将多租户方案分为两类：

• 部署类
  • 虚拟机方案
• 数据隔离类。
  • 隔离数据库
  • 数据添加组织 ID

二、虚拟机方案

这种方案指，为每个组织独立部署一套完整的服务。同时存在一个中控系统，可以控制虚拟机的创建、删除工作。设计方案：

这种方式下，数据天生是隔离的，无需任何额外处理。

2.1 中控系统

2.1.1 它的职能包括：

• 创建组织，记录一个组织的信息。
  • 创建组织的同时，需要为组织开辟服务器资源，全新部署一次完整的服务。
• 更新组织
• 删除组织
  • 删除组织的同时，需要删除组织占用的服务器资源。

2.1.2 虚拟机的管理方式

当新建组织时，需要为组织开辟服务器资源。
以vSphere为例，可以通过调用vSphere接口实现对虚拟机的管理，对资源执行创建、删除。

2.2 业务系统

通常一个完整的 Web 服务，至少包含用户管理系统和信息管理系统。

在这种模式下，每个组织都有自己的用户管理系统和信息管理系统。

2.3 升级问题

当发布新的正式版本、或者补丁版本时，可以对指定组织、或全部组织执行更新操作，操作上更加的自由化。

三、隔离数据库

既然目的是为了实现，不同组织之间的数据隔离问题。那么采用隔离数据库方案，不同的组织拥有自己的数据库，可能的设计方案：

设计思路：各种服务维持一个运行实例，通过索引、连接等方式实现对不同数据的读取与写入。

3.1 业务系统

各组织共用一个用户管理系统和信息管理信息，同时后台的服务也是单实例的运行时进程。

3.2 数据读写

每个组织组织拥有自己的数据存储库，用于存储组织自身产生的数据。同时也可以有一个共享库，用于存储各组织共享的数据，比如初始化配置数据。

数据库的实现方式，分多种场景，以数据库为例：

针对不同的部署方式，访问不同组织的数据时，需要实现不同的连接切换方式。

同理，kafka、es 等服务也需要做同样处理，实现不同组织的数据访问。

3.3 升级问题

这种方案下，需要考虑程序升级与数据升级问题

程序升级：
因为所有组织共用的一份代码，仅需要执行一次程序升级。

数据升级：
若使用了共享配置数据库，则大部分场景下仅需要升级这个公共库即可，少部分情况需要升级每个组织的数据。

若未使用共享配置数据库，则需要对每个组织都执行一次数据升级。

四、数据添加组织 ID

思路：所有的组织共用一份运行实例（业务服务实例、数据库库实例等），每一条数据都添加一个org_id，用于实现不同组织之间的数据隔离。

4.1 数据读写

根据当前访问用户的组织 ID，访问对应的组织的数据。

4.2 升级问题

发布新版本后，正常的业务升级即可。

五、方案对比

方案	优点	缺点
虚拟机方案	天生实现数据隔离，不需要额外的处理；	服务器资源开销大；升级麻烦；
隔离数据库	数通过修改连接方式的切换，实现数据隔离，比较方便；	需要开辟新的数据库，用户少时，不划算；升级时可能会稍微繁琐；
数据添加组织 ID	升级方案简单，几乎不要考虑组织的问题	业务系统的 API 需要根据组织 ID 的不同，操作不同组织的数据