【多租户】初识多租户

前言

什么是多租户呢,你了解多租户吗,多租户是什么呢

叙述

多租户的历史:

多租户技术源于1960年代,许多公司为了要使用更多的运算资源,向持有大型主机(Mainframe)的供应商租用一部分的运算资源,而这些用户经常会用到相同的应用程序,当时会以用户在登录系统时输入的数据来决定用户的帐户ID,基于这个ID,Mainframe的供应商即可利用此ID来计算运算的资源使用量,包含CPU,存储器与软盘或磁带等,这个作法也被SAP公司用在其R/1到R/3的产品线。

到了1990年代,应用程序服务提供者服务(application service provider)模式出现,它的作法与运作模式与租用大型主机时相同,不过租用的资源是在软件上,除了操作系统以外也包含了其上的应用程序,例如ERP系统或是CRM等应用,系统可能会运行在数台不同的机器上,或是在相同的主机但共享不同的数据库,以区分并计算客户的资源使用量,藉以作为计费的标准,而此技术也有效的缩减供应商的实体机器成本(因为可以在一台电脑上同时运行多个用户所租用的应用程序进程)。到了现代,受欢迎的消费者导向Web应用程序(如Hotmail或Gmail等)也是以单一应用程序平台来支持所有的用户,这已经是多租户技术的自然演化的结果,多租户技术也可以让客户中的一部份用户得以进一步定制化他们的应用程序。

在虚拟化(virtualization)技术的成熟与应用性的扩张之下,多租户技术可以驾驭虚拟化的平台,更强化在用户应用程序与数据之间的隔离,让多租户技术能更加发挥它的特色。

什么是多租户

** 内涵:
定义:**
多租户技术(英语:multi-tenancy technology)或称多重租赁技术,是一种软件架构技术,它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件,并且仍可确保各用户间数据的隔离性。
本质上讲:软件架构技术
通俗上讲:
在多租户技术中,租户(tenant)是指使用系统或电脑运算资源的客户,但在多租户技术中,租户包含在系统中可识别为指定用户的一切数据,举凡帐户与统计信息(accounting data),用户在系统中建置的各式数据,以及用户本身的客制化应用程序环境等,都属于租户的范围,而租户所使用的则是基于供应商所开发或建置的应用系统或运算资源等,供应商所设计的应用系统会容纳数个以上的用户在同一个环境下使用,为了要让多个用户的环境能力同一个应用程序与运算环境上使用,则应用程序与运算环境必须要特别设计,除了可以让系统平台可以允许同时让多份相同的应用程序运行外,保护租户数据的隐私与安全也是多租户技术的关键之一。
** 外延:**
技术上,多租户技术可以通过许多不同的方式来切割用户的应用程序环境或数据。
数据面(data approach):供应商可以利用切割数据库(database),切割存储区(storage),切割结构描述(schema)或是表格(table)来隔离租户的数据,必要时会需要进行对称或非对称加密以保护敏感数据,但不同的隔离作法有不同的实现复杂度与风险。
程序面(application approach):供应商可以利用应用程序挂载(hosting)环境,于进程(process)上切割不同租户的应用程序运行环境,在无法跨越进程通信的情况下,保护各租户的应用程序运行环境,但供应商的运算环境要够强。
系统面(system approach):供应商可以利用虚拟化技术,将实体运算单元切割成不同的虚拟机,各租户可以使用其中一至数台的虚拟机来作为应用程序与数据的保存环境,但对供应商的运算能力要更要求。

为什么要用多租户

