Spring Boot 构建多租户SaaS平台核心技术指南

Posted 2023-05-12

参考技术A

1. 概述

笔者从2014年开始接触SaaS（Software as a Service），即多租户（或多承租）软件应用平台；并一直从事相关领域的架构设计及研发工作。机缘巧合，在笔者本科毕业设计时完成了一个基于SaaS的高效财务管理平台的课题研究，从中收获颇多。最早接触SaaS时，国内相关资源匮乏，唯一有的参照资料是《互联网时代的软件革命：SaaS架构设计》（叶伟等著）一书。最后课题的实现是基于OSGI（Open Service Gateway Initiative）Java动态模块化系统规范来实现的。

时至今日，五年的时间过去了，软件开发的技术发生了巨大的改变，笔者所实现SaaS平台的技术栈也更新了好几波，真是印证了那就话：“山重水尽疑无路，柳暗花明又一村”。基于之前走过的许多弯路和踩过的坑，以及近段时间有许多网友问我如何使用Spring Boot实现多租户系统，决定写一篇文章聊一聊关于SaaS的硬核技术。

说起SaaS，它只是一种软件架构，并没有多少神秘的东西，也不是什么很难的系统，我个人的感觉，SaaS平台的难度在于商业上的运营，而非技术上的实现。就技术上来说，SaaS是这样一种架构模式：它让多个不同环境的用户使用同一套应用程序，且保证用户之间的数据相互隔离。现在想想看，这也有点共享经济的味道在里面。

笔者在这里就不再深入聊SaaS软件成熟度模型和数据隔离方案对比的事情了。今天要聊的是使用Spring Boot快速构建独立数据库/共享数据库独立Schema的多租户系统。我将提供一个SaaS系统最核心的技术实现，而其他的部分有兴趣的朋友可以在此基础上自行扩展。

2. 尝试了解多租户的应用场景

假设我们需要开发一个应用程序，并且希望将同一个应用程序销售给N家客户使用。在常规情况下，我们需要为此创建N个Web服务器（Tomcat）,N个数据库（DB），并为N个客户部署相同的应用程序N次。现在，如果我们的应用程序进行了升级或者做了其他任何的改动，那么我们就需要更新N个应用程序同时还需要维护N台服务器。接下来，如果业务开始增长，客户由原来的N个变成了现在的N+M个，我们将面临N个应用程序和M个应用程序版本维护，设备维护以及成本控制的问题。运维几乎要哭死在机房了…

为了解决上述的问题，我们可以开发多租户应用程序，我们可以根据当前用户是谁，从而选择对应的数据库。例如，当请求来自A公司的用户时，应用程序就连接A公司的数据库，当请求来自B公司的用户时，自动将数据库切换到B公司数据库，以此类推。从理论上将没有什么问题，但我们如果考虑将现有的应用程序改造成SaaS模式，我们将遇到第一个问题：如果识别请求来自哪一个租户？如何自动切换数据源？

3. 维护、识别和路由租户数据源

我们可以提供一个独立的库来存放租户信息，如数据库名称、链接地址、用户名、密码等，这可以统一的解决租户信息维护的问题。租户的识别和路由有很多种方法可以解决，下面列举几个常用的方式：

解决了上述问题后，我们再来看看如何获取客户端传入的租户信息，以及在我们的业务代码中如何使用租户信息（最关键的是DataSources的问题）。

我们都知道，在启动Spring Boot应用程序之前，就需要为其提供有关数据源的配置信息（有使用到数据库的情况下）,按照一开始的需求，有N个客户需要使用我们的应用程序，我们就需要提前配置好N个数据源（多数据源）,如果N<50,我认为我还能忍受，如果更多，这样显然是无法接受的。为了解决这一问题，我们需要借助Hibernate 5提供的动态数据源特性，让我们的应用程序具备动态配置客户端数据源的能力。简单来说，当用户请求系统资源时，我们将用户提供的租户信息（tenantId）存放在ThreadLoacal中，紧接着获取TheadLocal中的租户信息，并根据此信息查询单独的租户库，获取当前租户的数据配置信息，然后借助Hibernate动态配置数据源的能力，为当前请求设置数据源，最后之前用户的请求。这样我们就只需要在应用程序中维护一份数据源配置信息（租户数据库配置库），其余的数据源动态查询配置。接下来，我们将快速的演示这一功能。

