多租户架构

架构介绍

NLPKB Cloud 属于SaaS系统平台架构，SaaS平台的一个重要特点就是租户（tenant）架构设计。一个租户通常被看做一个用户，不同租户空间是相互隔离的，即用户之间的数据不可见。

早期的架构设计是仅仅在数据表中提供一个tenant附加字段，在执行业务时通过对tenant字段的筛选完成数据隔离。这种简易的设计使多个租户共用同一套数据表系统，在业务增长过程中，该数据表规模会同时随着租户量和业务量的增加而迅速增长。常用的数据表很容易达到规范或性能的上限，要经常进行分割存储，致使后期维护成本较高。另外，一旦该业务表不可用，那么所有的租户就都不可用了。这种脆弱的设计导致其不适合单租户大规模数据量的SaaS系统架构。

另一种极端的架构模式是，SaaS为每一个租户建立一套独立的应用系统实例，有的包括独立的应用系统和数据库实例，有的甚至包括操作系统的部分基础设施；即，有多少个租户在服务端（集群）就有多少个相互独立的租户系统，除应用系统、数据库系统外，每个租户甚至还有一套独立的文件系统、内存空间、CPU或GPU运算资源，甚至IP地址等基础设施。虽然，在云服务器行业，这已经是一种常见的设计模式，但对于纯粹的应用系统而言，由于租户必须按需为上述的各种基础设施支付费用，而这些费用均与业务无关，显然这种架构模式的成本较高。

我们希望建立一种能够混合上述两种模式的优势，而规避掉它们各自劣势的SaaS架构，我们希望它具有如下特征：

• 在同一实例上运行的多个租户：在同一示例上部署多个租户，而不需要重复构建数据库或操作系统级别的基础设施。所有租户共享操作系统的存储资源、运算能力和文件系统。只要存储空间（内存和硬盘）、运算能力（CPU/GPU）允许，可以构建尽可能多的租户，每个租户的部署不需要重新构建一套全新的操作系统环境。

• 逻辑隔离租户的共用数据：每个租户的空间都划分为共用数据空间和独立数据空间两部分。共用数据空间包括：系统的全局配置信息；每个租户都需要访问的全局配置信息；租户的身份认证信息；创建和分配租户的配置信息；共用数据区，如新闻、社区，发布和交付物，以及允许租户直接交叉访问的其他信息。共用空间中，各租户数据实现逻辑方式隔离。

• 物理隔离租户的独立数据：而SaaS架构可以从物理上隔离各个租户之间的独立数据空间，这里所说的物理隔离是指单个租户的独立数据可以存储在不同的数据库、数据库模式（Schema）、文件系统等。这允许在不同的模式（Schema）中使用相同的表名和对象而不会发生冲突。单个租户独立数据的创建、删除、执行、故障等与其他租户无关，在多处理器实例上，允许系统以多任务方式异步访问各个租户的独立空间，性能上不受影响。

依据这种设计思想建立的SaaS多租户架构代表了简单性和性能之间的理想折衷。

• 简单性：多租户架构可以部署在支持共享连接的多个数据库上，也可以仅部署在具有多SChema结构的一个数据库上。与简单模式相同，所有应用程序实例（WebApps）通过缓存（Redis）共享全局信息和认证信息。

• 性能：每个租户都有共用空间和独立空间。租户可以无缝的在共用数据区和独立数据区间切换执行业务、共享连接、缓存、内存。

多租户的设置、访问、权限

租户通过其主机名(即tenant.domain.com)进行标识。 此信息存储在公共数据表上。 无论何时发出请求，主机名都会用于匹配数据库中的租户。 如果存在匹配项，则搜索路径将更新为使用此租户的表。 因此，从现在开始，所有查询都将在租户的模式下进行。 例如，假设您在http://customer.example.com上有一个租户customer。 在customer.example.com上收到的任何请求都将自动使用customer的模式，并根据请求使租户可用。 如果找不到租户，则会引发404错误。这也意味着您应该为您的主域指定一个租户，通常使用公共模式。

• 共享的和特定于租户的应用

• 租户特定的应用

您的大多数应用程序可能是特定于租户的，也就是说，其数据不与任何其他租户共享。

• 共享应用

当应用程序的表位于公共模式中时，它被认为是共享的。共享某些应用很有意义。假设您有某种公共数据集，例如，一个包含统计数据的表。 您希望每个租户都能查询它。此应用程序通过始终将公共架构添加到搜索路径来启用共享应用程序，从而使这些应用程序也始终可用。