使用多租户带来什么好处,意义是什么
第一,系统维护成本低
多租户系统在系统升级时,只需要更新一次。
维护人员不需要对每个用户更新,节省了很大的运维成本!
经济:因为通过一个软件实例被多个组织共享,从而减低了整体资源的消耗,也同时减低应用运行的成本和相应的管理开支。
第二,提高了数据安全性
在云计算环境下,很多应用都放到了云端,导致在应用入口,敏感数据泄露、数据访问无详细记录、应用冒名访问开放接口;
在运维入口,开发人员账号混用、操作无详细记录、高危险误操作无法控制、敏感数据泄露
通过多租户数据资源隔离机制,就可以保证数据的安全性。
三、管理方便:
首先,通过使用了多租户架构能减少物理资源和软件资源,这将简化管理,其次。由于多租户软件主要由有经验的云供应商运营,所以能依赖那些非常经验的管理人员来提升效率。
怎么实现多租户
实现的原理是什么
由于多租户技术可以让多个租户共用一个应用程序或运算环境,且租户大多不会使用太多运算资源的情况下,对供应商来说多租户技术可以有效的降低环境建置的成本。包含硬件本身的成本,操作系统与相关软件的授权成本都可以因为多租户技术,而由多个租户一起分担。
通过不同的数据管理手段,多租户技术的数据可以用不同的方式进行数据隔离,在供应商的架构设计下,数据的隔离方式也会不同,而良好的数据隔离法可以降低供应商的维护成本(包含设备与人力),而供应商可以在合理的授权范围内取用这些数据分析,以作为改善服务的依据。
多租户架构下所有用户都共用相同的软件环境,因此在软件改版时可以只发布一次,就能在所有租户的环境上生效。
具多租户架构的应用软件虽可客制,但客制难度较高,通常需要平台层的支持与工具的支持,才可降低客制化的复杂度。
** 多租户实现的过程中涉及到的技术是什么**
多租户技术的实现重点,在于不同租户间应用程序环境的隔离(application context isolation)以及数据的隔离(data isolation),以维持不同租户间应用程序不会相互干扰,同时数据的保密性也够强。
应用程序部份:通过进程或是支持多应用程序同时运行的装载环境(例如Web Server,像是Apache或IIS等)来做进程间的隔离,或是在同一个伺服程序(server)进程内以运行绪的方式隔离。
数据部份:通过不同的机制将不同租户的数据隔离,Force是采用中介数据(metadata)的技术来切割,微软 MSDN 的技术文件则是展示了使用结构描述的方式隔离。
多租户就是说多个租户共用一个实例,租户的数据既有隔离又有共享,从而解决数据存储的问题。从架构层面来分析,SaaS区别于传统技术的重要差别就是Multi-Tenant模式。
SaaS多租户在数据存储上存在三种主要的方案,分别是
1.独立数据库
这是第一种方案,即一个租户一个数据库,这种方案的用户数据隔离级别最高,安全性最好,但成本也高。独立数据库是一个租户独享一个数据库实例,它提供了最强的分离度,租户的数据彼此物理不可见,备份与恢复都很灵活
优点:
为不同的租户提供独立的数据库,有助于简化数据模型的扩展设计,满足不同租户的独特需求;
如果出现故障,恢复数据比较简单。
缺点:
增大了数据库的安装数量,随之带来维护成本和购置成本的增加。
这种方案与传统的一个客户、一套数据、一套部署类似,差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户,可以选择这种模式,提高租用的定价。如果定价较低,产品走低价路线,这种方案一般对运营商来说是无法承受的。
2.共享数据库,独立Schema
这是第二种方案,即多个或所有租户共享Database,但一个Tenant一个Schema。将每个租户关联到同一个数据库的不同 Schema,租户间数据彼此逻辑不可见,上层应用程序的实现和独立数据库一样简单,但备份恢复稍显复杂;
优点:
为安全性要求较高的租户提供了一定程度的逻辑数据隔离,并不是完全隔离;每个数据库可以支持更多的租户数量。
缺点:
  如果出现故障,数据恢复比较困难,因为恢复数据库将牵扯到其他租户的数据;
  如果需要跨租户统计数据,存在一定困难。
3.共享数据库、共享 Schema、共享数据表
这是第三种方案,即租户共享同一个Database、同一个Schema,但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。租户间数据彼此逻辑不可见,上层应用程序的实现和独立数据库一样简单,但备份恢复稍显复杂; 最后一种模式则是租户数据在数据表级别实现共享,它提供了最低的成本,但引入了额外的编程复杂性(程序的数据访问需要用 tenantId 来区分不同租户),备份与恢复也更复杂。
优点:
三种方案比较,第三种方案的维护和购置成本最低,允许每个数据库支持的租户数量最多。
缺点:
隔离级别最低,安全性最低,需要在设计开发时加大对安全的开发量;
  数据备份和恢复最困难,需要逐表逐条备份和还原。

如果希望以最少的服务器为最多的租户提供服务,并且租户接受以牺牲隔离级别换取降低成本,这种方案最适合。

image

** 应用场景**
小飞,小象,小君三人大学毕业后同租了一套三室两厅的房子,三人各占一间独立卧室,每间房各配一把钥匙,从而保证每个人都有自己的独立私密空间,如果别人要进入,必须通过权限验证(也就是配套的开门钥匙)才行,但厨房、餐厅、客厅这些资源是共用的(ps:为啥没提厕所?因为每间卧室都带厕所,这三人租的房有点豪!)
这里的小飞,小象,小君就是多租户,别的租户要访问必须通过权限验证的独立卧室就是数据隔离共用的资源(厨房、餐厅、客厅)就是多租户环境下的系统和应用程序、组件
** 基本步骤demo**
数据层的多租户浅谈
** Spring boot + Hibernate 多租户的使用
eclipselink+jboss实现多租户基本配置**
具体的实现方式
如何选型
一般情况下,租户模型不会影响应用程序的功能,但可能会影响总体解决方案的其他方面。 以下条件用于评估每个模型:
可伸缩性:
租户数目。
每个租户的存储量。
总存储量。
工作负荷。

租户隔离:

    数据隔离和性能(一个租户的工作负荷是否影响其他租户)。

每个租户的成本:

   数据库成本。

开发复杂性:
架构更改。
查询更改(模式所需)。
操作复杂性:
监视和管理性能。
架构管理。
还原租户。
灾难恢复。

