云时代的多租户架构系统设计

什么是多租户？

多租户是一种软件架构技术，实现如何在多用户的环境下，共用相同的系统或程序组件，并可保持各用户间数据的隔离性。

多租户简单来说，指的是一个单独的实例可以为多个组织服务。

多租户技术，可以实现了同一数据中心为多个用户提供相同服务或定制化服务，并保障用户的数据隔离。

一个支持多租户技术的系统，需要在设计上对它的数据和配置进行逻辑区分，从而使系统的每个租户或组织能够用一个实例，为每个租户根据自己的需求进行个性化配置。

多租户有两种形式：

所以多租户技术，带来的架构主要价值包括，多租户共享系统实例，同时又可以为不同租户提供系统的个性化定制。

也就是说，多租户可以保证系统共性部分被共享，个性部分被单独隔离。

进而有效节省开发成本，提高需求交付效率，为系统迭代过程的稳定性提供保障。

比如我们开发一个SaaS化的CRM系统，部署在云端，可以开放给多个企业客户使用。

传统的交付方式，每当有一个新客户入驻时，都需要为他单独部署一套实例，提供新客户使用。

这样做，成本和资源投入都比较大。

因此，我们希望，当一个新客户入驻时，仍然可以使用原有的那套系统，同时新客户又感知不到这点，就像为他们单独部署了一套系统一样。

就是说，所有入驻的客户共享一套应用，但又能很好地做到资源和数据的隔离。

多组织架构，重点考虑的是数据层面的隔离，比如财务安全管控要求。但对于多租户架构来说，还需要考虑资源层面的隔离，比如云平台中的计费和计量管理。

租户为的是资源管理和计费定量使用，用户更多是为了业务功能和授权使用。

一些C端应用，用户和租户是对等的，比如一个在线邮箱系统，一个人就是一个租户。

但如果你的SaaS面向的是企业用户，那么这个时候，租户对应的是组织，也就是企业，入驻之后要给企业分配管理员账号，可以管理、录入其他用户账号。

也就是租户是第一层即组织，下面的用户是第二层。组织可以看做一个租户集的概念。

不只是SaaS应用，PaaS应用本身也有租户概念。

比如企业内部的公共业务流程平台，是一个PaaS平台，这个平台就需要设计成多租户，因为每个组织都需要自己的一个流程。

类似的其他PaaS平台，如DB平台、KV平台、MQ平台都需要引入租户概念。

在多租户数据隔离上，需要考虑三种形式：

1. 系统本身元数据和基础主数据的隔离（用户、角色、权限、数据字典、流程模板）；
2. 系统运行中产生的动态数据的隔离；
3. 业务系统底层所涉及到的计算资源和存储的隔离；

数据库层面隔离有两种方式：

1. 独立数据库：为每个租户分配独立数据库；
2. 共享数据库和共享schema：新租户单独生产新的独立schema；
3. share everthing：数据库和schema共享，通过租户标识逻辑分离；

总之，要做好租户之间的数据隔离，一个租户不应该看到其他租户下的数据，以满足业务需求。

独立数据库模式，隔离性好，但资源利用率低。

完全共享模式，隔离性弱，但资源利用率高。

具体采用哪种方式，可以根据租户需求和付费情况，具备灵活配置迁移的能力。

在当前云原生技术下，很多存储资源的隔离可以考虑用PaaS实现。

因为云原生时代下，资源弹性、部署都比较简单。完全可以为单独的大租户动态扩展一套独立的容器集群为该租户服务，实现该租户独享一组容器资源，而非共享。

云时代的多租户设计，需要为各个租户按需实时提供各种计算存储资源，就需要清楚定义数据采集和计费模式。

对于独享资源的多租户计费比较好搞，复杂的是共享资源的多租户，因为需要考虑用户注册数、并发数、存储容量分配的组合计费。

由于资源是共享的，必须能够准确采集各租户实际资源使用情况，便于多租户计费。

多租户还需要考虑可靠性问题，在IaaS平台上，做了多租户设计，需要在计算、网络、存储做资源隔离。就是任何一个租户导致的虚拟机异常问题，不应该影响到其他租户使用虚拟机。

还有一些应用层面的处理，不然多个租户并发访问同一套实例资源，需要按租户做好流量限流与隔离，一个租户的流量异常，不应该影响其他租户正常使用系统。

说到稳定性，需要更悲观一些，即使资源完全共享的多租户架构，仍然不建议采用一个大集群为所有租户提供服务。

而是要对大集群做分域或分组，或对大集群的资源做分区或分片。

让不同租户分配到不同集群分组或分片上。

这样既可以避免单个大集群无限扩展导致的性能问题和管理难度，也可以提升整个应用的容错能力，比如做多可用区的切量就比较简单。

我们的 bdf 框架就是为多租户系统设计的，可以帮助 saas 系统低成本支撑多租户，并对于遗留系统变为多租户系统改造更友好。