转载

ABP理论学习之多租户

返回总目录

本篇目录

什么是多租户
ABP中的多租户

什么是多租户

维基百科：“软件 多租户 是指一种软件架构，在这种软件架构中，软件的 一个实例 运行在服务器上并且为多个租户服务”。一个租户是一组共享该软件实例特定权限的用户。有了多租户架构，软件应用被设计成为每个租户提供一个 专用的实例包括该实例的数据的共享 ，还可以共享配置，用户管理，租户自己的功能和非功能属性。多租户和多实例架构相比，多租户分离了代表不同的租户操作的多个实例。

多租户用于创建 Saas（Software as-a service） 应用（云处理）。有几种类型的多租户：

多部署-多数据库

这实际上不是多租户。但是，如果我们为每个具有 分开数据库的 客户（租户）运行该应用的一个实例，那么我们可以在单个服务器上为 多个租户 提供服务。我们可以确定该应用的多个实例在相同的服务器环境不会相互冲突。

这个对于一个不是为多租户设计的 已存在应用 也是可能的。创建这么一个应用更容易，因为该应用不需要了解多租户。但这种方式存在安装，使用和维护问题。

单部署-多数据库

在这种情况下，我们可以在一个服务器上运行应用的 单个实例 。对于每个登录用户，我们从 master database 中检测该用户的租户，并获得该租户的数据库信息（ 连接字符串 ）。然后我们可以将连接字符串存储到 像session 一样的变量中，同时，使用这个 租户特定的 连接字符串执行所有的数据库操作。

某种程度上，这样的应用应该设计成多租户。但是大多数的应用都独立于多租户。这种方式也存在一些安装，使用和维护问题。我们应该为每个租户创建并维护一个 分离的数据库 。

单部署-单数据库

这是最 真实的多租户 架构：我们只将具有 单个数据库 应用的 单个实例 部署到 单个服务器 上。在（RDBMS）每个表中，都存在一个 TenantId （或相似）字段，该字段用于分离每个租户之间的数据。

这种方法安装和维护都很简单，但唯独创建这么一个应用很难，因为我们必须要阻止一个租户读取或写入其他租户的数据。我们可以为每个数据库的读取（select）操作添加一个 TenantId过滤器 。而且，我们可以在每次写入的时候检查一下该实体是否和 当前的租户 相关。这是乏味而易于出错的，但ABP通过使用 自动的数据过滤 帮助我们处理这个事情。

如果我们有很多具有大量数据的租户，那么这种方法可能会有性能问题。我们可以使用关系型数据库的表分割特征或者将租户按组分到不同的服务器上。

ABP中的多租户

ABP提供了创建 单部署，单数据库，多租户 架构的基础设施。

开启多租户

多租户默认是关闭的。我们可以在模块的PreInitialize方法中开启，如下所示：

Configuration.MultiTenancy.IsEnabled = true;

租主vs租户

首先，我们应该定义多租户系统中的两个条目：

租主（Host） :租主是单例的（只有一个租主）。租主会对创建和管理租户负责。因此，一个“ 租主用户 ”比所有的租户等级更高，并独立于所有租户，同时还能控制他们。
租户（Tenant） :租主的一个客户，具有自己的用户角色，权限，设置等。每个租户都可以完全独立于其他租户使用应用。一个多租户应用会有一个或多个租户。如果是一个CRM应用，那么不同的租户也有它们自己的账户，契约，产品和订单。因此，当我们说“**租户用户”的时候，意思就是一个租户拥有的用户。

Session

ABP定义了一个获取当前用户和租户 id的 IAbpSession 接口。该接口用于多租户获取当前的租户id。因此，它可以基于当前的租户id过滤数据。ABP中有以下规则：

如果UserId和TenantId都是null，那么当前的用户没有登录到系统。因此，我们可以不知道当前用户是否是一个租主用户还是一个租户用户。在这种情况下，用户不能访问授权的内容。
如果UserId不是null，TenantId是null，那么当前用户是一个租主用户。
如果UserId不是null，TenantId也不是null，那么当前用户是租户用户。

更多关于session的信息请看后面的Session一节。

数据过滤器

当从数据库中检索实体时，我们必须添加一个TenantId过滤器来只获得当前的租户实体。当你为实体实现了 IMustHaveTenant和IMayHaveTenant 两个接口之一时，ABP会自动地完成数据过滤。

IMustHaveTenant接口

该接口通过定义 TenantId 属性来区分不同租户的实体。一个实现了IMustHaveTenant的实体例子如下：

public class Product : Entity, IMustHaveTenant {     public int TenantId { get; set; }              public string Name { get; set; }          //...其他属性 }

这样，ABP知道这是一个特定租户的实体，并且会自动地将一个租户的实体从其他实体中分离出来。

IMayHaveTenant接口

我们可能需要在租户和租户之间共享一个 实体类型 。因此，一个实体可能会被一个租户或租主拥有。IMayHaveTenant接口也定义了 TenantId (类似于IMustHaveTenant)，但在这种情况下是 nullable 。实现了IMayHaveTenant的一个实体例子：

public class Role : Entity, IMayHaveTenant {     public int? TenantId { get; set; }              public string RoleName { get; set; }          //...其他属性 }

我们可能会使用相同的Role类来存储租主角色和租户角色。这种情况下，TenantId表明这是一个租户实体还是一个租主实体。null值表示这是一个租主实体， 非null 值表示这被一个租户拥有，该租户的Id是 TenantId 。

IMayHaveTenant不像IMustHaveTenant一样常用。比如，一个Product类可以不实现IMayHaveTenant接口，因为Product和实际的应用功能相关，和管理租户不相干。因此，要小心使用IMayHaveTenant接口，因为它更难维护租户和租主共享的代码。