<<ABP文檔 - 框架>> 1.5 多租戶

文檔目錄

本節內容：

• 什麼是多租戶
  • 多部署 - 多資料庫
  • 單部署 - 多資料庫
  • 單部署 - 單資料庫
  • 單部署 - 混資料庫
  • 多部署 - 單/多/混 資料庫
• 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僅在同一工作單元內可用，所以確保你的代碼是運行在同一個工作單元內。