很多人对 SaaS 平台的多租户设计都缺乏概念上的支撑，因此会觉得难以理解，本篇文章梳理了一下 SaaS 系统的多租户设计的结构，以及各类设计的特点，相信对 SaaS 产品经理会有不小的帮助。

前几天和几个搞技术的同事体验了一家公司的 SaaS 系统，从运营平台，到租户授权平台再到业务应用，一路配置起来到应用步骤挺繁琐的，以至于技术同事都不明白为什么会这么复杂。才发现，他们对 SaaS 平台的多租户设计其实了解很少，由于缺乏概念上的支撑，因此会觉得难以理解这样的设计。

对于刚接触 SaaS 平台的产品经理来说估计也是有很多不明白的地方，本篇就来讲讲 SaaS 平台的多租户设计。

一、以钉钉来看实际多租户场景

在讲设计之前，我们先以“钉钉”为例，来看看一个 SaaS 平台是如何运作的。相信大部分B 端产品经理都体验过钉钉，我们分两个维度来讲钉钉的租户注册到使用的流程。

一个是从个人视角来看使用钉钉的流程，下面图就是个人使用钉钉的流程。这个流程省略了个人注册和其他人加好友聊天的功能，那个其实不算 B 端的业务范畴了。

这里的关键是你要使用某个企业（或团队，以下我们统一称为租户）下的功能，首先你需要被邀请加入某个租户。而且，一个账号可以被邀请加入多个租户。

如果你属于多个租户，那么和某个租户相关的操作你需要先切换到该租户下才可以使用。比如我们的工作台、云盘这些就和租户有关，下面的图就是钉钉的工作台，默认会有一个租户，可以通过下拉方式切换租户。

那么从租户的角度来说，是什么样的呢？流程如下图所示。

与个人不同，对于租户来说，多了创建团队、企业认证和邀请成员几个步骤。这属于管理员类的功能，其中企业认证不是必需的，只是经过认证的企业可用的功能和资源多一些。

通过钉钉的例子我们会得到如下的实体关系：

• 一个平台有很多个租户；
• 一个平台也有很多用户；
• 一个用户属于多个租户，一个租户也有很多个用户。

这个是基础的关系，务必要明白。所以实际上一般 SaaS 平台会有三个后台：

1. 运营管理后台：即平台运营管理的后台系统，通常用于管理租户，主要是租户的权限、资源的分配管理；这个平台我们作为 SaaS 用户是接触不到的，但是作为 SaaS 产品设计是必不可少的。
2. 租户管理后台：即租户使用的管理后台，主要是用于租户的管理员管理成员和分配租户内部成员的权限、资源。
3. 业务应用：也就是实际租户的各个成员使用的业务系统，比如我们平时使用的钉钉的桌面端、App 其实都算是业务应用。这个业务应用其实是有多个的。比如钉钉自带的 OA 审批、考勤系统、智能填表等等，其实都是一个个业务应用。有些设计为了简化，在后台系统上，会将租户管理后台和业务应用合并为一个后台。

二、租户权限与资源管理

对于一个平台，租户是其服务的主要对象，也是最终的买单人，即 SaaS 系统的订阅者。因此，SaaS 的运营管理后台的一个核心职能就是管理平台上的租户的权限和资源管理。权限的管理和 SaaS 平台的订阅模式有比较大的关系，从抽象角度上来说也可以认为是一种资源。我们常见的 SaaS 在权限这块有两种方式：

1. 按销售版本订阅：这种不同的版本会有不同的功能。一般用于平台本身的业务应用是单体应用，即权限是在应用内，按租户订阅的版本不同分配不同的功能。
2. 按应用订阅：这种是平台比较大了，平台会有若干个应用，租户首先选择开通平台中的某些应用。当然，应用内可以再细分出销售版本，钉钉其实就是这种模式。这种模式比较重，但是扩展性会比较好，适用于有心构建开放应用平台的 SaaS 产品。

两种模式的结构对比如下两张图所示，当然，多应用的 SaaS 平台每个应用也可以单独再分出一层销售版本来。

资源一般来说会分为两类，一类是平台级资源，一类是应用内资源。平台级资源由平台统一管理，比如钉钉里的钉盘容量，应用的使用期限等。

应用内资源即各个应用自身的资源，比如授权使用的账号数（当然平台级有些也会有总的账号数限制）、短信条数等。

这种资源管理的原则是谁维护谁管理，也就是平台维护的资源由平台管理，应用维护的资源由应用管理，下面是资源的关系结构图。一般来说，资源会需要租户购买，或者平台会定期发放免费资源（比如钉钉的“短信钉”就是按月有免费的额度可以使用）。

三、菜单管理

既然涉及到不同销售版本，就会有菜单的管理，也就是需要将菜单统一管理，然后再把菜单组合成销售版本，最后根据租户购买的版本进行授权，最终落到客户那边呈现的就是可用的菜单。

这里同样会涉及一个问题，就是菜单归平台管还是归应用管。这两种模式其实现实中都有。我们遇到的平台就是平台统一管理，也就是应用首先要在平台配置菜单，这样租户才可以使用。

