多租户saas云平台框架

 

今天谈下云平台下的多租户架构，不论是在公有云还是私有云平台，是设计一个面向最终组织或用户的 SaaS 应用还是面向业务系统的 PaaS 平台，多租户都是前期架构设计的一个关键内容，因此有必要对里面的一些核心要点进一步说明。

多租户架构概述

首先还是看下百度百科对多租户的一些关键说明如下：

 多租户技术（英语：multi-tenancy technology）或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。多租户简单来说是指一个单独的实例可以为多个组织服务。多租户技术为共用的数据中心内如何以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。一个支持多租户技术的系统需要在设计上对它的数据和配置进行虚拟分区，从而使系统的每个租户或称组织都能够使用一个单独的系统实例，并且每个租户都可以根据自己的需求对租用的系统实例进行个性化配置。

多租户技术可以实现多个租户之间共享系统实例，同时又可以实现租户的系统实例的个性化定制。通过使用多租户技术可以保证系统共性的部分被共享，个性的部分被单独隔离。通过在多个租户之间的资源复用，运营管理维护资源，有效节省开发应用的成本。而且，在租户之间共享应用程序的单个实例，可以实现当应用程序升级时，所有租户都可以同时升级。同时，因为多个租户共享一份系统的核心代码，因此当系统升级时，只需要升级相同的核心代码即可。

这段描述可能理解起来比较啰嗦，我们还是从简单的场景来进行说明。

比如我们开发一个 SaaS 云服务的 CRM 系统。这个系统部署在公有云端可以开放给多个企业客户使用。那么我们就遇到了一个关键问题。即是否当新入驻一个新的企业客户的时候，我们都需要重新在部署一套应用给这个客户使用？

如果是这样，那么当新客户入驻的时候，将带来具体的人工投入和资源投入成本。

因此实际的情况是我们希望新增加客户的时候，仍然还是已有的那套应用系统。但是对于最终的入驻客户来说，我们又希望客户完全感知不到这点，就像是单独给他们部署了一套系统一样。虽然很多客户使用同一套应用，但是能够很好地做到资源和数据的隔离。

而这正好就是多租户架构的一个关键点。

多租户，多组织，用户区别

接着谈下一些常见概念的关键区别。

 

多租户和多组织

实际上在云计算和多租户这些概念出来前，就已经有多组织的概念。

比如常说的类似 Oracle ,SAP 等 ERP 系统都是支持多组织架构。多组织架构简单来说就是对于一个大的集团性质企业，企业本身涉及到子公司或分公司，子公司可能涉及到独立法人也可能涉及到需要独立输出财务报表，或者相关公司还在海外涉及到不同的财务和会计准则。

基于以上各种场景持续了多组织架构。

一个多组织架构支撑集团所有的企业都上同一套 ERP 系统，里面通过法人，财务账簿，OU 等设置进行了多组织的支撑。而不是单独为一个子公司再去部署一套独立的应用系统。

从这个概念来看多组织和多租户相当类似。

那么两者的关键区别点在哪里？

简单总结来说多组织架构重点考虑的是数据层面的隔离，但是对于多租户架构更多的还需要考虑资源层面的隔离。多组织架构一般不会考虑类似云平台中的计费和计量管理，数据隔离更多是为了后续财务和数据安全管控要求，而多租户架构则需要考虑计费和计量管理。多组织架构下一般资源全共享，而多租户架构下资源是否共享和资源安全管控要求相关。

租户和用户

租户和用户实际是不同的两个概念，租户更多的是为了资源管理和计费计量使用，而用户更多的是为了业务功能和授权使用。

租户和用户有时候也是一一对应的关系，比如你开发一个面向个人用户的在线邮箱 SaaS 应用，那么这个时候租户和用户本身是对应的，租户即用户。

但是如果你开发的是一个面向企业的 SaaS 应用系统，那么这个时候租户对应的是组织这个层面，即入驻的企业是租户，对应企业入驻后，SaaS 应用会先给企业分配一个管理员账号，这个时候管理员再去详细的录入企业里面的具体用户账号。

也就是说租户是第一层，而下面的组织架构和用户是第二层。

SaaS 应用和 PaaS 平台的多租户

注意对于 SaaS 应用和 PaaS 平台本身都有多租户的概念。

对于 SaaS 应用来说，比如一个 toB 的 SaaS 应用服务。最终面对的是企业和最终用户，因此每一个入驻的企业组织就是租户。

而对于 PaaS 平台来说，比如我们在企业内部建设一个公共流程平台，这个流程平台即企业私有云内部的 PaaS 平台一部分，那么这个平台本身也需要进行多租户设计，而这个平台的租户实际是各个需要使用流程引擎能力的业务系统。对于类似容器云 PaaS 平台，消息，缓存各种 PaaS 技术服务，都可以看到实际上各个业务系统就是最终的租户。

还是拿上面的例子来说。

