团队开发框架实战—多租户架构

1 对多租户的理解

多租户定义:多租户技术或称多重租赁技术,简称SaaS,是一种软件架构技术,是实现如何在多用户环境下(此处的多用户一般是面向企业用户)共用相同的系统或程序组件,并且可确保各用户间数据的隔离性。简单讲:在一台服务器上运行单个应用实例,它为多个租户(客户)提供服务。从定义中我们可以理解:多租户是一种架构,目的是为了让多用户环境下使用同一套程序,且保证用户间数据隔离。那么重点就很浅显易懂了,多租户的重点就是同一套程序下实现多用户数据的隔离。对于实现方式,我们下面会讨论到。
在了解详细一点:在一个多租户的结构下,应用都是运行在同样的或者是一组服务器下,这种结构被称为“单实例”架构(Single Instance),单实例多租户。多个租户的数据是保存在相同位置,依靠对数据库分区来实现隔离操作。既然用户都在运行相同的应用实例,服务运行在服务供应商的服务器上,用户无法去进行定制化的操作,所以这对于对该产品有特殊需要定制化的客户就无法适用,所以多租户适合通用类需求的客户。那么缺点来了,多租户下无法实现用户的定制化操作。
在翻阅多租户的资料时,还有一个名词与之相对应,那就是单租户SaaS架构(也被称作多实例架构(Multiple Instance))。单租户架构与多租户的区别在于,单租户是为每个客户单独创建各自的软件应用和支撑环境。单租户SaaS被广泛引用在客户需要支持定制化的应用场合,而这种定制或者是因为地域,抑或是他们需要更高的安全控制。通过单租户的模式,每个客户都有一份分别放在独立的服务器上的数据库和操作系统,或者使用强的安全措施进行隔离的虚拟网络环境中。因为本篇主要是讨论多租户,所以单租户的相关知识就简单了解一下,不做过多的阐述了。

2 多租户数据隔离的三种方案

在当下云计算时代,多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务,并且仍可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴,例如阿里云数据库服务(RDS)、阿里云服务器等等。
多租户在数据存储上存在三种主要的方案,分别是:

2.1 独立数据库

这是第一种方案,即一个租户一个数据库,这种方案的用户数据隔离级别最高,安全性最好,但成本较高

  • 优点:为不同的租户提供独立的数据库,有助于简化数据模型的扩展设计,满足不同租户的独特需求;如果出现故障,恢复数据比较简单。
  • 缺点: 增多了数据库的安装数量,随之带来维护成本和购置成本的增加。

这种方案与传统的一个客户、一套数据、一套部署类似,差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户,可以选择这种模式,提高租用的定价。如果定价较低,产品走低价路线,这种方案一般对运营商来说是无法承受的。

2.2 共享数据库,独立 Schema

这是第二种方案,即多个或所有租户共享Database,但是每个租户一个Schema(也可叫做一个user)。底层库比如是:DB2、ORACLE等,一个数据库下可以有多个SCHEMA

  • 优点: 为安全性要求较高的租户提供了一定程度的逻辑数据隔离,并不是完全隔离;每个数据库可支持更多的租户数量。
  • 缺点: 如果出现故障,数据恢复比较困难,因为恢复数据库将牵涉到其他租户的数据; 如果需要跨租户统计数据,存在一定困难。

2.3 共享数据库,共享 Schema,共享数据表

这是第三种方案,即租户共享同一个Database、同一个Schema,但在表中增加TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的模式
即每插入一条数据时都需要有一个客户的标识。这样才能在同一张表中区分出不同客户的数据。

  • 优点:三种方案比较,第三种方案的维护和购置成本最低,允许每个数据库支持的租户数量最多
  • 缺点: 隔离级别最低,安全性最低,需要在设计开发时加大对安全的开发量; 数据备份和恢复最困难,需要逐表逐条备份和还原。如果希望以最少的服务器为最多的租户提供服务,并且租户接受牺牲隔离级别换取降低成本,这种方案最适合
        
    在SaaS实施过程中,有一个显著的考量点,就是如何对应用数据进行设计,以支持多租户,而这种设计的思路,是要在数据的共享、安全隔离和性能间取得平衡。

3 选择合理的实现模式

衡量三种模式主要考虑的因素是隔离还是共享。

  • 成本角度因素
    隔离性越好,设计和实现的难度和成本越高,初始成本越高。共享性越好,同一运营成本下支持的用户越多,运营成本越低。
  • 安全因素
    要考虑业务和客户的安全方面的要求。安全性要求越高,越要倾向于隔离。
  • 从租户数量上考虑
    主要考虑下面一些因素。
    系统要支持多少租户?上百?上千还是上万?可能的租户越多,越倾向于共享。
    平均每个租户要存储数据需要的空间大小。存贮的数据越多,越倾向于隔离。
    每个租户的同时访问系统的最终用户数量。需要支持的越多,越倾向于隔离。
    是否想针对每一租户提供附加的服务,例如数据的备份和恢复等。这方面的需求越多, 越倾向于隔离。
  • 技术储备
    共享性越高,对技术的要求越高。

4 团队开发框架实战—多租户支持

