精华内容
下载资源
问答
  • 把这几天写的文章做一个汇总,方便大家查找 saas系统多租户数据隔离的实现(一)...saas系统多租户数据隔离的实现(二)使用租户id字段区分租户数据 saas系统多租户数据隔离的实现(三)每个租户使用独立的表空间 ...
    展开全文
  • SaaS-多租户SaaS平台的数据库方案

    千次阅读 2019-12-27 15:29:30
    1 多租户SaaS平台的数据库方案 1.1 多租户是什么 多租户技术(Multi-TenancyTechnology) 又称多重租赁技术:是一种软件架构技术,是实现如何在用户环境下(此处的用户一般是面向企业用户)共用相同的系统或程序...

    第2章 数据库设计与前端框架

    1 多租户SaaS平台的数据库方案

    1.1 多租户是什么

    多租户技术(Multi-TenancyTechnology) 又称多重租赁技术:是一种软件架构技术,是实现如何在多用户环境下(此处的多用户一般是面向企业用户)共用相同的系统或程序组件,并且可确保各用户间数据的隔离性。简单讲:在一台服务器上运行单个应用实例,它为多个租户(客户)提供服务。从定义中我们可以理解:多租户是一种架构,目的是为了让多用户环境下使用同一套程序,且保证用户间数据隔离。那么重点就很浅显易懂了,多租户的重点就是同一套程序下实现多用户数据的隔离

    1.2 需求分析

    传统软件模式,指将软件产品进行买卖,是一种单纯的买卖关系,客户通过买断的方式获取软件的使用权,软件的源码属于客户所有,因此传统软件是部署到企业内部,不同的企业各自部署一套自己的软件系统

    Saas模式,指服务提供商提供的一种软件服务,应用统一部署到服务提供商的服务器上,客户可以根据自己的实际需求按需付费。用户购买基于WEB的软件,而不是将软件安装在自己的电脑上,用户也无需对软件进行定期的维护与管理

    在这里插入图片描述
    在SaaS平台里需要使用共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务,并且仍可以保障客户的数据正常使用。由此带来了新的挑战,就是如何对应用数据进行设计,以支持多租户,而这种设计的思路,是要在数据的共享、安全隔离和性能间取得平衡。

    1.3 多租户的数据库方案分析

    目前基于多租户的数据库设计方案通常有如下三种:

    1. 独立数据库
    2. 共享数据库、独立 Schema
    3. 共享数据库、共享数据表

    1.3.1 独立数据库

    独立数据库:每个租户一个数据库。

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

    这种方案与传统的一个客户、一套数据、一套部署类似,差别只在于软件统一部署在运营商那里。由此可见此方案用户数据隔离级别最高,安全性最好,但是成本较高

    1.3.2 共享数据库、独立 Schema

    (1) 什么是Schema
    oracle数据库:在oracle中一个数据库可以具有多个用户,那么一个用户一般对应一个Schema,表都是建立在Schema中的,(可以简单的理解:在oracle中一个用户一套数据库表)

    在这里插入图片描述
    mysql数据库:mysql数据中的schema比较特殊,并不是数据库的下一级,而是等同于数据库。比如执行create schema test 和执行create database test效果是一模一样的

    在这里插入图片描述
    共享数据库、独立 Schema:即多个或所有的租户使用同一个数据库服务(如常见的ORACLE或MYSQL数据库),但是每个租户一个Schema。

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

    这种方案是方案一的变种。只需要安装一份数据库服务,通过不同的Schema对不同租户的数据进行隔离。由于数据库服务是共享的,所以成本相对低廉。

    1.3.3 共享数据库、共享数据表

    共享数据库、共享数据表:即租户共享同一个Database,同一套数据库表(所有租户的数据都存放在一个数据库的同一套表中)。在表中增加租户ID等租户标志字段,表明该记录是属于哪个租户的。

    • 优点:所有租户使用同一套数据库,所以成本低廉。
    • 缺点:隔离级别最低,安全性最低,需要在设计开发时加大对安全的开发量,数据备份和恢复最困难。

    这种方案和基于传统应用的数据库设计并没有任何区别,但是由于所有租户使用相同的数据库表,所以需要做好对每个租户数据的隔离安全性处理,这就增加了系统设计和数据管理方面的复杂程度。

    在这里插入图片描述

    1.4 SAAS-HRM数据库设计

    在SAAS-HRM平台中,分为了试用版和正式版。处于教学的目的,试用版采用共享数据库、共享数据表的方式设计。正式版采用基于mysql的共享数据库、独立 Schema设计(后续课程)。

    展开全文
  • 企业级SaaS多租户设计

    千次阅读 2020-05-14 11:26:22
    现有企业级SaaS市场在每个细分领域都涌现出了一批玩家,从技术角度看,在不同的领域不同的SaaS产品必定有着同样的架构内核,其中最关键的就是多租户的支持。简而言之,SaaS的成熟度高低,很大程度取决于如何实现...

     

     

    导读

          现有企业级SaaS市场在每个细分领域都涌现出了一批玩家,从技术角度看,在不同的领域不同的SaaS产品必定有着同样的架构内核,其中最关键的就是多租户的支持。简而言之,SaaS的成熟度高低,很大程度取决于如何实现多租户模式的支持。

     

    多租户技术的核心关注点

     

    多租户在技术实现层面目前并没有既定的规范,不仅细节多,每处细节的实现方式也多种多样。

     

    如何落地,一方面取决于当前研发团队现有的技术储备、技术选型、团队资本实力、所处行业或客户特点(比如金融行业对数据安全会有更高要求),另一方面也与当前的技术发展息息相关,云厂商的崛起和云原生时代的到来,也深刻影响着包括SaaS在内的软件构建的方法。

    但常规来说,真正的SaaS应用往往需要满足以下两点

    • 单实例

    • 多租户

    单实例意味着系统资源层面的共享,多租户意味着应用逻辑层面的隔离。所以如何平衡好这两点,才是SaaS应用多租户设计的核心关注点。

     

    经典的分布式服务架构天然解决了互联网应用的三高问题(高并发、高性能、高可用),这也是企业SaaS发展中后期即将面临的问题,下面我们来分析下如何在该架构下去设计与实现多租户SaaS应用。

     

    多租户的实现

     

    从资源共享的层面看,从share nothing到share everything,在天平的任何一个点上都可以支撑多租户。

     

    但正如我们前文所说,SaaS架构首要考虑的目标便是单实例,只有单实例才能将成本尽可能降低,产品才会有规模效应。所以所谓共享和隔离,在经典架构下又会聚焦为一点,即如何对不同租户进行资源层面的隔离。

     

     

    关于资源

     

    谈到资源,我们可能会想到CPU、内存、磁盘、网络带宽等,但如此多类型的资源,从其特征上又可以归为两类,即存储资源和计算资源。

     

    换句话说,SaaS系统在技术本质上也可以认为就是分布式存储和分布式计算的融合

     

    在多租户的实现中,往往更关键的是对于存储资源的处理,计算资源一般只在必要情况下才会考虑,我认为这主要是和存储的“有状态性”有关。下面我们以一些典型场景为例,具体分析一下多租户的设计该如何着手。

     

     

    存储资源的隔离

     

    隔离存储资源概括来说可以用一个词来解决:命名空间。以数据库为例,我们只需要在每条租户的记录上,记下对应租户的标识即可。

     

    一般来说,不考虑分库分表的情况下,我们逻辑上会在同一个Schema中,存储所有租户的数据。这就要求每张表都会有一个tenant_id字段,也即每条记录都携带了它的“命名空间”——租户标识。

     

     

    再以常用的NoSQL方案Redis为例,一般来说也是在同一个分布式集群中存储所有租户数据,那么很明显在key上携带租户标识即可。

     

    所以无论何种存储,思路都是相通的,而且处理起来相对简单粗暴。但这里我想着重强调的是,在工程层面我们应当将这种约定在底层框架里做统一处理。

     

    比如在租户上下文中的所有SQL语句,应当都要携带where tenant_id=?这个条件,才能保证逻辑正确,我们很难想象在代码从零到十万、百万行的过程中,所有人都自始至终都牢记这个规则。

     

    那么类似场景下,我们就可以通过AOP技术将多租户相关的逻辑切出来进行统一处理,比如在Java中,我们可以定义@TenantContextAware注解,以声明而非编码的方式在需要的地方做对应的租户信息获取及传递处理。

     

    那么又如何保证开发者也牢记这个规则呢,由于多租户是SaaS的天然属性,我们可以反其道而行之,默认支持多租户逻辑,同时定义@TenantContextUnaware注解,在不需要多租户的地方进行例外声明,这就大大降低了开发团队的负担。

     

    同理,类似Redis Key的维护,也建议定义统一的KeyGeneratePolicy来维护。

     

    计算资源的隔离

     

    隔离计算资源的方法也可以用一个词来概括,那就是亲和性,简单来说就是租户与集群计算资源的亲和性设计。

     

    计算与存储除了“状态”方面的差异外,还有一个非常重要的区别,计算的财务成本往往远高于存储,比如我们一台虚拟主机上可能只允许数百个线程同时处理请求。

     

    正因为如此,宝贵的计算资源在非必要的情况下一般不会再进行细粒度的隔离,例如我们一般不会在运行时只允许某租户的请求只提交给指定工作线程处理

     

    另外一方面,计算资源发生倾斜的后果,往往比存储要严重的多,如同木桶效应般,直接且显著地影响整个集群的服务能力。

     

    但特定场景下较粗粒度的隔离,有时候还是非常必要的。比如为了减少系统故障时租户的影响范围,我们可能会将租户的请求哈希后提交给不同的线程池处理,因为这种情况下,反压将会产生全局的影响。

     

    另外我们也可能在特定场景下进行进程、集群层面的隔离。总的来说,对计算资源进行隔离,没有既定的模式与套路,而且往往需要高超的资源操作水平,一般不到万不得已不建议实施。

     

    同样地,如果一定要实施,那么也应当以组件化的方式进行,保证业务逻辑的纯粹性。

     

    通过上述对存储和计算资源的隔离处理,我们的SaaS架构整体看起来将会是下图这个结构。

     

     

     

    在这里用一个表格就一些要点对两种手段做个简单的对比,便于大家更直观地理解↓

     

     

    单实例架构的扩展

     

    面向企业的SaaS服务往往还有一些特点可能会引出一些高阶需求,而独立的单实例架构有时候并不能完全满足这些高阶需求。

     

    此时就需要对原有架构进行扩展,以实例级别的整体隔离,配合租户级的请求分流手段,为SaaS带来资源、软件版本等多方面的隔离。

     

    需要注意的是,对单实例架构的扩展,并没有降低其架构成熟度,与我们文中一直在强调的单实例架构理念并不冲突

     

    比如我们往往会根据企业客户的规模和特点对其保障等级进行分级,那如何进一步合理地隔离资源,保障不同级别客户的使用体验,也是一个无法逃避的问题。

     

    这种情况下,我们就可以考虑将这类客户的某些资源实施特殊的保护性隔离,或者干脆将单实例架构扩展成为多实例架构,将客户分流到不同保障级别的资源池。

     

    如果有个别客户体量远超其他客户,那么在成本允许的情况下,我们甚至可以考虑为其建设专属资源池,对其进行重点保障,这种级别的保护并不意味着牺牲了小体量客户的体验,相反,往往大体量客户才更容易发生一些影响稳定性的突发事件,所以可以认为是一种多赢的操作。

     

    另外,SaaS往往能给客户带来更快的特性交付,但这种快速交付很可能带来不佳的使用体验,比如严重BUG的存在。

     

    那么这个时候,如果我们的系统是多实例架构,那么就可以很轻易地实现灰度发布,从而使得特性交付的过程更加稳健,也是对品牌形象的一种保护

    总结

     

    在实际开发中,我们往往容易忽视早期对类似多租户等基础层面的系统性规划与设计,导致后期研发、维护成本持续增加,甚至在面临一些新的商业机会的时候,无法灵活应对。

     

    好的架构则能将这些本质的特征透明化,做到业务层无感,从而提高研发效率。

     

    在企业SaaS的多租户架构设计环节,我们无法罗列或预判所有可能,在不同的技术选型下的多租户实现也有很大差异,我们应当着重去发掘其技术本质,从计算与存储资源的隔离层面,系统地规划与架构,做好基础组件的建设与沉淀。

     

    只有抛开现象去归纳总结相关本质方法,才能以不变应万变。

     

    关于作者

    张晋。网易智慧企业架构师,负责旗下多款SaaS产品的架构、基础设施建设等相关工作,有丰富的C端、B端产品研发经验。目前主要关注企业级产品的技术架构、研发管理等方面

    展开全文
  • 对广大企业来说,引入SaaS产品本质上就是对互联网服务的租赁,因而多租户便必然是SaaS的天然属性之一,也是其与传统互联网应用架构设计的重要差异之一。在SaaS架构的成熟度演进过程中,其核心路线便是如何实现多租户...

     

    企业级SaaS市场近几年在每个细分领域都涌现出了一批玩家。从技术角度看,不同的领域、不同的SaaS产品,必定有着同样的架构内核,其中最关键的便是对于多租户(Multi-Tenancy)的支持。对广大企业来说,引入SaaS产品本质上就是对互联网服务的租赁,因而多租户便必然是SaaS的天然属性之一,也是其与传统互联网应用架构设计的重要差异之一。在SaaS架构的成熟度演进过程中,其核心路线便是如何实现多租户,也就是说,SaaS成熟度的高低,很大程度上取决于如何实现多租户的支持。

    一 多租户技术的核心关注点

    多租户在技术实现层面目前并没有既定的规范,不仅细节多,每处细节的实现方式也多种多样。如何落地,一方面取决于当前研发团队现有的技术储备、技术选型、团队资本实力、所处行业或客户特点(比如金融行业对数据安全会有更高要求),另一方面也与当前的技术发展息息相关,云厂商的崛起和云原生时代的到来,也深刻影响着包括SaaS在内的软件构建的方法。

    但常规来说,真正的SaaS应用往往需要满足以下两点

    • 单实例
    • 多租户

    单实例意味着系统资源层面的共享,多租户意味着应用逻辑层面的隔离。所以如何平衡好这两点,才是SaaS应用多租户设计的核心关注点。

    经典的分布式服务架构天然解决了互联网应用的三高问题(高并发、高性能、高可用),这也是企业SaaS发展中后期即将面临的问题,下面我们来分析下如何在该架构下去设计与实现多租户SaaS应用。

     

    二 多租户的实现

    从资源共享的层面看,从share nothingshare everything,在天平的任何一个点上都可以支撑多租户。但正如我们前文所说,SaaS架构首要考虑的目标便是单实例,只有单实例才能将成本尽可能降低,产品才会有规模效应。所以所谓共享和隔离,在经典架构下又会聚焦为一点,即如何对不同租户进行资源层面的隔离

     

    三 关于资源

    谈到资源,我们可能会想到CPU、内存、磁盘、网络带宽等,但如此多类型的资源,从其特征上又可以归为两类,即存储资源和计算资源。

    换句话说,SaaS系统在技术本质上也可以认为就是分布式存储和分布式计算的融合

    在多租户的实现中,往往更关键的是对于存储资源的处理,计算资源一般只在必要情况下才会考虑,我认为这主要是和存储的有状态性有关。下面我们以一些典型场景为例,具体分析一下多租户的设计该如何着手。

     

    四 存储资源的隔离

    隔离存储资源概括来说可以用一个词来解决:命名空间。以数据库为例,我们只需要在每条租户的记录上,记下对应租户的标识即可。

    一般来说,不考虑分库分表的情况下,我们逻辑上会在同一个Schema中,存储所有租户的数据。这就要求每张表都会有一个tenant_id字段,也即每条记录都携带了它的命名空间”——租户标识。

    再以常用的NoSQL方案Redis为例,一般来说也是在同一个分布式集群中存储所有租户数据,那么很明显在key上携带租户标识即可。

    所以无论何种存储,思路都是相通的,而且处理起来相对简单粗暴。但这里我想着重强调的是,在工程层面我们应当将这种约定在底层框架里做统一处理

    比如在租户上下文中的所有SQL语句,应当都要携带where tenant_id=?这个条件,才能保证逻辑正确,我们很难想象在代码从零到十万、百万行的过程中,所有人都自始至终都牢记这个规则。

    那么类似场景下,我们就可以通过AOP技术将多租户相关的逻辑切出来进行统一处理,比如在Java中,我们可以定义@TenantContextAware注解,以声明而非编码的方式在需要的地方做对应的租户信息获取及传递处理。

    那么又如何保证开发者也牢记这个规则呢,由于多租户是SaaS的天然属性,我们可以反其道而行之,默认支持多租户逻辑,同时定义@TenantContextUnaware注解,在不需要多租户的地方进行例外声明,这就大大降低了开发团队的负担。

    同理,类似Redis Key的维护,也建议定义统一的KeyGeneratePolicy来维护。

     

    五 计算资源的隔离

    隔离计算资源的方法也可以用一个词来概括,那就是亲和性,简单来说就是租户与集群计算资源的亲和性设计。

    计算与存储除了状态方面的差异外,还有一个非常重要的区别,计算的财务成本往往远高于存储,比如我们一台虚拟主机上可能只允许数百个线程同时处理请求。

    正因为如此,宝贵的计算资源在非必要的情况下一般不会再进行细粒度的隔离,例如我们一般不会在运行时只允许某租户的请求只提交给指定工作线程处理。

    另外一方面,计算资源发生倾斜的后果,往往比存储要严重的多,如同木桶效应般,直接且显著地影响整个集群的服务能力。

    但特定场景下较粗粒度的隔离,有时候还是非常必要的。比如为了减少系统故障时租户的影响范围,我们可能会将租户的请求哈希后提交给不同的线程池处理,因为这种情况下,反压将会产生全局的影响。

    另外我们也可能在特定场景下进行进程、集群层面的隔离。总的来说,对计算资源进行隔离,没有既定的模式与套路,而且往往需要高超的资源操作水平,一般不到万不得已不建议实施。

    同样地,如果一定要实施,那么也应当以组件化的方式进行,保证业务逻辑的纯粹性。

    通过上述对存储和计算资源的隔离处理,我们的SaaS架构整体看起来将会是下图这个结构。

    在这里用一个表格就一些要点对两种手段做个简单的对比,便于大家更直观地理解。

     

    六 单实例架构的扩展

    面向企业的SaaS服务往往还有一些特点可能会引出一些高阶需求,而独立的单实例架构有时候并不能完全满足这些高阶需求。此时就需要对原有架构进行扩展,以实例级别的整体隔离,配合租户级的请求分流手段,为SaaS带来资源、软件版本等多方面的隔离。

    但需要注意的是,对单实例架构的扩展,并没有降低其架构成熟度,与我们文中一直在强调的单实例架构理念并不冲突。

    比如我们往往会根据企业客户的规模和特点对其保障等级进行分级,那如何进一步合理地隔离资源,保障不同级别客户的使用体验,也是一个无法逃避的问题。

    这种情况下,我们就可以考虑将这类客户的某些资源实施特殊的保护性隔离,或者干脆将单实例架构扩展成为多实例架构,将客户分流到不同保障级别的资源池。

    如果有个别客户体量远超其他客户,那么在成本允许的情况下,我们甚至可以考虑为其建设专属资源池,对其进行重点保障,这种级别的保护并不意味着牺牲了小体量客户的体验,相反,往往大体量客户才更容易发生一些影响稳定性的突发事件,所以可以认为是一种多赢的操作。

    另外,SaaS往往能给客户带来更快的特性交付,但这种快速交付很可能带来不佳的使用体验,比如严重BUG的存在。

    那么这个时候,如果我们的系统是多实例架构,那么就可以很轻易地实现灰度发布,从而使得特性交付的过程更加稳健,也是对品牌形象的一种保护。

     

    七 总结

    在实际开发中,我们往往容易忽视早期对类似多租户等基础层面的系统性规划与设计,导致后期研发、维护成本持续增加,甚至在面临一些新的商业机会的时候,无法灵活应对。

    好的架构则能将这些本质的特征透明化,做到业务层无感,从而提高研发效率。在企业SaaS的多租户架构设计环节,我们无法罗列或预判所有可能,在不同的技术选型下的多租户实现也有很大差异,我们应当着重去发掘其技术本质,从计算与存储资源的隔离层面,系统地规划与架构,做好基础组件的建设与沉淀。

    只有抛开现象去归纳总结相关本质方法,才能以不变应万变。

     

     

    关于作者

    张晋。网易智慧企业架构师,负责旗下多款SaaS产品的架构、基础设施建设等相关工作,有丰富的C端、B端产品研发经验。目前主要关注企业级产品的技术架构、研发管理等方面

     

    展开全文
  • 行业文档-设计装置-SAAS平台多租户数据管理模型.zip
  • 教育科研-学习工具-SAAS平台多租户数据管理模型.zip
  • MultiTenant-SaaS 项目
  • 目录 0.前言 1.whymybatis-plus? 2.需求分析 ...4.4编写拦截器,在接口调用前进行多租户处理 5.项目测试 总结 参考资料 0.前言 上一篇文章中,我们一起了解了一下saas系统架构中实现...
  • 如果我们开启了Eslint , 也就意味着要接受它非常苛刻的语法检查,包括空格不能少些或些,必须单引不能双引,语句后不可以写分号等等,这些规则其实是可以设置的。我们作为前端的初学者,最好先关闭这种校验,否则...
  • 一、https://www.cnblogs.com/Jeely/p/12325680.html 二、https://blog.csdn.net/johntsu2006/article/details/100600533
  • 目录 0.前言 1.需求分析 2.系统架构设计 3.环境准备 4.编码实现 4.1添加父项目依赖坐标 4.2实现eureka注册中心 4.3实现zuul网关 ...上一篇文章中,我们自己实现了saas系统架构中租户数据隔离的其中一...
  • 1、SaaS多租户实现方案概述 2、MySql数据库SaaS多租户实现方案 3、MongoDB文档数据库SaaS多租户实现方案 4、Redis缓存数据库SaaS多租户实现方案 5、工作流activiti的SaaS多租户实现方案一 6、工作流activiti的...
  • 如果基于传统的数据库设计中存在外键则可以使用面版中的Reference配置个表之间的关联关系,效果如下图 导出sql 菜单->数据库(database)->生成数据库表结构(Generate Database)
  • 2.什么是多租户 3.数据隔离方案 3.1每个租户提供独立的数据库系统 3.2每个租户提供独立的表空间 3.3按租户id字段区分租户 4.三种数据隔离方案的优劣势分析 5. 为土豪准备的解决方案 总结 参考资料 0. ...
  • 一种面向SaaS多租户的多层模型
  • SaaS多租户数据隔离的方案 1.每个租户拥有独立的数据库 2.每个租户拥有独立的表空间 3.每个租户按id字段区分
  • 聊完以后,实在手痒难耐,于是花了两天时间自己实现了两个saas系统多租户数据隔离实现方案。俗话说“独乐乐不如众乐乐”,所以我把我的“研究成果”写出来,让大家乐呵乐呵。 在分享我的研究成果之前,我们先了解...
  • SaaS多租户理解

    2020-06-05 16:55:41
    多租户要做到的最大的问题就是实现数据隔离,处理好了数据隔离多租户问题也就得到了解决。 实现方法 实现方法主要有三种 独立数据库 不同的租户数据放在不同的数据库中 共享数据库,隔离数据架构 所以租户数据放在...
  • #资源达人分享计划#
  • 很多人对于一些SaaS技术问题还是知之甚少,例如企业在进行SaaS企业管理软件选型时,仍不了解“多租户”与“单租户”是什么意思,二者之间的区别更是一头雾水。企业管理者需要明白这两种SaaS架构的特点,才能更地从...
  • 很多人对于一些SaaS技术问题还是知之甚少,例如企业在进行SaaS企业管理软件选型时,仍不了解“多租户”与“单租户”是什么意思,二者之间的区别更是一头雾水。 企业明白这两种SaaS架构的特点,才能更地从未来的...
  • 摘 要:采用副本技术的 SaaS 多租户数据为满足租户访问及服务提供商管理的需求,在云中节点必须合理放置。针对多租户数据特征和节点负载情况,对负载超重节点或超轻节点,通过调整数据副本数目和位置进行放置策略...
  • saas多租户

    千次阅读 2018-11-15 17:24:43
    依据是否具有“可配置”、...那么,继开源框架构建CRM系统初级SaaS成熟度模型之后,如何通过技术手段,实现“可配置”和“多租户”架构呢?今天我们就来探讨这个话题。 一、SaaS “可配置” 架构的技术实现方式 ...
  • SaaS多租户架构摘抄

    2020-10-08 11:39:05
     多租户定义:多租户技术或称多重租赁技术,简称SaaS,是一种软件架构技术,是实现如何在用户环境下(此处的用户一般是面向企业用户)共用相同的系统或程序组件,并且可确保各用户间数据的隔离性。简单讲:在一...
  • 产品经理系列-saas多租户设计

    千次阅读 2019-05-13 18:32:31
    (18)基于 RBAC 的 saas 权限系统设计 ...(19)PaaS 平台——多租户的 RBAC 权限管理(一)基本概念 https://blog.csdn.net/guo_ang/article/details/77658199 (20)SaaS 系统用户权限设计 http://w...
  • SaaS架构设计之如何转化成SaaS多租户模式.pdf
  • SaaS模式下,对共享模式的多租户数据在云中节点环境的划分问题进行了研究,提出一种支持SaaS应用的多租户数据划分模型和算法。与目前主要面向分析型应用并且缺乏事务支持的分区技术和云数据库解决方案进行比较,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,850
精华内容 2,340
关键字:

saas产品多租户