可自定义性:

   易于支持租户特定或租户类特定的架构自定义。

  有关租户的讨论侧重于数据层。 但是,请花费片刻时间思考一下应用程序层。 应用程序层被视为单一实体。 如果将应用程序划分成多个小型组件,所选的租户模型可能会更改。 在所用的租户和存储技术或平台方面,可以不同的方式对待某些组件。

实现多租户的方式:
JPA Provider
JSR 338 定义了 JPA 规范 2.1,但如我们已经了解到的,Oracle 把多租户的多数特性推迟到了 Java EE 8 中。尽管这些曾经在 JavaOne 大会中有过演示,但无论是在 JPA 2.0(JSR 317)还是 2.1 规范中,都依然没有明文提及多租户。不过这并不妨碍一些 JPA provider 在这部分领域的实现,Hibernate 和 EclipseLink 已提供了全部或部分的多租户数据层的解决方案。
Hibernate 是当今最为流行的开源的对象关系映射(ORM)实现,并能很好地和 Spring 等框架集成,目前 Hibernate 支持多租户的独立数据库和独立 Schema 模式。EclipseLink 也是企业级数据持久层JPA标准的参考实现,对最新 JPA2.1 完整支持,在目前 JPA 标准尚未引入多租户概念之际,已对多租户支持完好,其前身是诞生已久、功能丰富的对象关系映射工具 Oracle TopLink。因此本文采用 Hibernate 和 EclipseLink 对多租户数据层进行分析。
Hibernate
Hibernate 是一个开放源代码的对象/关系映射框架和查询服务。它对 JDBC 进行了轻量级的对象封装,负责从 Java 类映射到数据库表,并从 Java 数据类型映射到 SQL 数据类型。在 4.0 版本 Hibenate 开始支持多租户架构——对不同租户使用独立数据库或独立 Sechma,并计划在 5.0 中支持共享数据表模式。
EclipseLink
EclipseLink 是 Eclipse 基金会管理下的开源持久层服务项目,为 Java 开发人员与各种数据服务(比如:数据库、web services、对象XML映射(OXM)、企业信息系统(EIS)等)交互提供了一个可扩展框架。
在完整实现 JPA 标准之外,针对 SaaS 环境,在多租户的隔离方面 EclipseLink 提供了很好的支持以及灵活地解决方案。
如何判定能否支持多租户   
我们通常所说的应用程序对多租户的支持程度,其判定依据是基于多少核心应用层(或者SaaS)是可以让各个“租户”共享的。完全支持多租户模式指的是允许多个“租户”共享数据库的表空间、支持对业务逻辑、工作流和用户界面的定制。换句话说,所有SaaS的子层都提供对“多租户”的支撑能力;而最低程度的支持“多租户”也至少意味IaaS和PaaS层可以共享,只是每个“租户”有自己专有的SaaS层;中等程度地支持“多租户”,则是具有同样特征的一组“租户”共享数据库的表空间(schemae)及其他应用层,而不同组的“租户”有其自己的数据库和应用程序。

避坑指南

多租户的缺点:
多租户架构的一个缺点就是,某一客户的问题会影响整个系统。 另外,如果集中式运作出问题,所有客户都会受到影响。没有哪家软件即服务(SaaS)提供商是完美无缺的。它们都遇到过严重的服务停用事件。不过与大多数内部数据中心的糟糕记录相比,它们的情况似乎都相当好。
隔离:因为承租者共享软件和硬件的同一实例,所以一个承租者可能会影响其他承租者的软件的可用性和性能。例如,如果共享的软件没有充足的安全保障措施,则可能会发生因一个承租者关闭共享软件而导致对共享该实例的所有承租者拒绝服务。
安全性:如果共享软件没有充分的安全保障措施,则一个承租者的用户可能会访问属于另一个承租者的数据。
自定义能力:因为软件是在承租者之间共享的,所以各个承租者不可能自定义该软件。例如,在没有充足的扩展点的情况下,一个承租者不可能为业务流程提供自己的实现。
应用程序升级将为承租者带来问题:同时升级共享的软件可能并不是所有承租者都希望的。
恢复:在承租者之间共享数据库使得很难为每个承租者单独备份和恢复数据。
面临的挑战
跟我上“云”端(一)认识多租户

扩展问题

** .net平台下多租户是怎么做的
多租户技术可被其他技术替代吗?
多租户架构之外的技术?**
多租户架构之外的选择是单租户架构; 在这种模式中,每个客户都运行自己的软件实例,软件可通过元数据或其他方式来配置。SAP公司为其Business by Design软件采用了单租户模式,该软件实施了众多商业应用程序。
两者之间的区别
多租户模式与单租户架构模式存在大片的潜在灰色区,往往被人们所忽视。单租户应用程序可由云环境中的虚拟化服务器或数据中心内的服务器来提供,单租户应用程序的各部分可以共享或不共享。比方说,应用程序采用单租户模式、而数据库进行共享这种现象并不罕见

小结

对于多租户先有一个基本的认识,接下来就是用到项目中啦,实践很重要

https://blog.csdn.net/zmh458/article/details/79690318

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

推荐阅读更多精彩内容