什么是多租户系统？

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

这篇文章最初发布在我的博客上。

软件系统的设计者被称为架构师并非偶然。软件架构师借鉴了土木工程中的许多概念。多租户就是其中之一。与土木工程类似，软件多租户优化了资源利用率，同时提供了灵活的定制选项。

让我们先从土木工程的角度来理解这个概念。

我出生在一栋独立的房子里。房子虽小，但却独立自主。我们可以随心所欲地布置它。我们把房子隔成两部分，一边是牛棚，另一边是居住空间。我们不需要征得邻居的同意。在自己的土地上，我们可以自由地做任何想做的事。但这种自由也是有代价的。如果遇到任何公用设施（比如水）方面的问题，我们都得自己解决。

我上大学的时候住在宿舍。我们每个人都有一间独立的房间，可以自带家具。有些人只带了够四年生活所需的基本家具，而少数家境优渥的学生则带了豪华的家具。学校负责宿舍的维护和维修。虽然允许我们自带家具，但我们不能对房间进行任何改动，甚至连墙壁的颜色都不能改。房间的布置并不能代表我们。

工作几年后，我买了一套公寓。200户业主户型相同，但我们都用自己喜欢的家具布置了房子。有些人甚至进行了更深入的改造，比如建了一个隔音录音室！和我们住的宿舍一样，公寓的维护和维修都由一家公司负责。

现在让我们从软件工程的角度来理解这个概念。

让我们以软件行业的例子来探讨这个问题。

假设我想搭建自己的邮件和文档服务器。经过一番搜索，我选择了OwnCloud ^1。我把它安装在自己的服务器上。我创建了一个账户供自己使用。这是一个单用户、单租户系统。我既是用户又是租户。我可以对系统进行任何我想要的修改。

想把它托管在单独的域名上？没问题。
想更改系统颜色？没问题。
想选择和使用模块？没问题。

随着我对这套系统的逐渐熟悉，我想和妻子及家人共享日历。我为他们每个人都创建了单独的账户。现在系统变成了多用户系统，但仍然是单租户模式。每个用户可以自定义一些功能，例如日历名称，但无法选择性地启用某些功能。如果我妹妹想将这个日历与她的 Gmail 日历同步，她做不到。为什么呢？因为如果我启用这个功能，它就会对所有人启用，我不想让我的父亲因为这个新选项而感到困惑。目前没有办法只对某个用户或一组用户启用该功能。

现在我的同事马丁和鲍勃对我管理家庭日程的方式印象深刻，他们也想效仿。我可以把 OwnCloud 安装在他们自己的服务器上，这样他们就可以自由地进行自定义设置。但他们不想操心服务器的管理和监控，所以他们请我帮忙管理。他们还告诉我，他们不想与任何人共享数据，并问我是否可以为他们设置独立的数据存储。事情还没完。马丁只需要日历功能，希望通过 schedules.martinfamily.com 访问系统。而鲍勃则希望通过 familyroom.bob.com 访问系统。正如网址所示，除了日历之外，他还想存储家庭文档。他希望使用 AWS S3 作为数据存储。由于 OwnCloud 支持多租户，我可以帮他们实现所有这些功能。他们对设置非常满意，并邀请所有家庭成员使用该系统。他们决定付费使用我的服务。我按使用量收费，而不是收取固定费用。 （我真希望故事能像童话故事那样结尾：我在夏威夷过上了幸福的生活 :-)）。现在，这套系统已经发展成一个多用户、多租户系统。

正如您所理解的，并非所有Web应用程序都必须是多用户系统，也并非所有多用户Web应用程序都必须是多租户系统。所有解决方案都取决于具体情况。架构师必须根据给定的需求选择合适的方法。

构建多租户系统比构建多用户系统更复杂。构建多租户系统有两种模型：实例复制和数据隔离。

在实例复制模型中，系统会为每个租户创建一个新实例。这种模型启动起来比较容易，但扩展性较差。当数百个租户注册时，就会出现严重的问题。

在数据隔离模型中，应用程序在租户之间共享，但每个租户的数据存储在不同的数据存储区中。不同的数据存储区可以是不同的数据库，也可以是同一数据库中的不同模式。

为了支持这种数据隔离，系统架构中需要增加一个管理层，以便在每个租户注册时都配置一个独立的数据存储。多租户模式包括为每个租户定制用户界面、选择性订阅服务以及按使用量计费。该管理层负责所有这些功能。

现在应该很清楚，多租户系统并非适用于所有Web应用程序。对于B2C（企业对消费者）Web应用程序而言，多用户架构就足够了。而对于B2B（企业对企业）应用程序，则应考虑采用多租户架构。

尽管多租户架构较为复杂，但像 GDPR 这样的数据隐私法规将迫使大多数 B2B SaaS 应用采用多租户系统。如果您正在构建新的 B2B SaaS 应用，最好从一开始就采用多租户架构。

1. 我与owncloud没有任何关联。这只是一个例子 。↩