## 1.5 ABP总体介绍 - 多租户
### 1.5.1 什么是多租户
维基百科:“软件多租户是指一个软件架构的实例软件运行在一个服务器上,但存在多个租户。租户是一组共享一个公共的用户访问特定权限的软件实例。多租户架构,软件应用程序旨在提供每个租户专用的实例包括数据、配置、用户管理、租户个体功能和非功能属性。多租户与多实例架构,独立的软件实例代表不同的租户”操作多租户一般用来创建SaaS(软件即服务)应用程序(云计算),下面有一些案例:
### 1.5.2 多个部署多个数据库
这实际上并不是多租户,如果为每个客户(租户)配置一个单独的数据库和应用程序的一个实例,即在单个服务器中部署但提供给多个客户(租户)使用,我们需要确保应用程序的多个实例不会因为系统相同的配置环境而发生冲突。
这种已有的设计方式也不是真正为多租户服务的,它的好处是更容易的创建,但是存在一些安装、使用和维护的问题。
### 1.5.3 单个部署多个数据库
使用这种方式,我们可以在服务器上运行应用程序的一个实例。我们有一个主数据库用来存储租户的数据(例如:租户名称以及子域名)以及每个租户的单个数据库。一旦我们识别出当前租户(例如:从子域名或者用户登录的信息来判定),那么我们可以切换到当前租户的数据库来执行操作。
以这种方式设计出来的应用程序,在某种程度上可以被看做多租户。但是大多数的应用仍然依赖于多租户。
我们应该为每个租户创建和维护它们自己单独的数据库,这包括数据迁移。如果我们有很多的客户以及与之相应的数据库,在更新应用程序的时候,那会花费太多的时间在数据库架构的迁移上。当然这样做,我们为租户分离出了数据库,我们可以为每个租户备份它们自己的数据库。如果租户需要的话,我们可以将租户的数据库迁移到更强大的服务器上。
### 1.5.4 单个部署单个数据库
这是真正的多租户构架,我们只在服务器上部署应用程序的单一实例且只有一个数据库。在各表中使用TenantId来隔离其它租户的信息。
这样的好处是易于安装和维护,但创建这样的一个应用程序比较困难。因为,需要防止租户读写其它租户的信息。在用户读取数据时候可以添加TenantId过滤器过滤数据,同样,系统会检测用户的写入操作。这是很繁琐的,而且也容易出错。ABP可以帮助我们自动数据过滤。
如果我们有很多租户并且数据量巨大,那么这种实现方式将会导致一些性能问题。我们可以使用表分区或者数据库的其它功能来克服这些问题。
### 1.5.5 单部署混合数据库
通常我们可能想存储租户到一个单独的数据库中,但是也可能想为租户创建分离的数据库。例如:我们可以为那些数据量巨大的租户创建单独的数据库,但是其它租户仍使用同一个数据库。
### 1.5.6 多部署-单/多/混合数据库
最后,为了达到更好的性能,高可用性以及伸缩性;我们可能想要部署我们的应用到多个服务器上。这些都是依赖于数据库的方式。
### 1.5.7 ABP中的多租户
ABP可以工作于所有上面所描述的场景。
#### 1. 开启多租户
默认多租户是被禁用的,我们需要在模块的 **PreInitialize** 方法中开启它,如下所示:
```csharp
Configuration.MultiTenancy.IsEnabled = true;
```
#### 2. Host VS 租户
首先,我们先定义两个多租户系统中的术语:
+ 租户:客户有它自己的用户,角色,权限,设置…并使用应用程序与其他租户完全隔离。多租户应用程序将有一个或多个租户。如果这是一个CRM应用程序,不同的租户也他们自己的帐户、联系人、产品和订单。所以,当我们说一个租户的用户,我们的意思是用户拥有的租户。
+ Host: Host是单例的(只有唯一一个Host).Host负责创建和管理租户。所以Host用户独立与租户且可以控制租户。
#### 3. Session
ABP定义IAbpSession接口来获取当前用户和租户id。这个接口中使用多租户当前租户的id。因此,它可以基于当前租户的id过滤数据。
这里有一些规则:
+ 如果两个用户id和TenantId是null,那么当前用户没有登录到系统中。所以,我们不知道这是一个主机用户或租户的用户。在这种情况下,用户不能访问授权的内容。
+ 用户id(如果不为空,TenantId为空的,然后我们可以知道当前用户是一个主机用户。
+ 用户id(如果不为空,TenantId也不为空,我们可以知道当前用户是一个租户的用户。
有关更多的Session内容可查看:[Session](225828)
#### 4. 数据过滤
当我们从数据库检索实体,我们必须添加一个TenantId过滤当前的租户实体。当你实现了接口:IMustHaveTenant或IMayHaveTenant中的一个时,ABP将自动完成数据过滤。
##### IMustHaveTenant Interface
这个接口通过TenantId属性来区分不同的租户的实体。示例:
``` csharp
public class Product : Entity, IMustHaveTenant
{
public int TenantId { get; set; }
public string Name { get; set; }
//...其它属性
}
```
因此,ABP能发现这是一个与租户相关的实体,并自动隔离其它租户的实体。
##### IMayHaveTenant interface
我们可能需要在Host和租户之间共享实体类型。一个实体可能属于租户或Host,IMayHaveTenant接口还定义了TenantId(类似于IMustHaveTenant),但在这种情况下可以为空。示例如下:
```csharp
public class Role : Entity, IMayHaveTenant
{
public int? TenantId { get; set; }
public string RoleName { get; set; }
//...其它属性
}
```
我们可以使用相同的角色类存储主机角色和租户的角色。在这种情况下,TenantId属性会告诉我们这是一个Host实体还是一个租户实体。**null** 值意味着这是一个 **Host实体** ,一个 **非空值** 意味着这被一个租户拥有,该租户的Id是 **TenantId** 。
##### 备注
IMayHaveTenant不像IMustHaveTenant一样常用。比如,一个Product类可以不实现IMayHaveTenant接口,因为Product和实际的应用功能相关,和管理租户不相干。因此,要小心使用IMayHaveTenant接口,因为它更难维护租户和租主共享的代码。
当你定义一个实体类型实现了 IMustHaveTenant 或者 IMayHaveTenant 接口的时候;那么在创建一个新实体的时候,你就需要设置 **TenantId** 的值,(ABP会尝试把当前AbpSession的TenantId的值设置给它,但是在某些情况下这是不可能的,尤其是实现了IMayHaveTenant接口的实体)。在大多数时候,这是唯一一个地方你需要处理TenantI的地方,但是在其它对租户数据过滤的时候,你不需要在写Linq的where条件语句的时候明确指出TenantId,因为它会自动的实现过滤。
##### 在Host和租户之间的切换
当在多租户应用数据库上工作的时候,我们应该知道当前的租。默认获取租户ID的方式是从 IAbpSession 上获取的。我们可以改变这个行为并且切换到其它租户的数据库上。例如:
```csharp
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方法,它会从Session中取得租户Id,如同之前所述。
这里有一些关于最佳实践的建议:
+ 使用 **SetTenantId(null)** 切换到Host
+ 如果没有特别的原因,你应该像上面示例所展示的一样,在using语句块中使用SetTenantId方法。因为它会在using语句块后且在 GetProducts 方法工作完成之前,自动的还原TenantId (也就是说using语句块运行完后,TenantId是从Session中获取的不会是来自于GetProducts的传入参数)
+ 如果需要你可以嵌套使用SetTenantId方法
+ 因为 **_unitOfWorkManager.Current** 仅在工作单元中有效,请确保你的代码是在工作单元中运行
- 文章&教程
- Abp
- 1.1ABP总体介绍-入门介绍
- 1.2ABP总体介绍-多层架构体系
- 1.3ABP总体介绍-模块系统
- 1.4ABP总体介绍-启动配置
- 1.5ABP总体介绍-多租户
- 1.6ABP总体介绍-集成OWIN
- 2.1ABP公共结构-依赖注入
- 2.2ABP公共结构-会话管理
- 2.3ABP公共结构-缓存管理
- 2.4ABP公共结构-日志管理
- 2.5ABP公共结构-设置管理
- 2.6ABP公共结构-时区设置
- 3.1ABP领域层-实体
- 3.2ABP领域层-值对象
- 3.3ABP领域层-仓储
- 3.4ABP领域层-领域服务
- 3.5ABP领域层-工作单元
- 3.6ABP领域层-领域事件
- 3.7ABP领域层-数据过滤器
- 4.1ABP应用层-应用服务
- 4.2ABP应用层-数据传输对象
- 4.3ABP应用层-数据传输对象验证
- 4.4ABP应用层-权限认证
- 4.5ABP应用层-功能管理
- 4.6ABP应用层-审计日志
- 5.1ABP分布式服务-ASP.NET WebApi
- 5.2ABP分布式服务-动态WebApi层
- 5.3ABP分布式服务-集成OData
- 5.4ABP分布式服务-集成SwaggerUI
- 6.1ABP表现层-Mvc控制器
- 6.2ABP表现层-Mvc视图
- 6.3ABP表现层-本地化
- 6.4ABP表现层-导航栏
- 6.5ABP表现层-异常处理
- 6.6.2-AJAX
- 6.6.3-Notification
- 6.6.4-Message
- 6.6.5-UIBlockBusy
- 6.6.6-EventBus
- 6.6.7-Logging
- 6.6.8-OtherUtilities
- 6.6ABP表现层-JavascriptAPI
- 6.7ABP表现层-嵌入资源文件
- 6.8ASP.NET-Core
- 6.9CSRF和XSRF保护
- 7.1ABP后台服务-后台作业和工人
- 7.2ABP后台服务-集成Hangfire
- 8.1ABP实时服务-通知系统
- 8.2ABP实时服务-集成SignalR
- 9.1ABP基础设施层-集成Entity Framework
- 9.2ABP基础设施层-集成NHibernate
- 9.3ABP基础设施层-集成Entity Framework Core
- abp合并版160929
- md文档排版规范
- AbpZero
- 1.1ABPZero-概述
- 1.2ABPZero-安装
- 1.3ABPZero-启动模板
- 1.4ABPZero-启动模板Core
- 2.1ABPZero-多租户管理
- 2.2ABPZero-版本管理
- 2.4ABPZero-组织单位管理