如果企业内部的公共流程平台提供给多个业务系统开发商使用，类似用友在该企业本身开发了 CRM 和 SRM 两个业务系统。

那么实际管理方式可以是 CRM 和 SRM 单独进行租户申请和注册。也可以是两层结构，即还是先进行组织申请，组织作为第一层租户。但是组织接入后还需要维护需要接入的业务系统，业务系统作为第二层租户。第一层的组织实际只是一个抽象的租户集的概念。

而实际的资源管理，计量计费等可以细粒度地管理到业务系统这个层级。

多租户架构设计和资源隔离

在多租户和云结合的情况下，IaaS 基础资源层的共享已经会变化为最基本的要求。那么在 Iaas 层之上来谈主要则包括两个方面的内容，即应用是一套还是多套？数据库是一套还是多套？最彻底的多租户即上图中的第 6 种 share everything 的模式，在这种模式下数据库和应用都为一套。

多租户我们首先考虑隔离，在多租户下的隔离包括了几个方面的内容。

一个是系统本身元数据和基础主数据的隔离（用户，角色，权限，数据字典，流程模板），一个是系统运行过程中产生的动态数据的隔离，一个是业务系统底层所涉及到的计算资源和存储资源的隔离。

在应用一套，数据库多套或多 schema 分离情况，我们比较容易实现计算资源和存储资源的单独分配，但是在完全 share everthing 的情况下，对于计算和存储资源的隔离则需要我们的 PaaS 应用本身去考虑。

在当前云原生和容器下，整个动态部署和持续交付都更加容易，那么为了更好地进行资源隔离，我们完全可以为单独的大租户动态的扩展一套独立的容器集群为该租户服务，即实现该租户能够单独使用一组容器资源池而非共享。

在私有云下的多租户，往往隔离又不是绝对的，在能够完全隔离的情况下又需要支撑跨租户或组织的数据共享，可以看到如果存在这种需求，在 Share everthing 的情况下是比较容易满足的。

多租户除了隔离外，另外一个重点就是能够为各个租户按需要实时地提供各种计算资源和存储资源，而且有清楚定义的数据采集和计费模型。由于资源池是共享的，我们必须要能够准确地采集到各个租户对实际资源的使用情况，以方便进行多租户的计费。

共享资源时候的资源隔离

当在 IaaS 云平台的时候，一台物理机可以虚拟化为多台虚拟云主机提供给不同的租户使用，虚拟机可以做到在计算，网络，存储等方面的资源逻辑隔离。也就是说一个租户本身导致的虚拟机使用异常或性能问题，并不会影响到其它租户使用的虚拟机。

到了 SaaS 层多租户，实际上仍然需要考虑租户下面的资源管理，特别是在多个租户共享一套底层资源的情况下。

比如当前有 A，B，C，D 四个租户在使用 SaaS 版本的 CRM 系统，那么我们就需要考虑是不是会出现由于 A 租户出现的大并发和大数据量访问而导致了剩余的三个租户无法正常使用系统。要做到这点，我们就必须做到面向租户的服务容量控制，服务限流等能力。

多租户下的资源计费

如果是一个 IaaS 平台的多租户，可以看到对于弹性计算和弹性存储资源都是单独申请的，资源本身也是逻辑隔离，这个时候计费相对简单。

但是对于 SaaS 应用来说，要做到按资源使用情况计费就比较复杂。因此一般的 SaaS 应用会简单地根据用户注册数，并发数或存储容量分配来进行组合计费。当然如果是非共享资源模式的多租户架构，相当来说就更加容易按资源使用来进行计费。

多租户下的分域和分组

即使是资源完全共享下的多租户架构，仍然不建议采用一个大集群来为所有租户提供服务，而是应该对大集群进行分域或分组，或者多大的集群资源进行分区或分片处理。让不同的租户分配到不同的集群组或分片上面。

这样做的好处可以避免单个大集群无限扩展导致的性能问题和管理难度，同时也提升了整个应用对外的容错能力，比如 A 集群全部故障，还可以快速的将 A 集群流量切换到 B 集群。

多租户下的数据库扩展

在公有云下的多租户，如果采用完全共享的模式，还必须考虑数据库的可扩展性，多租户架构服务下的数据库可以是独立数据库，共享数据库但是 Schema 独立，完全共享数据库几种模式。

独立数据库模式为每个租户分配一个独立的数据库，其在 SID 层就是完全独立的。而对于共享数据库但是 Schema 独立这种模式下，SID 只有一个，但是当入驻新的租户的时候会单独新生成一个独立的 Schema。

最后一种模式就是完全共享数据库，SID 和 Schema 都只有一套，在这种模式下核心是所有数据库表都需要增加租户 ID 字段对数据进行多租户隔离，以保障某一个租户登录系统只能够看到自己租户下的相关信息。如果是一个完整的多租户应用，还需要考虑第二层按用户，组织，角色群组等进行第二级的数据隔离，以满足业务系统的使用需求。