多租户技术的实现重点,在于不同租户间应用程序环境的隔离(application context isolation)以及数据的隔离(data isolation),以维持不同租户间应用程序不会相互干扰,同时数据的保密性也够强。
多租户数据库构架方式主要分为:独立数据库(私有表)、共享数据库隔离数据框架(扩展表)、共享数据库共享数据框架(通用表)
以上架构模式中,数据隔离程度相对较差,数据共享程度越高,越能够支持较多的租户,同时设备成本越低,但同时数据维护难度越大。如敏感数据较多,则选择共享数据库隔离数据框架,否则可选择共享数据库共享数据框架的方式进行数据存储构架。
本项目系统可能出现数量较多的租户,同时设备有限,所以选取共享数据库共享数据框架(通用表)的数据存储结构

多租户结构示意图.png

数据表结构采用名称值对的方式进行设计:将扩展数据的保存和原数据表分离,另外用一个统一的扩展数据表来保存。扩展数据表将数据表的横向扩展列转换为纵向的数据集,将每一条原始数据记录的一个扩展字段,都保存成一条扩展数据行。将数据表中的数据记录与配置元数据表中的配置记录关联,构成扩展数据记录。可以提供无限数量的自定义扩展字段。但是其增加数据操作的复杂性,查询时也要多次访问数据库才能得到完整的业务数据。

多租户表结构示意图.png

多通用表与键值对的数据存储架构存储工作过程,上层应用通过标准多租户数据定义、存储API 进行交互,通过标准的API 接口将多租户数据存储到数据空中;也可以通过查询的方式来从统一存储的数据库中还原租户的数据。

多通用表与键值对的数据存储工作过程.png

在图中,多租户数据管理系统主要进行的数据操作是开发视图下进行的,主要操作有对租户数据模型的定义和扩展、租户数据的持久化存储和查询读取。在对租户数据模型的定义和扩展过程中,需要将租户的信息提取出来单独存储;对租户所定义的数据表包含的数据表名称、数据表中列名称、列值的类型、列值的数据长度、数据表与其他表中的关系等元数据提取出来进行管理。租户数据的持久化存储和查询读取操作,先对租户的身份进行验证,防止租户对其他租户数据进行操作。通过物理SQL 语句生成模块将租户数据查询操作的逻辑SQL 与转化成能够直接在逻辑存储层执行的SQL 语句。

  • 租户数据模型定义部件描述了租户的定制信息。这种定制信息描述了租户定制的数据表的名称、数据类型、约束关系等。
  • 逻辑SQL,是由租户发起的数据查询查询请求。在数据管理分层模型中,开发视图下,屏蔽了租户无关的数据特性。租户可以通过相关的接口进行数据查询,因此逻辑SQL 与标准SQL 没有区别。
  • 物理SQL是用于实际查询数据的SQL语句,它工作在逻辑存储视图层。物理SQL 是将逻辑SQL 语句逻辑数据表结构转换成底层数据的物理数据表结构所形成的能够在底层数据库中执行的SQL 语句。
  • 查询重写器的功能是将逻辑SQL 语句进行重新构造将其转换为能够在通用表上执行的物理SQL 语句。查询重写器获取租户发出的查询请求,从数据库中获取租户信息,根据租户查询的数据表对应的元数据信息,将租户的查询请求,转换成为逻辑存储层面上,数据库系统能够执行的查询语句。
  • 租户管理模块的功能是将租户的信息、租户所拥有的数据表信息进行存储和查询,提供给数据管理系统中其他模块获取租户数据的能力。
  • 租户身份验证主要是针对某一租户的数据进行正确的存储,正确地映射到数据库系统中;当租户对数据进行查询时,能够根据租户信息正确地查找到租户所需的数据,并在查询过程中不对其他租户数据产生影响。

当租户进行数据模式定制时,租户数据模式定制器获取租户所需定制的数据模式,并定制请求中分析出租户对数据模型定制信息,并将这些信息写入到元数据表中元数据表和,完成租户数据模式的定制。当租户中用户发起数据查询请求时,查询重写部件查找用户数据库,获取该用户所对应的租户身份标识,根据查询请求中的数据表模式信息,从元数据表中查询出相应的元数据信息,将租户中用户发起的数据查询请求进行重写,重写过程如下,根据逻辑SQL 语句,从中提取出查询关键字,需要查询的逻辑数据表、数据列等信息,根据这些信息从元数据表中查找出相应的逻辑存储表信息,将实际存储的信息替换逻辑SQL 语句中的信息,完成重写。
通用表存储模式下,当租户发起业务数据模式新建时,逻辑数据管理提出租户信息,其中包含了租户新建的数据表的列数及各列的描述,根据新建的命令,生成逻辑SQL 语句,提交到SQL 重写器,SQL 重写从逻辑SQL 语句中抽取出元数据,数据表元数据,字段表元数据,关系表元数据,并根据SQL 重写算法,逐一生成物理SQL 语句,交予数据库执行,序列图如下所示。

新建业务数据模型序列图.png

当租户查询数据时,SQL 查询重写器捕捉到租户查询的逻辑SQL 语句,访问控制管理从逻辑SQL 语句中感知租户身份,并根据租户的权限,验证数据查询是否超出租户权限,若超出则返回,并给出超出权限提示。通过验证则,将逻辑查询请求发送给SQL 重写器,重写器从逻辑SQL 语句中抽取出查询字段,租户虚拟表,查询条件。根据租户虚拟表从元数据中查询出对应的元数据,查询重写器根据元数据,将逻辑SQL 语句转化为物理SQL 语句,并在数据库中查询执行。如图所示。

数据查询时序图.png
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容