关于多租户系统的思考

前言

今天去公园走了十四多公里,想通了很多事情。其实,最近困扰我的主要是这个多租户系统的搭建都需要做什么事情。初步想来,其实很多问题,但是,当我大方向决定使用分数据库来解决的时候,似乎大多数问题都解决了,剩下的问题就是如何实现了。而这中间的实现其实也有不少问题,接下来我们一个一个来聊聊。

思考

数据隔离

多租户的系统最根本是每个租户在系统上都不会感受到别的用户的存在。而与多用户的区别是,租户有自己的用户,而租户的用户也是感受不到别的租户的,但是可以感受到同租户下用户的存在。就像是用同一套代码充当很多个公司的管理后台一样。这件事的复杂度是很高的。基本上来说,就是在原来所有的事情基于用户的前提下,再多一个租户的过滤。这件事要深入到每一个业务中。如果真的这么做,这事看起来也不难。但是,我们希望租户的概念在开发的时候是尽可能透明的。
  所以,我们选择一个租户一个数据库。这样,每个数据库的复杂程度和原来就相同的。但是,这也迎来了另一个挑战,多数据源。不过这件事我们后面说,这里,我们仅说明,数据隔离,我们使用多数据库的方案实现。这里面临的更多的问题可能就是自动创建数据库,和自动创建数据表这类事了,这些就属于细节上的一些小事情了,或许会存在问题,不过都可以实现。

身份认证

在之前,我一直将这个问题归结为会话的问题。但是,今天我想的时候,把验证用户身份,和维持会话两件事情分开了。事情,似乎一下开朗了。验证用户身份,是验证这个人是否是他声明的那个人。身份验证通过,我们才开启会话。如果有其它的机制的话,我们也可能不需要验证身份就开启会话,总之,两者是合作关系,而不是谁是谁的必要条件。

多数据源

说数据隔离的时候,我们提到了多数据源。其实,多数据源的情况是复杂的。首先,不同租户在同一应用下,需要切换数据源,来更新各自的数据库。其次,因为存在公共统一的后台服务,它们可能会落入到统一的数据源。这样就可能需要在同一个事务里操作多数据源,这件事,是复杂的。在之前我们使用XA
事务做过一个版本。说实话,当时总是出现一些资源耗尽的事情,而且这样处理吞吐量是很低的。个人也不喜欢XA事务。但是,开发人员是喜欢的,因为不用学太多新东西。不过,今天我又深入得思考了一番,为什么一定要使用多数据源呢?我们可以用API嘛。

前后端分离

本来呢,这并不是多租户的必要条件。但是,我希望我这次的多租户系统可以是统一前端,但是后端api的提供可以分离,再通过api网关聚合出来。但是,这里有个很讨厌的事,就是前端很难获得后端的配置信息。于是,我就想了个办法,让后端生成一个js文件,让前端引用。然后,我今天解决的问题就是怎么让它不缓存这个js文件而每次更新,我们在js后面加个参数。但是,这个随着前后端分离后可能会变成一个伪需求,因为我发版不用重新打包了。不过,无论如何,让js文件及时更新的方法是非常有用的。

权限如何划分

在传统来说,我们的系统一般来说是直接划分菜单的。但是,最近,我头疼的是,我们每个功能模块可能都有仪表盘中的一部分内容。那么,我再直接给用户划分菜单,似乎就不太合适了。这里如何组织,是值得深入思考的。

应用如何研发

在多租户系统中,其实存在很多重复的基础模块,比如上述说到的菜单。那么,这些是不是我们就可以集中存储和打造了呢?那如果这个模块可以集中存储和打造,那么别的模块又怎么做呢?这个是真的值得深入思考的。

后记

这里引出了对多租户问题的一些思考,后续我有进展还会更新。欢迎一起讨论。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

征途无悔

发文不易,谢谢认可

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值