可以看到独立数据库模式资源利用率低，但是数据隔离性最好；而完全共享模式下资源利用率高，但是数据隔离性最弱。因此具体采用哪种模式仍然需要根据实际租户的需求来进行灵活创建和配置，一个灵活的 SaaS 应用实际需要同时灵活支撑上面三种模式。最后给大家推荐一个早些年全开源的 saas 新零售系统：weiit-saas是一款Java开源项目，属于weiit团队自研产品，意在通过技术封装，让企业无需代码开发，帮助企业一键生成小程序、公众号，让企业拥有独立品牌的自营商城。对 saas 感兴趣的小伙伴可以去研究学习一下。
————————————————
版权声明：本文为CSDN博主「年少有为2025」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_41156974/article/details/125301739

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

在当下云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，而且仍能够保障客户的数据隔离。目前各类各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。阿里云

　　多租户在数据存储上存在三种主要的方案，分别是：

　　1. 独立数据库

　　这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本较高。 
　　优势： 
　　　　为不一样的租户提供独立的数据库，有助于简化数据模型的扩展设计，知足不一样租户的独特需求；若是出现故障，恢复数据比较简单。 
　　缺点： 
　　　　增多了数据库的安装数量，随之带来维护成本和购置成本的增长。 
　　这种方案与传统的一个客户、一套数据、一套部署相似，差异只在于软件统一部署在运营商那里。若是面对的是银行、医院等须要很是高数据隔离级别的租户，能够选择这种模式，提升租用的订价。若是订价较低，产品走低价路线，这种方案通常对运营商来讲是没法承受的。

　　2. 共享数据库，独立 Schema 

　　这是第二种方案，即多个或全部租户共享Database，可是每一个租户一个Schema（也可叫作一个user）。底层库好比是：DB二、ORACLE等，一个数据库下能够有多个SCHEMA
　　优势： 
　　　　为安全性要求较高的租户提供了必定程度的逻辑数据隔离，并非彻底隔离；每一个数据库可支持更多的租户数量。
　　缺点： 
　　　　若是出现故障，数据恢复比较困难，由于恢复数据库将牵涉到其余租户的数据； 
　　若是须要跨租户统计数据，存在必定困难。

　　3. 共享数据库，共享 Schema，共享数据表

　　这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中增长TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的模式。
　　即每插入一条数据时都须要有一个客户的标识。这样才能在同一张表中区分出不一样客户的数据。
　　优势： 
　　　　三种方案比较，第三种方案的维护和购置成本最低，容许每一个数据库支持的租户数量最多。 
　　缺点： 
　　　　隔离级别最低，安全性最低，须要在设计开发时加大对安全的开发量； 数据备份和恢复最困难，须要逐表逐条备份和还原。

　　若是但愿以最少的服务器为最多的租户提供服务，而且租户接受牺牲隔离级别换取下降成本，这种方案最适合。 
　　　　
　　在SaaS实施过程当中，有一个显著的考量点，就是如何对应用数据进行设计，以支持多租户，而这种设计的思路，是要在数据的共享、安全隔离和性能间取得平衡。

　　由于咱们用的底层库是MySQL，且要保证数据的彻底隔离，因此用的方案属于第一种。独立数据库。由于MySQL下SCHEMA就是他的数据库名。因此每多服务一个用户，都须要新建一个数据库。若是是DB2或者是ORACLE的话，一个数据库下，能够采用独立的SCHEMA来进行数据隔离，这样会相对节省成本，且数据隔离的强度高。

3、选择合理的实现模式 
　　衡量三种模式主要考虑的因素是隔离仍是共享。

　　成本角度因素 

　　　　隔离性越好，设计和实现的难度和成本越高，初始成本越高。共享性越好，同一运营成本下支持的用户越多，运营成本越低。

　　安全因素 

　　　　要考虑业务和客户的安全方面的要求。安全性要求越高，越要倾向于隔离。

　　从租户数量上考虑
　　　　主要考虑下面一些因素 
　　　　系统要支持多少租户？上百？上千仍是上万？可能的租户越多，越倾向于共享。 
　　　　平均每一个租户要存储数据须要的空间大小。存贮的数据越多，越倾向于隔离。 
　　　　每一个租户的同时访问系统的最终用户数量。须要支持的越多，越倾向于隔离。 
　　　　是否想针对每一租户提供附加的服务，例如数据的备份和恢复等。这方面的需求越多， 越倾向于隔离

　　技术储备 
　　　　共享性越高，对技术的要求越高。

　　以上三部份内容分别针对开头的三个问题作了概要的阐述，文章中部份内容也是摘录自查阅的资料，实乃他人总结的很是好，因此就直接把轮子拿过来用了，旨在让你我更加了解多租户这种架构，还望勿喷！