4. 项目构建

我们将使用Spring Boot 2.1.5版本来实现这一演示项目，首先你需要在Maven配置文件中加入如下的一些配置：

然后提供一个可用的配置文件，并加入如下的内容：

接下来，我们需要关闭Spring Boot自动配置数据源的功能，在项目主类上添加如下的设置：

最后，让我们看看整个项目的结构：

5. 实现租户数据源查询模块

我们将定义一个实体类存放租户数据源信息，它包含了租户名，数据库连接地址，用户名和密码等信息，其代码如下：

持久层我们将继承JpaRepository接口，快速实现对数据源的CURD操作，同时提供了一个通过租户名查找租户数据源的接口，其代码如下：

业务层提供通过租户名获取租户数据源信息的服务（其余的服务各位可自行添加）：

接下来是配置自定义的数据源，其源码如下：

在改配置类中，我们主要提供包扫描路径，实体管理工程，事务管理器和数据源配置参数的配置。

6. 实现租户业务模块

在此小节中，租户业务模块我们仅提供一个用户登录的场景来演示SaaS的功能。其实体层、业务层和持久化层根普通的Spring Boot Web项目没有什么区别，你甚至感觉不到它是一个SaaS应用程序的代码。

首先，创建一个用户实体User，其源码如下：

业务层提供了一个根据用户名检索用户信息的服务，它将调用持久层的方法根据用户名对租户的用户表进行检索，如果找到满足条件的用户记录，则返回用户信息，如果没有找到，则返回null;持久层和业务层的源码分别如下：

7. 配置拦截器

我们需要提供一个租户信息的拦截器，用以获取租户标识符，其源代码和配置拦截器的源代码如下：

8. 维护租户标识信息

在这里，我们使用ThreadLocal来存放租户标识信息，为动态设置数据源提供数据支持，该类提供了设置租户标识、获取租户标识以及清除租户标识三个静态方法。其源码如下：

9. 动态数据源切换

要实现动态数据源切换，我们需要借助两个类来完成，CurrentTenantIdentifierResolver和AbstractDataSourceBasedMultiTenantConnectionProviderImpl。从它们的命名上就可以看出，一个负责解析租户标识，一个负责提供租户标识对应的租户数据源信息。

首先，我们需要实现CurrentTenantIdentifierResolver接口中的resolveCurrentTenantIdentifier()和validateExistingCurrentSessions()方法，完成租户标识的解析功能。实现类的源码如下：

有了租户标识符解析类之后，我们需要扩展租户数据源提供类，实现从数据库动态查询租户数据源信息，其源码如下：

最后，我们还需要提供租户业务模块数据源配置，这是整个项目核心的地方，其代码如下：

10. 应用测试

最后，我们通过一个简单的登录案例来测试本次课程中的SaaS应用程序，为此，需要提供一个Controller用于处理用户登录逻辑。在本案例中，没有严格的对用户密码进行加密，而是使用明文进行比对，也没有提供任何的权限认证框架，知识单纯的验证SaaS的基本特性是否具备。登录控制器代码如下：

在启动项目之前，我们需要为主数据源创建对应的数据库和数据表，用于存放租户数据源信息，同时还需要提供一个租户业务模块数据库和数据表，用来存放租户业务数据。一切准备就绪后，启动项目，在浏览器中输入：http://localhost:8080/login.html

在登录窗口中输入对应的租户名，用户名和密码，测试是否能够正常到达主页。可以多增加几个租户和用户，测试用户是否正常切换到对应的租户下。

总结

云平台下的多租户架构，从SaaS应用到PaaS平台，你应该理解的一些关键点

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

多租户架构概述

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

多租户技术可以实现多个租户之间共享系统实例，同时又可以实现租户的系统实例的个性化定制。通过使用多租户技术可以保证系统共性的部分被共享，个性的部分被单独隔离。

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

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

比如我们开发一个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应用实际需要同时灵活支撑上面三种模式。

文章来源：人月聊IT，作者：何明璐；

编辑：云朵匠 | 数商云(微信ID：shushangyun_com)