多租户架构设计

最新推荐文章于 2025-04-03 07:01:05 发布

加酶洗衣粉

最新推荐文章于 2025-04-03 07:01:05 发布

阅读量1.6k

点赞数 1

文章标签：架构后端

本文链接：https://blog.youkuaiyun.com/weixin_43996530/article/details/132722405

版权

多租户是SaaS领域的特有产物，在SaaS服务中，租户是指使用SaaS系统的客户，租户不同于用户，例如，B端SaaS产品，用户可能是某个组织下的员工，但整个企业组织是SaaS系统的租户。多租户技术是一种软件架构技术，可以实现多个租户共享系统实例，并且租户间能够实现数据与行为的隔离。

1、SaaS模式

针对ToB端的开发，传统的方式一般是开发一套独立的软件系统，然后通过独立部署的方式，部署在客户方的资源上，一般是内网。SaaS（Software as a Service）是一种云计算服务模式，它提供基于互联网的软件应用程序，通过订阅或按需付费的方式，让用户在云端直接使用这些应用程序，而无需购买、安装和维护软件的复杂基础设施。

2、多租户功能

我们现在讨论的多租户功能都是基于SaaS模式下，多个租户可以共享同一套软件系统，对于软件服务上来说有多个租户在服务上，但是对于单个租户使用来看和单租户一样，一个多租户的软件应用应该包含以下功能：

多个租户支持共享一套云资源，如计算、存储、网络资源等。
多个租户间能够实现行为和数据的隔离，能够对租户进行分权和分域控制。
租户内部能够支持基于组织架构的管理，可以对产品能力进行授权和管理。
不同的产品能力可以根据客户的要求，支持运行在不同的云资源上。

多租户模型

单个租户内部模型

3、多租户隔离

上面说到多租户的一个重要功能就是要实现行为和数据的隔离，对于客户来说没有租户区分的概念，但是对于服务来说，需要把每一个租户的操作和产生的数据隔离开来。多租户隔离主要是对资源的隔离，而资源分计算资源和存储资源，下面这就两种隔离做介绍。

计算资源隔离

计算资源主要是CPU、内存和网络等机器资源，SaaS模式下可以认为就是云资源。现在SaaS部署环境一般都是基于k8s构造，所有的服务都运行在k8s集群中，方便动态扩缩容，所以这里讲解隔离方式也以这种方式为基础。

k8s集群中会涉及到很多种资源，比如IngressRoute、Middleware、Service、Deployment、Pod 等，所以资源的隔离也就是控制这些资源的访问形式，避免这些资源间的相互影响和污染。

多租户模型-多集群

多集群模式可以完美解决资源隔离问题，每个租户只能访问自己所属集群的控制平面，但是完美的隔离带来的问题就是严重的资源浪费。

【优点】

满足强隔离要求，每个租户单独部署在一个环境，安全性高。
计费逻辑简单，SaaS针对每个租户使用的资源进行计费
降低了故障影响面，资源之间使用服务互相不影响，不会导致故障的扩散。

【缺点】

成本高，每个租户都要部署一套独立集群环境，这就要求更多的计算资源，如果有成千上万的租户，那将会产生很高的资源成本。
运维困难，如果有成千上万套集群，那对于运维管来说将会非常的复杂，会有很大的挑战。
敏捷迭代能力差，SaaS模式的一个主要优势就是可以进行频繁的迭代，快速响应市场需求，如果换成这种多集群模式，部署都会比较麻烦。
系统监控困难，环境复杂，监控每一个集群的资源使用情况变得困难。

多租户模型-资源复用

和多集群相对的就是资源复用，也称为分享模式，是一种软多租户模式。一套集群中接入所有的租户，租户之间共享计算资源，对于业务APP来说租户是透明的，也就是业务服务无状态，集群通过水平扩展来满足租户对资源使用的要求。

资源复用和多集群的模式刚好相反，所以带来的问题也刚好是相反，节省资源，但是隔离性就没那么高，所有的租户在同一个环境操作，会互相有影响。

【优点】

成本低，资源得到充分利用，根据所有租户的使用情况动态扩缩容，保证了资源的充分利用。
运维简单，对于运维人员来说相当于一套资源，方便进行维护。
监控方便，针对单个集群的资源监控，监控基础设施和服务指标变得简单。
快速迭代，多个租户共用同一套环境，可以快速进行产品的迭代。