个人来说，不推荐这种由平台统一管理的方式。一方面是导致平台和应用强耦合，如果平台有第三方应用的话，意味着第三方需要和平台要同步菜单；另一方面是限制了平台的灵活性，因为既然是菜单，要统一管理就需要有一套标准的菜单管理模式，这就要求应用必须按照平台的规则来。还有一个是，平台要给应用开发者（或运营者）开放账号管理菜单，实际上也增加了复杂度。

实际上，应用开发方也会有对应的运营团队，平台只需要给租户和应用开发方提供沟通的渠道就可以了。比如，租户订阅某个应用成功后，通知应用开发方及时维护租户的权限即可。

因为，实际 B 端企业订阅某个应用，会有个下单付款过程，一般付款都是采用汇款的方式（我们在钉钉上购买第三方应用的时候也是单独付款给第三方，而不是经过支付宝这类通道），这就意味着付款成功后才会介入服务。

当然，也有免费提供试用期的，这个时候只要租户订阅应用，应用开发方的售后团队就可以提前介入提供服务，实际上后续付费后也能接得上。

有了菜单管理后，SaaS 的实体关系变成了下面的样子，这里省略了资源，实际资源和销售版本有点类似，只是会有平台级和应用内资源。总结来说，各个实体的关系如下：

• 一个平台会有多个应用；
• 一个应用会有多个菜单，通过菜单组合成多种销售版本；
• 租户属于1个平台，租户可以根据自身需要订阅多个平台下的应用的某个销售版本。
• 租户拥有多个用户，用户也可以属于多个租户，但用户则属于同一个平台。

四、多租户设计核心要点

有了上面的整体概念后，我们就知道 SaaS 的多租户设计的核心要点了，整理如下图所示。这里说明几点：

1. 用户和账号的区别

对于平台来说，注册的账号实际是平台用户，要通过用户来确定用户的唯一性。

同时，为了用户能够切换租户，需要有用户租户管理（即用户属于哪些租户）；对于租户来说，用户其实就是账号，也就是我这个租户下开通了哪些账号，一般一个账号就对应一个员工。

需要注意的是，租户下的账号可以注销的（或者是禁用），比如说员工离职了，他还可以使用平台，但是无法使用该租户下的功能。

2. 订单管理

平台、应用和租户都能够看到订单，只是范围不同。平台管理整个平台的订单（不包含应用内自己的资源订单，除非平台覆盖到了应用内的交易环节），应用内管理应用自身产生的的订单，而租户看到的是自己的订单。

3. 租户权限管理

平台如果是纯粹的平台，那么其实可以没有权限管理的，但是一般 SaaS 平台不会是一个空架子，会有一个或多个核心抓手应用。这个就看平台的设计了，是一开始就把自己的应用当作第三方等同对待还是特殊处理。

应用管理租户的权限主要是销售版本的管理，这个很多时候可以通过订单自动同步管理。不过，要考虑特殊场景，比如租户可能购买的是较低级版本，但是为了推广高级版本，可能会在后台给租户开通高级版本的试用权限。

4. 租户后台

租户后台其实和业务应用可以混合在一起，只是管理员的权限不同而已。租户后台主要就是邀请成员（开账号），进行授权管理（通常会有功能权限和数据权限），然后是自己在平台消费的资源和订单管理，主要是购买和查看为主。

5. 业务应用

一般是基层员工用的频次更多，对于管理层更多提供的是报表类的功能。这里主要是能够支持用户切换租户以及便于租户下的成员使用租户开通的业务应用功能。

五、多租户数据存储设计

在技术上多租户数据存储有三种方式，最简单的一种是共用数据表，也就是不同租户的数据存储在同一张数据表中，然后通过租户 id 区分。这种适合小型的 SaaS应用，优点是开发实现简单，缺点是不同租户之间的操作数据会有一定的影响（因为操作的同一个数据表，如果多个租户同时操作，会有并发性能问题）。

另一种是分表设计，即不同的租户的数据表结构虽然相同，但是使用各自的数据表。比如说一个权限表名是 auth，那么 A 租户的叫 a_auth，B 租户的叫 b_auth。这种设计需要根据租户动态创建表，一般表名会有租户 id 来区分唯一性。隔离程度上，比共用表好很多，复杂性也高一些，同时由于是共用了数据库，整体性能会受数据库性能影响，也就是租户之间的操作还是一定程度上会相互影响。

最后一种是分库设计，就是不同的租户使用不同的数据库，这样在数据上是完全隔离的。当然，技术实现上也最复杂了。对于业务系统比较重的垂直SaaS应用，建议是按这种方式设计。因为，深入客户业务的 SaaS 系统一般都是高频操作，随着客户量增加，如果不分离数据，会导致性能瓶颈出现。

当然，实际也可以采用渐进式的数据存储设计，即客户少的时候使用共用数据表，客户稍微多的时候用分表设计，最后再使用分库设计。这种前期成本低，后期会有数据迁移成本。

六、总结

本篇梳理了一下 SaaS 系统的多租户设计的结构，各类设计的特点，相信对 SaaS 产品经理会有不小的帮助。对于 SaaS 系统的设计，如果要调研复杂的 SaaS 系统，推荐大家可以体验阿里云后台和钉钉，相比而言，云厂商的后台虽然不太像 SaaS，但是基本的设计思想是一样的，而且云厂商的设计更为复杂一些，涵盖了多个业务子系统和多类资源分配。