精华内容
下载资源
问答
  • 多租户表设计

    千次阅读 2018-01-24 22:00:00
    2019独角兽企业重金招聘Python工程师标准>>> multi-tenant-databases-in-the-cloud ...团队开发框架实战—多租户支持 转载于:https://my.oschina.net/yangjiandong/blog/1612626
    展开全文
  • 多租户设计与实践探索

    千次阅读 2021-07-18 10:42:25
    从中台架构的理念提出到现在,经过了3年的实践,行业内从一些大厂开始纷纷将自身的架构逐步改造成中台架构或者基于中台模式的架构进行规划,到今天来看,从中台架构出发,衍生出各种与之相关的模式,如sass等,其...

    前言

    从中台架构的理念提出到现在,经过了3年多的实践,行业内从一些大厂开始纷纷将自身的架构逐步改造成中台架构或者基于中台模式的架构进行规划,到今天来看,从中台架构出发,衍生出各种与之相关的模式,如sass等,其底层技术架构的规划,仍然和中台是一脉相承的

    为什么需要中台

    关于这一点,可以参考阿里内部人士撰写的一本《企业IT架构转型之道 阿里巴巴中台战略思想与架构实战》,有非常详细的解读

    个人也有幸参与过2个小型的中台化产品的建设与改造,从实践上来说,产品逐步向中台(这里指代技术中台,不同的公司有自己的中台,比如业务中台,数据中台等)靠拢的好处在于,业务更加聚焦,不再像之前那样各种定制化的需求一大堆,兵来将挡水来土掩,最后弄得毫无章法,技术上来说,偏向基础而底层的微服务可以逐步抽象并下沉,使得公司的技术体系更加完备,比如数据存储服务,中间件服务,数据统计分析服务等,从而技术人员有更多的精力去研究如何在提升系统的高并发等性能方面进行发力,而对于上层应用来说,有了这些基础的底层服务的支撑,快速开发新的基于中台的应用也就变得更高效

    租户由来

    在这里插入图片描述

    想必很多同学对电商类系统一定不陌生吧,就像上图展示的这种架构,一般的电商系统或者类电商(医疗电商,宠物商城,团购电商等)模式,都有一个前台系统和后台系统,前台系统是流量的主要来源,而且随着硬件技术的发展,前台的入口也越来越多,图中展示的来源包括,网页,app,Ipad,甚至一些广告屏幕,小程序等

    前台页面中产生的数据来源于各类渠道用户的交互点击行为,比如某个用户产生了一笔订单数据,这些进入订单表的数据,对于公司来说,最终都是要走财务流程的,为了财务核算数据,就需要一个后台系统,专门处理订单表的数据,这只是其中一个非常简单的场景

    再比如说,当系统处于流量高峰期时,比如像双11那样的大促,为了确保核心服务可用,可以考虑关闭一些无关紧要的服务,为了能够快速的关闭前台服务展示的各种菜单入口,总不能直接去服务器上面把这个服务给kill掉吧,通常各类的服务都可以通过后台系统统一配置管理,根据需要进行快速的启停等操作

    从以上描述来看,这个后管系统对于整个系统的作用是不言而喻的

    在上面的后管系统中,为了管理前台页面的数据,经常需要从后管系统中对数据进行管理,是不是所有人都可以登录后管系统进行操作呢?

    答案是否定的

    通常来说,系统的超级管理员只有一个,即admin,为了分担admin的压力,通常可以通过admin创建出一些2级管理员,授予这些2级管理员一定的角色,然后就可以通过这些2级管理员来管理各种菜单、资源、用户等数据权限了

    到这里,就要引出租户的概念了,从上面的后管系统开始,可以发现,后管的主要目的是为了统一管理一些前台数据,和前台甚至后台操作相关的权限等等

    一旦当前台的应用架构演变为中台架构之后,需要对各种数据、资源权限相关的操作就更多了,本文以小编参与过的一个中台产品,基于sass架构的中台产品为例,来探讨下租户的设计与实践

    我们知道,所有中台建设的目的都是为了业务快速且低成本创新,绝大部分的企业基于中台都会开发大量的业务应用,一般基于业务中台的架构如下图:

    在这里插入图片描述
    上图为某业务中台架构模式,在该业务中台下,可以划分成不同的维度,可以确定的是,业务中台承载的应用是多样的,输出的能力也是多样的,但不管今后有多少新的应用加入到中台中,有一点可以确定的是,任何一个使用中台的账户,需要被授予一定的权限,才能具有访问中台下各个子模块应用的能力

    这就像大家的支付宝账号,不仅可以访问支付宝,还可以访问淘宝、天猫、阿里云等等阿里生态的几乎所有产品,因为你的支付宝账号对应的背后的应用,理论上都是阿里大中台下的一个个具体的应用而已

    在如此的背景下,我们亟需一个统一管理用户、授权等数据的应用或者入口,对访问中台中各个应用的资源细化到更具体的层面,这就是对应的权限配置

    在这里插入图片描述

    以上就是用户中心简易功能图,即用户中心最基本的管理用户,管理权限的能力,但是在中台模式下,整个缺少远远不够的,为什么呢?

    这种类似简单的用户管理后台一样的系统,在小规模的几个微服务应用之下,还是可以支撑勉强应付,但对于中台来说,尤其是要商业化的中台产品,必然要考虑的一个问题就是,你的前台应用要拿出去卖钱的,针对不同的客户,对于用户数据的管理必然有不同的需求,有的客户希望自建数据库,有的想上公有云,有的想玩私有云,有的甚至想混合云,并且能够打通各种云之间的数据通道

    更有一种极端情况,用户希望有一种方式可以使用你的中台应用达到数据上的隔离,如果将用户的需求理解为 “数据空间”的话,那么就需要你的用户中心具备数据隔离的能力,即在不同的数据空间下,用户能够管理的应用资源也是不同的

    这里就可以将这个 “数据空间”理解为租户

    何为租户

    租户可以当作一个逻辑上的概念进行理解,相信有购买过阿里云或者腾讯云等服务器的小伙伴有过深刻的体会,其实你购买的云服务器或者云服务,本质上来说,购买完成之后,你就是服务提供商的一个租户,你是在租用他们的服务,而服务器提供商从他们那里给你分配了一个虚拟机或者服务器空间,你可以在这个独立的空间上进行各种操作,安装应用,跑mysql服务等

    也就是说,你是作为一个租户在有限的空间内使用服务提供商的资源,而这个空间内你操作过程中产生的一切数据都归属于你自己这个租户

    从中台架构上来说,租户可以表示为使用中台应用的第三方,为了管理自身的用户数据,合理的为其单位下的各类用户分配不同的应用资源权限等操作,需要一个独立的逻辑上的隔离空间,来达到目的

    单独户和多租户

    在这里插入图片描述

    单租户下,平台中只有一个租户,即使用平台应用的只有一个租户,所有租户相关的管理数据都在这一个租户中完成

    优点:

    • 单租户系统独立享有所有资源,用户不隔离,数据独享
    • 支持自定义所有功能,具备较大灵活性,后期定制化功能时预留空间大
    • 支持高可用,高并发,分布式部署

    缺点:

    • 维护成本高,上百套系统需投入大量的运维及开发
    • 资源浪费极大,如果用户需要多个租户,则需要横向扩张服务器资源
    • 存在私有云、公有云、混合云部署,对数据抽离及分析存对技术提出了很大的挑战

    在这里插入图片描述

    多租户是相对但租户来说的,多租户主要从逻辑上将租户进行了区分,实际操作时,可以通过 tenant_id字段标识与之相关的数据表

    优点:

    • 租户之间资源可以方便的实现共享
    • 用户隔离,数据隔离(逻辑上)
    • 后期可以方便的对数据进行提取分析,也可以方便的通过tenant_id对数据库、数据表做拆分

    缺点:

    • 支持有限定制化功能开发
    • 数据隔离上存在一定的安全隐患(逻辑隔离)
    • 对混合云的支持不够好

    租户的主要功能

    这是本篇探讨的一个很重要的话题,上面谈到了租户的由来,我们大致了解到,租户其实要完成的工作其实和后管中的内容差不多,只是从设计上来说,比单纯的后管系统要更复杂,而且可以支持使用平台的单位更加灵活的对用户、资源等数据进行分配,更重要的是,要提供数据隔离空间

    在这里插入图片描述
    这仅仅是用户中心的基础功能,为了能够达到租户级别的数据控制,我们还需要有一个可以配置管理租户的地方,我们可以理解为 “租户管理”模块

    小编在实际产品中,租户管理是作为单独的微服务应用划分出来的,这样有个好处,就是可以集中管理所有的租户,即你在租户管理中,可以创建租户,删除租户,以及为租户分配用户数据

    想必这么一描述之后,大家心里对租户管理服务应该有个大致的模样了,试想,如果没有租户管理的话,若还想满足用户对于租户的需求,那就只能是单租户,即默认为每个使用本系统的单位为一个租户,这样来说,从后期更长远的需求规划上,就很难再满足用户从单租户切换为多租户

    在这里插入图片描述

    实际的实施流程大概是下面这样的

    在客户购买我们整个标准产品后(包括业务中台、或部分基础应用),首先我们在顶级租户中预置了一个root账户,通过该账户我能够创建更多租户,并为租户实例化应用,在实例化应用的同时,为该租户生成在该应用实例下的租户管理员。

    租户管理员能够登入本租户进行租户下的全局的权限管理,例如:他能在该租户下创建用户,并设置该用户能够登录的应用;他能为租户下的任一应用实例创建角色,并把该角色分配租户下的用户

    也就是说,租户其实和用户中心的功能是相辅相成的,用户中心的功能是基础,租户相当于是隔离了一块块区域,在该区域下,管理自己的数据,入用户、权限、用户组等等

    当然在实际操作中,远远比上面描述的要复杂,举例来说,如何让中台下的各个应用都能快速接入租户这一套体系呢?

    这是一个业务问题,也是一个技术问题,本篇的最后,以实践中的经验来简单探讨下

    在这里插入图片描述

    以上图为例,为一个sass应用使用admin用户默认登录之后的界面展现,上面我们简单提到过,应用的分配可以在租户下进行分配

    通常来说,对于初次安装的使用单位,会默认分配基本的应用,这个可以在租户应用侧在程序初始化的安装的时候,根据商务要求,通过读取配置中心的配置,将基础的应用初始化注册到应用相关的数据表中

    为了方便后续新接入的应用可以继续注册进去,从租户侧的微服务来说,提供了更灵活的方式来实现应用注册,包括:restFul接口,dubbo接口,当然也可以通过租户的界面进行配置

    注册之前,比如当调用租户侧的dubbo接口注册时候,需要携带一定的参数,除了必要的参数之外,有一个参数非常必要,就是全局的apiKey,对于apiKey这个想必大家并不陌生,这个apiKey的产生在于用户创建那一刻就产生了,而注册应用时,为了确定租户信息,还需要携带一个tenant_id的参数

    其他的和租户相关的操作,租户侧也提供了各类基于apiKey和tenant_id的dubbo服务接口,供各个应用的微服务模块进行调用,比如注册权限,新建用户组等

    多租户展望

    在实际实践过程中,由于需要真实对接客户方的需求,针对一些大的客户方,比如像某某油公司这样的大金主,由于总部到分部人员众多,对于租户的使用也提出了越来越多的需求,举例来说,客户方希望对租户的类型进行区分,也可以理解为等级,不同等级的租户具备不同的操作权限,即不再是单纯的在各个租户下进行自己租户下用户、资源、权限等数据管理,还能对租户自身进行分级管理,其目的之一,在于加强总部(顶级租户)对下级租户的管控

    第二个需求是,客户希望所有的用户数据只有一个入口和出口,即租户管理中,在本文上篇描述的,用户信息一般来源于顶级租户,即admin这个账户产生的用户数据,然后各个租户可以登录之后管理自己的用户数据(用户的增删改查,及基于用户的资源权限分配),但是客户希望所有的用户只能从admin顶级租户往各个租户做分配,即各个租户不再单独产生用户数据,而是由顶级租户生产,然后分发到各个租户,然后各个租户再管理这部分的用户数据

    这么做的考虑在于总部对分部对用户数据的集中管理

    当然,这也说明,基于多租户的业务,还有很多值得探究的问题,毕竟在大环境下互联网安全的话题越来越被重视的情况下涉及到数据安全的问题,所以对于租户的探索,还需要更多丰富的场景来完善我们的认知

    本篇到此结束,最后感谢观看!

    展开全文
  • 主要介绍了springboot多租户设计过程图解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
  • 干货分享!Saas架构如何针对确保安全性、创建可扩展数据模型以及数据基础结构的可扩展性等方面进行设计,本文给出答案!
  • oracle数据库:在oracle中一个数据库可以具有个用户,那么一个用户一般对应一个Schema,都是建立在Schema中的,(可以简单的理解:在oracle中一个用户一套数据库) mysql数据库:mysql数据中的schema比较...

    共享数据库、独立 Schema

    (1) 什么是Schema

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

     mysql数据库:mysql数据中的schema比较特殊,并不是数据库的下一级,而是等同于数据库。比如执行create schema test 和执行create database test效果是一模一样的

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

    优点: 为安全性要求较高的租户提供了一定程度的逻辑数据隔离,并不是完全隔离;每个数据库可支持更多的租户数量。

    缺点: 如果出现故障,数据恢复比较困难,因为恢复数据库将牵涉到其他租户的数据; 如果需要跨租户统计数据,存在一定困难。

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

    共享数据库、共享数据表

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

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

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

     

    展开全文
  • 第三个示例 : 使用多租户应用,并且具有分片式多租户数据库。 三种模型,从左向右,资源共享程度依次变高,当然成本也就逐步下降,但与之带来的就是技术难度也在大幅增加。 数据库的实现 -- 租户表:租用系统的...

    租户模式

    • 三种多租户模式
      在这里插入图片描述

    第一个示例 : 使用每租户的独立应用程序和其自己的数据库。

    第二个示例 : 使用多租户应用,并且每个租户都具有一个数据库。

    第三个示例 : 使用多租户应用,并且具有分片式多租户数据库。

    三种模型,从左向右,资源共享程度依次变高,当然成本也就逐步下降,但与之带来的就是技术难度也在大幅增加。

    数据库表的实现

    
    -- 租户表:租用系统的客户
    CREATE TABLE IF NOT EXISTS `sys_tenant` (
      `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '租户id',
      `name` varchar(255) DEFAULT NULL COMMENT '租户名称',
      `code` varchar(64) DEFAULT NULL COMMENT '租户编号',
      `start_time` timestamp NULL DEFAULT NULL COMMENT '开始时间',
      `end_time` timestamp NULL DEFAULT NULL COMMENT '结束时间',
      `status` char(1) NOT NULL DEFAULT '0' COMMENT '0正常 9-冻结',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='租户表';
    
    -- 租户客户表:
    -- tenant_id : 表示属于哪一个租户
    CREATE TABLE IF NOT EXISTS `customer` (
      `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
      `name` varchar(255) NOT NULL COMMENT '名称',
      `tenant_id` int(11) NOT NULL,
      PRIMARY KEY (`id`) USING BTREE
    ) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='租户客户表';
    
    -- 用户表(3 种类型 :系统用户,租户用户,租户客户用户):
    -- tenant_id : 表示属于哪一个租户
    -- customer_id: 表示属于哪一个客户
    -- 哪个租户的哪个客户的用户信息
    CREATE TABLE IF NOT EXISTS `sys_user` (
      `user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
      `username` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT '用户名',
      `password` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
      `salt` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '随机盐',
      `dept_id` int(11) DEFAULT NULL COMMENT '部门ID',
      `mini_openid` varchar(32) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '小程序openid',
      `gitee_login` varchar(32) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '码云登录',
      `osc_id` varchar(32) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '开源中国',
      `wx_openid` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '微信openid',
      `qq_openid` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT 'QQ openid',
      `user_stype` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户类型(0:系统用户,1:租户用户,2:租户客户用户)',
      `tenant_id` int(11) DEFAULT NULL DEFAULT '1' COMMENT '所属租户',
      `customer_id` int(11) DEFAULT NULL DEFAULT '1' COMMENT '所属客户',
      PRIMARY KEY (`user_id`) USING BTREE,
    ) ENGINE=InnoDB AUTO_INCREMENT=412 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC COMMENT='用户表';
    
    -- 用户与角色关联表
    CREATE TABLE IF NOT EXISTS `sys_user_role` (
      `user_id` int(11) NOT NULL COMMENT '用户ID',
      `role_id` int(11) NOT NULL COMMENT '角色ID',
      PRIMARY KEY (`user_id`,`role_id`) USING BTREE
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='用户角色表';
    
    -- 系统角色表(3 种类型 :系统角色,租户角色,租户客户角色):
    -- tenant_id : 表示属于哪一个租户 ;
    -- customer_id: 表示属于哪一个租户客户 ;
    -- dept_id: 表示属于哪一个部门;
    -- ds_scope: 数据权限范围(为部门ID集合),即此角色可操作范围
    -- ds_type: 数据权限类型(读,写,读写)
    -- 哪个租户的哪个客户的角色信息
    CREATE TABLE IF NOT EXISTS `sys_role` (
      `role_id` int(11) NOT NULL AUTO_INCREMENT,
      `role_name` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
      `role_code` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
      `role_desc` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL,
      `ds_type` char(1) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT '2' COMMENT '数据权限类型',
      `ds_scope` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '数据权限范围',
      `tenant_id` int(11) NOT NULL COMMENT '所属租户',
      `customer_id` int(11) DEFAULT NULL COMMENT '所属客户',
      `dept_id` int(11) DEFAULT NULL COMMENT '所属部门',
      PRIMARY KEY (`role_id`) USING BTREE,
    ) ENGINE=InnoDB AUTO_INCREMENT=28 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC COMMENT='系统角色表';
    
    -- 角色菜单表
    CREATE TABLE IF NOT EXISTS `sys_role_menu` (
      `role_id` int(11) NOT NULL COMMENT '角色ID',
      `menu_id` int(11) NOT NULL COMMENT '菜单ID',
      PRIMARY KEY (`role_id`,`menu_id`) USING BTREE
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ROW_FORMAT=DYNAMIC COMMENT='角色菜单表';
    
    -- 菜单权限表(3 种类型 :系统菜单,租户菜单,租户客户菜单):
    -- tenant_id : 表示属于哪一个租户,可实现定制化菜单;
    -- customer_id: 表示属于哪一个租户客户 ;
    CREATE TABLE IF NOT EXISTS `sys_menu` (
      `menu_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '菜单ID',
      `name` varchar(32) NOT NULL COMMENT '菜单名称',
      `permission` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT '菜单权限标识',
      `path` varchar(128) DEFAULT NULL COMMENT '前端URL',
      `parent_id` int(11) DEFAULT NULL COMMENT '父菜单ID',
      `icon` varchar(32) DEFAULT NULL COMMENT '图标',
      `component` varchar(64) DEFAULT NULL COMMENT 'VUE页面',
      `sort` int(11) DEFAULT '1' COMMENT '排序值',
      `keep_alive` char(1) DEFAULT '0' COMMENT '0-开启,1- 关闭',
      `type` char(1) DEFAULT NULL COMMENT '菜单类型 (0菜单 1按钮)',
      `tenant_id` int(11) DEFAULT NULL DEFAULT '1' COMMENT '租户',
      `customer_id` int(11) DEFAULT NULL COMMENT '所属客户',
      PRIMARY KEY (`menu_id`) USING BTREE
    ) ENGINE=InnoDB AUTO_INCREMENT=100362 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='菜单权限表';
    
    
    -- 租户数据库的信息:
    -- tenant_id : 表示属于哪一个租户,可实现 上述三种模式中的后两种
    CREATE TABLE IF NOT EXISTS `sys_datasource_conf` (
      `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
      `name` varchar(255) DEFAULT NULL COMMENT '名称',
      `url` varchar(255) DEFAULT NULL,
      `username` varchar(255) DEFAULT NULL,
      `password` varchar(255) DEFAULT NULL,
      `tenant_id` int(11) DEFAULT NULL COMMENT '租户ID',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ROW_FORMAT=DYNAMIC COMMENT='数据源表';
    
    
    -- 部门表(3 种类型 :系统部门,租户部门,租户客户部门):
    -- tenant_id : 表示属于哪一个租户,每一个租户都有自己的部门数;
    -- customer_id: 表示属于哪一个租户客户 ;
    -- 哪个租户的哪个客户的部门信息
    CREATE TABLE IF NOT EXISTS `sys_dept` (
      `dept_id` int(20) NOT NULL AUTO_INCREMENT,
      `name` varchar(64) DEFAULT NULL COMMENT '部门名称',
      `parent_id` int(11) DEFAULT NULL,
      `tenant_id` int(11) DEFAULT NULL COMMENT '所属租户',
      `customer_id` int(11) DEFAULT NULL COMMENT '所属客户',
      PRIMARY KEY (`dept_id`) USING BTREE
    ) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ROW_FORMAT=DYNAMIC COMMENT='部门管理';
    
    -- 职位表(3 种类型 :系统职位,租户职位,租户客户职位):
    -- tenant_id : 表示属于哪一个租户
    -- customer_id: 表示属于哪一个租户客户 ;
    -- dept_id : 表示属于哪一个部门
    -- 哪个租户的哪个客户的哪个部门的职位信息
    CREATE TABLE IF NOT EXISTS `sys_job` (
      `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
      `name` varchar(255) NOT NULL COMMENT '职位名称',
      `tenant_id` int(11) DEFAULT NULL,
      `customer_id` int(11) DEFAULT NULL COMMENT '所属客户',
      `dept_id` int(20) DEFAULT NULL,
      PRIMARY KEY (`id`) USING BTREE
    ) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC COMMENT='职位表';
    
    
    • 名词解释

    系统用户 :就是软件开发商用户;
    租户用户:就是软件租用方用户;
    租户客户用户:就是租户的客户用户;
    如果租户就是软件开发商的客户的话,可以简化为前两种用户,因为租户就是客户。

    所有的表都要加上 租户ID [ 、客户ID ]、部门ID,以此表明资源所属者是:哪个租户的 [ 哪个客户的 ] 哪个部门的资源 。

    操作权限如何判断?

    可通过 springSecurity 自定义 AccessDecisionManager,根据登录用户获取用户权限,再此用户权限来匹配此次访问的url。

    数据权限如何判断?

    可通过 mybaits / JPA 的拦截器,获取原始sql并改写(就是在sql基础上加上 tenant_id / customer_id / dept_id 条件)。

    一个用户可以完全管理自己的资源,并可以管理职权范围内( 读,写,读写 )的本人所在体系(就是这个人属于哪个租户或者哪个客户)下授予的权限范围(部门)。

    展开全文
  • 多租户方案设计

    千次阅读 2021-02-03 15:13:38
    独立数据库 独立服务实例 优点:独立部署,数据服务... 优点: 维护和购置成本最低,允许每个数据库支持的租户数量最多。 缺点: 隔离级别最低,安全性最低,需要在设计开发时加大对安全的开发量 数据备份和恢复最困
  • mybatis-实现多租户.zip

    2020-08-12 14:11:24
    mybatis实现多租户,java,mybatis,sass
  • 在上一篇“浅析多租户在 Java 平台和某些 PaaS 上的实现”中我们谈到了应用层面的多租户架构,涉及到 PaaS、JVM、OS 等,与之相应...在SaaS实施过程中,有一个显著的考量点,就是如何对应用数据进行设计,以支持租...
  • 多租户系统设计

    千次阅读 2021-11-30 09:45:22
    多租户系统设计SaaS 的系统分级SaaS 系统架构成熟度模型的 5 个级别——从“混乱”到“乌托邦“第 0 级(混乱):每次新增一个客户,都会新增软件的一个实例。第 1 级(受控的混乱):所有客户都运行在软件的同一个...
  • 我最初的计划是创建一个商店,一个用户和一个user_stores交叉.然后,我会在stores中保存该存储的数据库名称(并使用应用程序用户和密码创建每个特定于商店的数据库,以便Web应用程序始终可以登录).每个商店都有...
  • 分析了 Kubernetes 访问控制和资源隔离实现方案基础上,提出了一种基于多租户访问控制模型的容器云平台多租户方案,涵盖多租户管理模型、多租户访问控制、计算资源隔离和网络资源隔离等,可切实提升基于Kubernetes的...
  • Let us say I need to design a database which will host data for multiple companies. Now for security and admin purposes I need to make sure that the data for different companies is properly isolated b...
  • SaaS 系统架构成熟度模型的 5 个级别——从“混乱”到“乌托邦“ 第 0 级(混乱):每次新增一个客户,都会新增软件的一个... 第 3 级(多租户, 扩建 [Build-Out]):此时你已经拥有了多租户、单一版本的软件模型。
  • Keycloak Policy-Enforcer多租户问题 这是一个示例项目,旨在演示在多租户配置中使用Keycloak的Policy-Enforcer时遇到的一些问题。 有问题的 似乎在多租户体系结构中使用的Keycloak Spring-Boot适配器的策略执行器会...
  • 多租户系统设计之权限控制

    千次阅读 2020-03-13 21:29:54
    也是多租户系统必须实现的隔离,在上篇文章中提到的数据隔离主要是针对数据存储层面而言的,用户一般感知不到,所以如“基于数据行的租户唯一标识”方案中,即使存储在相同的数据也是可以的。在系统设计层面,业务...
  • 多租户系统架构

    2021-02-08 04:12:56
    多租户系统架构一种多租户系统架构背景:去年的时候,因为某些特殊原因,有幸带了一个组,参与了B2B平台的开发。说是B2B平台,因为这套程序开发完了后,可以拿给个客户使用。客户可以搭建一套具有京东商城风格,...
  • 数据库多租户数据隔离设计

    千次阅读 2020-08-03 11:30:09
    SaaS 是一种软件布局模型,其应用专为网络交付而设计,便于用户通过互联网托管、部署及接入。” 也就是说,我只需要能连接上互联网,并且给saas平台交租金,我就能用saas平台给我提供的系统服务。这方面最典型的...
  • 彻底理解微商城多租户Saas架构设计

    千次阅读 2020-07-28 09:49:35
    彻底理解微商城多租户Saas架构设计 原文链接:https://blog.csdn.net/haponchang/article/details/104246317,感谢作者提供这么好的总结! 1.具体的SaaS架构必须 1.先仔细选择最适合应用程序需求的租户模型, 2....
  • springboot多租户设计

    2021-01-19 12:43:35
    首先从租户数据源配置中获取所有的配置,然后对这些数据源进行一个个的初始化。getDataSouce方法中,也对数据源进行了一个map的映射,先放到一个容器中,如果初始化过了,直接拿出来使用即可。 3.7 这里才是真正的...
  • 对可行性进行分析后选择了共享库,按租户id字段区分租户的方式去实现。以此记录一下方便日后所需查阅 1.熟悉多租户之前先来了解一下什么是SaaS系统 以下内容来着百度百科 SaaS平台是运营saas软件的平台。SaaS...
  • 原文:http://www.ibm.com/developerworks/cn/java/j-lo-dataMultitenant/index.html在上一篇“浅析多租户在 Java 平台和某些 PaaS 上的实现”中我们谈到...数据层的多租户综述多租户(Multi Tenancy/Tenant)是一种软...
  • 本文内容包括:简介租户身份验证和授权机制在租户上下文中访问常用J2EE工件租户数据层设计模式隔离和定制业务过程的人员/角色选择...我们将介绍几种主要共享资源的多租户设计模式。另外,即将发表的一个develope
  • 多租户
  • PostgreSQL 多租户

    千次阅读 2016-11-24 13:16:39
    PostgreSQL 多租户 作者 digoal 日期 2016-11-07 标签 PostgreSQL , 多租户 , schema , ...Oracle 12c提出了数据库多租户的概念,即PDBs(私有数据库),因为早期Oracle的设计是以schema为隔离的,schema的隔离不...
  • 设计多租户SaaS应用程序时,您必须仔细选择最适合您应用程序需求的租户模型。租户模型确定每个租户的数据如何映射到存储。您选择的租户模式会影响应用程序设计和管理。以后切换到另一个模型有时代价昂贵。 关于可...
  • 多租户多租户-源码

    2021-02-13 18:28:11
    多租户多租户
  • 多租户Saas架构设计分析(实践篇)

    万次阅读 多人点赞 2020-02-11 15:30:14
    上一篇文章已经将SaaS架构做了一个简单的介绍和分析,此篇进入实践篇。 ...2.需要根据租户模型来选定最终的架构,即应用程序设计和管理、每个租户的数据如何映射到存储等等。 避免因租户模型的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 21,928
精华内容 8,771
关键字:

多租户表设计