【缺点】

隔离性不高，共享模式下，不同租户是在同一个环境操作的，互相之间会有影响，比如一个体量大的租户可能会占用系统80%资源，导致其他租户使用系统的体验感很差。
计费困难，多个租户使用的同一套基础设置，就不好针对计算资源来进行计费，必须针对每个租户设计计费模式。

多租户模型-分版本资源复用

这是资源复用模式的一个延伸，虽然是在同一套环境里，但是对产品的使用还是有差别的。因为对于客户来说租户是透明的，客户只会要求购买哪一个版本的服务。所以共享模式下同一个环境中可能会存在多个版本的服务，这个就需要进行灰度控制了，不同的租户路由到不同版本对应的NameSpace。

分版本资源共享模式也是现在SaaS模式下常见的一种模式，因为多集群的这种方式在维护和成本上都会有很大的挑战，至于共享模式下的计算资源使用互相应用的问题，这个可以通过平滑扩容的方式来解决，保证客户都有一个比较好的产品使用体验。

多租户模型-分域隔离模式

这种模式其实是前两种模式的一个组合，因为客户的规模不同，所以对产品的部署要求可能也会不一样。比如体量大的客户，有很强的支付的能力，对安全性和隔离性要求高，这种就可以采用多集群的模式，单独为其部署一套环境。而对于那些体量较小，支付能力没那么强的客户可以共享同一套环境。

存储资源隔离

除了计算资源的隔离，在存储上也需要做到合理，上面说到我们大部分情况都是使用的共享模式，对于客户来说租户区分的概念是要弱化的，也就是让客户感觉就只有自己在使用，那么就要求做到存储资源的隔离，说的简单一点就是不同租户操作的数据不能串了，A租户创建的订单在B租户那里展示出来了，这种肯定是不行的。

存储资源比较多，有数据（MySQL/MongoDB）、文件资源（Minio）还有分布式文件存储，这里我拿比较常用也最重要的数据资源来讲解，以MongoDB为例，在资源隔离上我们大致有以下几种方式：

按照隔离性从高到低，MongoDB 的多租户模型可以分为以下四种：

I. 集群或实例级别：每个租户一个 MongoDB 集群（或实例）

II. 数据库级别：所有租户在同一个集群（或实例），每个租户一个数据库
III. 集合（表）级别：所有租户在同一个数据库（按业务划分），每个租户一个集合

IV. 文档（记录）级别：所有租户在同一个集合中，通过集合中的不同字段（一般叫 tenant_id）来区分不同租户的数据

不同的模型在隔离性和共享性上的强弱可以用一张图来体现：

MongoDB 多租户模型分析

从安全角度来说：

模型 IV 最容易出现查询上的安全漏洞以及各种 bug。因为它的所有租户的数据都存储在同一个集合中，操作时很容易互相影响导致数据污染。从模型 IV 到模型 I 的安全性逐步递增。
模型 I 可以做到磁盘、内存、CPU 的隔离，模型 II 可以做到磁盘和内存的隔离，而其余两种模型做不到机器资源的隔离。
模型 I 和 II 可以做到存储级别的静态数据加密，每个租户使用自己的 key；其余两种模型只能做到应用级别的加密，这样可能导致同一个数据库中的数据不可读取。
模型 I 和 II 可以做到每个租户都使用各自的 x.509 证书来进行认证并加密自己的连接；但模型 III 和 IV 所有租户只能共享同一个数据库连接。
模型 I 和 II 可以对租户做到数据库级别的 RBAC 鉴权及审计，其余两种模型无法对租户做 RBAC 鉴权及审计。

从运维角度来说：

模型 I 和 II 具有租户级别的便携性，比如可以很方便地将整个租户的数据进行迁移；模型 III 和 IV 很难做到。
模型 I、II、III 可以很方便地根据租户 ID 进行数据的水平扩展，比如增加一个租户只需要增加一个实例/数据库/集合即可，很大程度上降低了单表的数据量（如果遇到超大租户，可再根据二级 key 来进行分片）；模型 IV 如果出现数据过多的情况只能根据租户 ID 进行数据分片。
模型 IV 在做跨租户的查询时有优势，但一般的实时查询很少需要做跨租户的查询；模型 I、II、III 要做跨租户查询只能通过定时任务来聚合数据做查询或者通过 ETL 平台来做这件事。

最后是成本的角度：