ABP、SaaS与多租户

ABP

ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点，它旨在成为一个通用的WEB应用程序框架和项目模板。ASP.NET Boilerplate 基于DDD的经典分层架构思想，实现了众多DDD的概念（但没有实现所有DDD的概念）。ABP不仅架构设计和代码写的好，文档也很全面详实（这是一个开发框架被技术选型的基础）。

多租户

多租户用于创建Saas（Software as-a service）应用（云处理）。

维基百科对多租户的解释是：软件多租户是指一种软件架构，在这种软件架构中，软件的一个实例运行在服务器上并且为多个租户服务。

一个租户是一组共享该软件实例特定权限的用户。有了多租户架构，软件应用被设计成为每个租户提供一个专用的实例包括该实例的数据的共享，还可以共享配置，用户管理，租户自己的功能和非功能属性。多租户和多实例架构相比，多租户分离了代表不同的租户操作的多个实例。

多租户一般涉及如下几种场景：

• 多部署-多数据库：即针对每个租户独立部署一套应用程序实例，每个实例对应一个数据库。这种不算是真正的多租户，不过对于在设计时没有考虑多租户的遗留系统采用这种部署方式不失为一种折中办法。
• 单部署-多数据库：只有唯一的一个应用程序实例，每个租户分别连接不同的数据库。
• 单部署-单数据库：应用程序实例和数据库都是一个。通过在需要隔离数据的数据表中加入一个类似TanantId或EnterpriseId来区分。如果我们有很多具有大量数据的租户，那么这种方法可能会有性能问题。我们可以使用关系型数据库的表分割特征或者将租户按组分到不同的服务器上。
• 单部署-混搭数据库：应用程序实例一个，但是数据库根据情况，可以是单个或者多个。比如免费用户放到一个数据库中，高级用户分别有自己的数据库。
• 集群部署-单/多/混搭数据库：应用程序的逻辑实例还是一个（只是为了高可用和性能部署为一个集群），然后对应的数据库可以是单个、多个和混搭。

另外，除了针对租户的数据库以外，可能还需要一个全局的数据库（称之为主机数据库）来保存全局范围的配置数据。在单数据库情况下，主机数据可能就和租户数据放在一起（甚至同一个数据表中）。

ABP中的多租户

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

从零搭建单部署-单数据库的多租户架构比较麻烦，因为我们必须要阻止一个租户读取或写入其他租户的数据。我们可以为每个数据库的读取（select）操作添加一个TenantId过滤器。而且，我们可以在每次写入的时候检查一下该实体是否和当前的租户相关。这是乏味而易于出错的，但ABP通过使用自动的数据过滤帮助我们处理这个事情。

租主与租户

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

Session

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

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

数据过滤器

当从数据库中检索实体时，我们必须添加一个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接口，因为它更难维护租户和租主共享的代码。

保存实体

一个租户用户不应该创建或编辑其他租户的实体。如果相关的数据过滤器开启了，那么ABP会检查该实体相对于数据库的改变。

ABP对多租户的支持

在模块的PreInitialize方法中开启多租户模式

Configuration.MultiTenancy.IsEnabled = true;

ABP中内置了处理TenantId的机制（通过接口IMustHaveTenant或IMayHaveTenant来实现）。实体实现了IMustHaveTenant接口，会包含一个不能为空的TenantId属性，即意味着其中的数据库需要基于TenantId来进行隔离。实现了IMayHaveTenant接口，会包含一个能为空的TenantId属性，在TenantId为空的时候代表数据属于主机范围的，不为空的时候表示数据基于租户来隔离。

而ABP通过一个特殊封装的IAbpSession来给使用者提供当前TenantId的获取，如果是主机用户登录系统，那么TenantId就是为空的，否则就是登录用户所在租户的Id。

ABP在多租户下读取数据

ABP并非只是简单的给你的实体类添加一个TenantId属性，而是通过识别IMustHaveTenant或IMayHaveTenant接口，使用数据过滤机制（根据底层所用ORM不同有不同的实现方式）自动在你读取数据的时候，基于当前AbpSession中的TenantId来过滤数据。也就是说，你查询读取数据的时候，写“where item.TenantId == AbpSession.TenantId” 这样的代码是毫无必要的。

需要注意的是，如果实体实现的是IMustHaveTenant接口，且AbpSession.TenantId为null的时候（即主机用户），获取到的数据是所有租户的，除非你自己显式进行过滤。而在IMayHaveTenant情况下，AbpSession.TenantId为null获取到的是主机用户的数据。

ABP在多租户下写入数据

在多租户的情形下，写入数据也通过拦截机制（比如重写DbContext的SaveChanges方法），可以自动为你的实体设置TenantId属性，不管你用的是IMustHaveTenant还是IMayHaveTenant。虽然官方文档是推荐在创建实体的时候，总是显示设置TenantId的，尤其在使用IMayHaveTenant的时候（这也是abp使用者唯一需要关系这个属性的地方）。但是，就我个人的看法而言，利用框架的原因就是为了让编码简单，所以我还是倾向于建议大家不用显式设置TenantId。

参考资料：ABP多租户官方文档