文檔目錄
本節內容：
什麼是多租戶
維基百科：“軟件多租戶是一個軟件架構，軟件只有一個實例運行在服務器，並服務於多個租戶。一個租戶包含一組用戶，他們擁有指定權限，共同訪問一個軟件實例。一個多租戶架構，應用程序為每個租戶提供一個專屬於他們的數據、配置、用戶管理、租戶特有的功能和屬性。多租戶架構而多實例框架抽象而成，多實例架構是把每個實例看成一個租戶。“
多租戶通常用來創建Saas（軟件作為服務）應用（雲計算）。多租戶有多種架構：
多部署 - 多數據庫
這種實際上不算多租戶，但是，如果我們為每個客戶（租戶）運行應用的一個實例，並使用一個獨立的數據庫，那麼我們就可以在一台服務器上為多個租戶服務，我們只要確保應用的多個實例不要在一個服務器的環境下互相沖突就行。
為一個不是為多租戶設計，但已經在運行的應用，提供了可能性。這種方式雖然使得創建一個不考慮多租戶的應用相對容易，但在安裝、使用和維護方面有些問題。
單部署 - 多數據庫
用這種方式，我們在一個服務器上運行應用的單一實例，我們有一個主（宿主）數據庫存儲租戶元數據（像租戶名和子域），並為每個租戶維護一個隔離的數據庫。我們一旦識別當前租戶（例如：從子域或從一個用戶登錄窗體），就切換到該租戶的數據庫裡執行操作。
用這種方式，我們應該在設計應用時，在某些層面上設計成多租戶，但應用的大部分還是不依賴於多租戶。
我們應該為每個租戶創建並維護一個隔離的數據庫，包括數據遷移。如果我們有多租戶就需要維護它們專有的數據庫，在應用更新時，可能就需要花很長的時間進行數據庫結構遷移。由於我們有租戶的隔離的數據庫，所以我們可以單獨地備份各自的數據庫，同樣在租戶要求下，我們也可以移動租戶數據庫到一個更強大的服務器。
單部署 - 單數據庫
這是最純粹的多租戶架構：我們只在一台服務器上部署應用的單個實例和單個數據庫。我們在每個表（關系型數據庫）裡用一個TenantId（租戶Id或類似的）字段來區分隔離每個租戶數據。
這種方式易於安裝和維護，但難於創建這種應用，因為我們必須防止一個租戶讀或寫其它租戶數據。我們得為每次的數據庫讀取（select）操作添加TenantId來過濾。同樣，我們也在每次寫數據庫時進行檢查當前實體是否與當前租戶相關，這就是乏味和易犯錯的地方。但ABP自動使用數據過濾技術幫我們解決這些問題。
這種方式在有很多租戶和大數據量的情況下，可能帶來性能問題，我們可以使用表分區或其它數據庫特性來解決這個問題。
單部署 - 混數據庫
我們可能想存儲租戶數據到一個數據庫，但想為有需要的租戶創建單獨的數據庫。例如，我們可以存儲租戶的大數據到各自的數據庫，但其它的都保存到另一數據庫。
多部署 - 單/多/混 數據庫
最後，我們可能想部署我們的應用到多個服務器（像分布式服務器集群）獲得更好地性能、實用性和擴展性。這是一種依賴於數據庫的方式。
ABP中的多租戶
ABP可用於上述所描述的場景。
啟用多租戶
默認情況多租戶是禁用的，我們可以在我們模塊的PreInitialize（預初始化）裡啟用它，如下：
Configuration.MultiTenancy.IsEnabled = true;
宿主與租戶
首先我們要在多租戶系統裡定義兩個術語：
會話（Session）
ABP定義了IAbpSession接口，用來獲取user（用戶）和tenant ids(租戶Id)。該接口在多租戶系統中默認情況下獲取當前租戶Id，因此它能基於租戶Id過濾數據。有如下規則：
查看會話文檔獲取更多相關信息。
數據過濾
在多租戶單數據庫方式裡，我們必須添加一個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確保我們工作於給定的租戶的數據，獲取方式依數據庫而定：
如果我們不使用SetTenantId，如前面所說，將從會話中獲取TenantId。這裡有些提醒和最佳實踐：
