本节内容：
- 什么是多租户
- 多部署 - 多数据库
- 单部署 - 多数据库
- 单部署 - 单数据库
- 单部署 - 混数据库
- 多部署 - 单/多/混 数据库
- ABP中的多租户
- 启用多租户
- 宿主与租户
- 会话
- 数据过滤
- IMustHaveTenant 接口
- IMayHaveTenant 接口
- 补充提醒
- 在宿主与租户间切换
什么是多租户
维基百科：“软件多租户是一个软件架构，软件只有一个实例运行在服务器，并服务于多个租户。一个租户包含一组用户，他们拥有指定权限，共同访问一个软件实例。一个多租户架构，应用程序为每个租户提供一个专属于他们的数据、配置、用户管理、租户特有的功能和属性。多租户架构而多实例框架抽象而成，多实例架构是把每个实例看成一个租户。“
多租户通常用来创建Saas（软件作为服务）应用（云计算）。多租户有多种架构：
多部署 - 多数据库
这种实际上不算多租户，但是，如果我们为每个客户（租户）运行应用的一个实例，并使用一个独立的数据库，那么我们就可以在一台服务器上为多个租户服务，我们只要确保应用的多个实例不要在一个服务器的环境下互相冲突就行。
为一个不是为多租户设计，但已经在运行的应用，提供了可能性。这种方式虽然使得创建一个不考虑多租户的应用相对容易，但在安装、使用和维护方面有些问题。
单部署 - 多数据库
用这种方式，我们在一个服务器上运行应用的单一实例，我们有一个主（宿主）数据库存储租户元数据（像租户名和子域），并为每个租户维护一个隔离的数据库。我们一旦识别当前租户（例如：从子域或从一个用户登录窗体），就切换到该租户的数据库里执行操作。
用这种方式，我们应该在设计应用时，在某些层面上设计成多租户，但应用的大部分还是不依赖于多租户。
我们应该为每个租户创建并维护一个隔离的数据库，包括数据迁移。如果我们有多租户就需要维护它们专有的数据库，在应用更新时，可能就需要花很长的时间进行数据库结构迁移。由于我们有租户的隔离的数据库，所以我们可以单独地备份各自的数据库，同样在租户要求下，我们也可以移动租户数据库到一个更强大的服务器。
单部署 - 单数据库
这是最纯粹的多租户架构：我们只在一台服务器上部署应用的单个实例和单个数据库。我们在每个表（关系型数据库）里用一个TenantId（租户Id或类似的）字段来区分隔离每个租户数据。
这种方式易于安装和维护，但难于创建这种应用，因为我们必须防止一个租户读或写其它租户数据。我们得为每次的数据库读取（select）操作添加TenantId来过滤。同样，我们也在每次写数据库时进行检查当前实体是否与当前租户相关，这就是乏味和易犯错的地方。但ABP自动使用数据过滤技术帮我们解决这些问题。
这种方式在有很多租户和大数据量的情况下，可能带来性能问题，我们可以使用表分区或其它数据库特性来解决这个问题。
单部署 - 混数据库
我们可能想存储租户数据到一个数据库，但想为有需要的租户创建单独的数据库。例如，我们可以存储租户的大数据到各自的数据库，但其它的都保存到另一数据库。
多部署 - 单/多/混 数据库
最后，我们可能想部署我们的应用到多个服务器（像分布式服务器集群）获得更好地性能、实用性和扩展性。这是一种依赖于数据库的方式。
ABP中的多租户
ABP可用于上述所描述的场景。
启用多租户
默认情况多租户是禁用的，我们可以在我们模块的PreInitialize（预初始化）里启用它，如下：
Configuration.MultiTenancy.IsEnabled = true;
宿主与租户
首先我们要在多租户系统里定义两个术语：
- Tenant（租户）：一个客户，拥有多个用户、角色、许可、设置等，并要单独地使用这个应用。一个多租户应用可能有多个租户，每个租户有它自己的帐户、联系人、产品及其它。所以当我们说一个“Tenant user（租户用户）”，表示一个租户下的一个用户。
- Host（宿主）：宿主是单例的（就一个宿主），这个宿主负责创建和管理租户，所以“Host user（宿主用户）”拥有更高级别，不依赖于租户，并能控制租户。
会话（Session）
ABP定义了IAbpSession接口，用来获取user（用户）和tenant ids(租户Id)。该接口在多租户系统中默认情况下获取当前租户Id，因此它能基于租户Id过滤数据。有如下规则：
- 如果用户Id和租户Id都为null，当前用户尚未登录到系统，所以我们不知道它是宿主用户还是租户用户。这种情况下，用户不能访问需要授权的内容。
- 如果用户Id不为null，租户Id为null，我们就可以知道当前用户为宿主用户。
- 如果用户id不为null，租户Id也不为null，我们就可以知道当前用户为租户用户。
查看会话文档获取更多相关信息。
数据过滤
在多租户单数据库方式里，我们必须添加一个TenantId（租户Id）过滤，从数据库中只获取当前租户的实体。当你的实体实现IMustHaveTenant和ImayHaveTenant两个接口中的一个，ABP就会自动做到这点。
IMustHaveTenant 接口
该接口通过定义TenantId属性为不同租户区分实体。如下所示，一个实体实现IMustHaveTenant：
public class Product : Entity, IMustHaveTenant
{
public int TenantId { get; set; }
public string Name { get; set; }
//...other properties
}
因此ABP知道这是一个特定租户的实体并自动与其它租户的实体分离。
IMayHaveTenant 接口
我们有时需要在宿主与租户之间共享一个实体，所以一个实体可能是宿主的或租户的。IMayHaveTenant接口同样定义了TenantId属性（类似于IMustHaveTenant），但它是nullable（可空的）。如下所示，一个实体实现IMayHaveTenant：
public class Role : Entity, IMayHaveTenant
{
public int? TenantId { get; set; }
public string RoleName { get; set; }
//...other properties
}
我们可以使用两样的role类来存储宿主角色和租户角色，在这种情况下，靠TenantId属性来区分是宿主实体还是租户实体。如果为null表示这是一个宿主实体，否则它就是一个租户实体，它的值就是租户Id。
补充提醒：
IMayHaveTenant没有IMustHaveTenant那么通用。例如：一个Product（产品）类不能是IMayHaveTenant，因为它跟应用功能切实相关的，而与租户的管理无关。所以在使用IMayHaveTenant接口时要格外小心，毕竟维护共享于宿主与租户的代码比较难。
当你定义一个实体类型为IMustHaveTenant或IMayHaveTenant后，在创建一个新实体时应该特意支设置TenantId（尽管ABP会尝试把当前TenantId赋给它，但某些情况下不会成功，尤其是使用IMayHaveTenant的实体）。大部分情况，这个TenantId属性是唯一需要处理的点，当你写LINQ时，不需要显式地在where条件里写TenantId过滤，因为它会自动地被过滤。
在宿主与租户间切换
在多租户应用数据库上，我们应该知道当前租户，默认情况下，可以从IAbpSession中获取（如之前所述）。但我们可以改变这种行为，切换到其它租户的数据库上，例如：
public class ProductService : ITransientDependency
{
private readonly IRepository<Product> _productRepository;
private readonly IUnitOfWorkManager _unitOfWorkManager;
public ProductService(IRepository<Product> productRepository, IUnitOfWorkManager unitOfWorkManager)
{
_productRepository = productRepository;
_unitOfWorkManager = unitOfWorkManager;
}
[UnitOfWork]
public virtual List<Product> GetProducts(int tenantId)
{
using (_unitOfWorkManager.Current.SetTenantId(tenantId))
{
return _productRepository.GetAllList();
}
}
}
SetTenantId确保我们工作于给定的租户的数据，获取方式依数据库而定：
- 如果给定的租户有特定的数据库，它切换到这个数据库，从中获取产品。
- 如果给定的租户没有特定的数据库（例如：单数据库方式），它自动添加TenantId过滤到查询里，只获取给定租户的产品。
如果我们不使用SetTenantId，如前面所说，将从会话中获取TenantId。这里有些提醒和最佳实践：
- 使用SetTenantId(null)可切换到宿主。
- 如果没有特殊情况，要像示例那样，在using块里使用SetTenantId，因为它会在块后面自动还原TenantId的值，并且调用GetProducts方法的代码也会像调用前那样工作。
- 如果有需要，你可以块里嵌套使用SetTenantId
- 由于_unitOfWorkManger.Current仅在同一工作单元内可用，所以确保你的代码是运行在同一个工作单元内。