多租户设计与实践探索

港控/mmm° 2022-08-30 01:45 345阅读 0赞

## 前言 ##

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

## 为什么需要中台 ##

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

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

## 租户由来 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70]

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

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

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

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

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

**答案是否定的**

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

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

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

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

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

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 2]

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

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

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

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

## 何为租户 ##

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

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

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

## 单独户和多租户 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 3]

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

**优点：**

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

**缺点：**

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 4]

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

**优点：**

*  租户之间资源可以方便的实现共享
 *  用户隔离，数据隔离（逻辑上）
 *  后期可以方便的对数据进行提取分析，也可以方便的通过tenant\_id对数据库、数据表做拆分

**缺点：**

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

## 租户的主要功能 ##

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

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

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 6]

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

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

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

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

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 7]

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

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

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

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

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

## 多租户展望 ##

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

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

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

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

**本篇到此结束，最后感谢观看！**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70]: /images/20220829/e044dc5f65734675a39189d349b8fbc0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 1]: /images/20220829/358ba47e3051442ead58d285b2d58b70.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 2]: /images/20220829/7921f9d4257543718739fded31564c42.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 3]: /images/20220829/eb07774f688f492ea2793922b03cddcb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 4]: /images/20220829/40e0411c86084d398716e7729ed95d6e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 5]: /images/20220829/cd23f238c7294457bdfc46093ffc2368.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 6]: /images/20220829/c4054051c13146e096ba4dfb77049941.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY29uZ3lpNDIw_size_16_color_FFFFFF_t_70 7]: /images/20220829/88f45864a5ec4197a9fb10b2499af04e.png