如何自行實現一個多租戶系統註意：前情概要描述的文字比較多，說的是我的思考過程，不感興趣的可以直接到跳到 “解析租戶信息” 一節。現如今框架滿天飛的環境下，好像很少機會需要自己來實現一個模塊。畢竟這樣能節省很多的開發時間，提高效率。這就是框架的好處，也是我們使用框架的直接原因。情況總有例外，假 ...

如何自行實現一個多租戶系統

註意：前情概要描述的文字比較多，說的是我的思考過程，不感興趣的可以直接到跳到 “解析租戶信息” 一節。

現如今框架滿天飛的環境下，好像很少機會需要自己來實現一個模塊。畢竟這樣能節省很多的開發時間，提高效率。

這就是框架的好處，也是我們使用框架的直接原因。

情況總有例外，假設剛好我們公司沒有用到框架，用的就是 .netcore 平臺新建項目，直接開乾一把唆。由於前期工作沒有考慮周全，現在發現公司新建的平臺項目的業務數據越來越大，提供給用戶的數量越來越多。但是這些不同的用戶的數據肯定不能互相干擾。

舉個例子說明，例如我舉個跟我公司接近的一種情況，公司再搭建數據平臺，來給不同學校提供資料。並且我們的數據平臺要記錄合作學校對應的學生和老師。前面有假設提到公司前期考慮不周，我們把所有的學校放在 school 表中，所有學生放在 student 表中。所有老師放在 teacher 表中。這樣當公司系統在給他們（用戶）提供數據的時候，是不是每次都要判斷當前用戶在哪個學校，然後再把對應的學校資料推送給他們。不僅如此，對數據敏感的增刪改操作對這種混在一起數據要各位小心。一不小心，可能就會發生誤刪其他學校的信息。

為了有效的解決這個問題，我們第一要做的就是要將數據分開管理，彼此互不幹擾。這是我們要實現的最終目的。

想要的效果有了，現在的問題是能不能實現，該如何實現，怎麼實現才算好。

我們做事情的目的就是解決問題，在前面我們分析了我們要把數據在一個系統中隔離。那麼我們自然能想到的就是以學校為領域劃分為不同的庫。這樣我們在系統運行的時候就能做到在用戶選擇對應的學校登陸系統時，就只能訪問這個學校的所有信息了。

到這裡，我們就很清晰了，如果我們平時多看多聽到別人談論新的知識點或框架時，我們就會知道對於這種情況，“多租戶”就是為了這種情況而誕生的。

既然要做 “多租戶” 系統，並且團隊之間沒有使用市面上的多租戶框架。那麼我們就得自己實現一個了。那麼要做的第一件就是要瞭解 “多租戶” 的概念。正所謂知己知彼，方能戰無不勝。

什麼是多租戶

我們來看下維基百科對多租戶的定義是什麼（以下是概述）

多租戶軟體架構就是在同一個系統實例上運行不同用戶，能做到應用程式共用，服務自治，並且還能做到數據互相隔離的軟體架構思想。一個租戶就相當於一組用戶（比如針對學校來說，一個學校就是一個租戶，這個租戶下有學生，老師作為用戶（一組用戶））。

現在我們總結一下我們要做什麼？

我們要實現：

相同的應用程式 app 下
解析出登陸系統的（當前用戶）是屬於哪一個租戶（對應到例子就是學校）。
根據解析出來的租戶信息，來訪問對應的資料庫信息。

現在我們就來實現上面說的步驟。第一步不用想，肯定要得一個 app 下。

解析租戶信息

現在我們要設計如何才能讓系統檢測到當前用戶的租戶信息。

現階段我們能想到的解析方式有三種：

功能變數名稱：例如 tenant1.example.com，tenant2.example.com
URL：例如 www.example.com/tenant1/，www.example.com/tenant2
header：例如 [x-header: 'tenant1']，[x-header: 'tenant2']

一下子有這麼多解決方式，是不是自信心起來了，有木有。

具體如何用代碼實現呢？首先要定義一個 “租戶” 的信息體，為了方便表述我這裡用的是類（當然也可以用介面）

public class Tenant {
    public string Identifier { get; set;}
  public string Id { get; set;}
}

只要繼承了這個租戶類，就表示擁有了這個租戶信息。有了租戶之後，我們緊接著要做的就是解析了。因為前面有討論我們解析方式有三種，這裡我主要討論第一種的實現方案。正是因為有多種可能，解析方式對於架構來說是不穩定的，所以我們要封裝變化來抽象畫。我們先定一個解析租戶介面類，然後提供一個實現類具體以功能變數名稱方式解析，這樣封裝就達到對修改封閉，新增開放（OCP）的目的了。例如用戶可以自行繼承介面用 URL 方式解析租戶信息。

public interface ITenantResolver {
    Task<string> GetTenantIdentifierAsync();
}

public class DomainTenantResolver : ITenantResolver {
  private readonly IHttpContextAccessor _accessor;
  public DomainTenantResolver(IHttpContextAccessor accessor) {
    _accessor = accessor;
  }
  // 這裡就解析道了具體的功能變數名稱了，從而就能得知當前租戶
  public async Task<string> GetTenantIdentifierAsync() {
    return await Task.FromResult(_accessor.HttpContext.Request.Host.Host);
  }
}

接著我們拿到租戶標識符，要幹嘛呢？自然是要存起來的，好讓系統很方便的獲取當前用戶的租戶信息。

存儲租戶信息

關於存儲功能，同樣我們選擇抽象出來一個 ITenantStore 介面。為什麼要抽象出來，作為一個基礎功能架構設計。我們就應該考慮這個功能的解決方案是否是穩定的。明顯，對於存儲來說，方式太多了。所以作為系統，要提供一個基本實現的同時還要供開發者方便選擇其他方式。

public interface ITenantStore {
    Task<T> GetTenantAsync(string identifier);
}

關於存儲，其實我們可以選擇將租戶信息放入記憶體中，也可以選擇放入配置文件，當然你選擇將租戶信息放入資料庫也是沒問題的。

現在的最佳實踐是將一些敏感信息，比如每個租戶對應的鏈接字元串都是以 Option 配置文件方式存儲的。利用 .netcore 內置 DI 做到即拿即用。

這裡為了簡便，我選擇用硬編碼的方式存儲租戶信息

public class InMemoryTenantStore: ITenantStore {
  private Tenant[] tenantSource = new[] {
            new Tenant{ Id = "4da254ff-2c02-488d-b860-cb3b6363c19a", Identifier = "localhost" }
    };
    public async Task<T> GetTenantAsync(string identifier) {
    var tenant = tenantSource.FirstOrDefault(p => p.Identifier == identifier);
        return await Task.FromResult(tenant);
    }
}

好了，現在我們租戶信息有了，解析器也提供了，存儲服務也決定了。那麼接下來就只剩下什麼了？

進入管道捕獲源頭

剩下的就是找到請求的源頭，很顯然，.netcore 優良的設計，我們可以很方便的將上述我們準備的服務安排至管道中。那就是註冊服務（AddXXXService）和中間件（UseXXX）。

所以我們這一步要做的就是

註冊解析租戶信息服務
註冊中間件，好讓每一次請求發起時截獲信息將用戶的租戶信息存至這個請求（HttpContext）裡面，好讓系統隨時訪問當前用戶租戶信息。

註冊服務類

這個太簡單了，.netcore 的源代碼給了我們很好的範例

public static class ServiceCollectionExtensions {
    public static AddMultiTenancy<T>(this IServiceColletion services, Action<IServiceCollection> registerAction) where T : Tenant {
        service.TryAddSingleton<IHttpContextAccessor,HttpContextAccessotr>();  // 這一步很重要
        registerAction?.Invoke(services);
    }
}

調用：

// Startup.cs ConfigureServices

services.AddMultiTenancy<Tenant>(s => {
    // 註冊解析類
    s.AddScoped(typeof(ITenantResolver), typeof(DomainTenantResolver));
    // 註冊存儲
    s.AddScoped(typeof(ITenantStore), typeof(InMemoryStore));
})

這樣我們就能在系統中比如控制器，註入這兩個類來完成對當前租戶信息的訪問。

註冊服務解決了，然後是中間件

註冊中間件

中間件所乾的事，很簡單，就是捕獲進來管道的請求上下文，然後解析得出租戶信息，然後把對應的租戶信息放入請求上下文中。

class MultiTenantMiddleware<T> where T : Tenant {
    private readonly RequestDelegate _next;

  public TenantMiddleware(RequestDelegate next)
  {
      _next = next;
  }

  public async Task InvokeAsync(HttpContext context)
  {
      if (!context.Items.ContainsKey("localhost"))
      {
          var tenantService = context.RequestServices.GetService(typeof(TenantAppService<T>)) as TenantAppService<T>;
          // 這裡也可以放到其他地方，比如 context.User.Cliams 中
          context.Items.Add("localhost", await tenantService.GetTenantAsync());
      }

      if (_next != null)
          await _next(context);
  }
}

這樣我們就實現了整個請求對當前租戶操作過程了。所以本文就結束了。

不好意思，開個玩笑。還沒結束，其實上面是我第一版的寫法。不知道大家有沒有發現，我這樣寫其實是有 “問題” 的。大毛病沒有，就是對開發者不友好。

首先，在 ConfigureServices 方法里的註冊操作，我的 AddMultiTenancy 方法不純粹。這是我當時寫這個 demo 時候感覺特別明顯的。因為起初我的方法簽名是不帶回調函數 action 的。

public static IServiceCollection AddMultiTenancy<T>(this IServiceColletion services) where T : Tenant {
  services.TryAddSingleton<IHttpContextAccessor,HttpContextAccessotr>();  // 這一步很重要
  services.Add(typeof(ITenantResolver), typeof(ImlITenantResolver), LifetimeScope);
  services.Add(typeof(ITenantStore), typeof(ImlITenantStore), LifetimeScope);
  return services;
}

但是在註冊租戶解析類和存儲類時，發現沒有實現類型和生命周期做參數，根本無法註冊。如果把兩個參數當成方法簽名，那不僅使這個方法變得醜陋，還固話了這個方法的使用。

所以最後我改成了上面用回調的方式，暴露給開發者自己去註冊。所以這就要求開發者必須要清楚要註冊那些內容。

所以後來一次偶然的機會看到相關的資料，告訴我其實可以藉助 Program.cs 中的 Builder 模式改善代碼，可以讓代碼結構更加表義化。第二版如下

public static class ServiceCollectionExtensions {
    public static TenantBuilder<T> AddMultiTenancy<T>(this IServiceColletion services) where T : Tenant {
        return new TenantBuilder<T>(services);
    }
}

public class TenantBuilder<T> where T : Tenant {
    private readonly IServiceCollection _services;
    public TenantBuilder(IServiceCollection services) {
        _services = services;
    }
    
    public TenantBuilder<T> WithTenantResolver<TIml>(ServiceLifetime lifttime = ServiceLifetime.Transient) where TIml : ITenantResolver {
        _services.TryAddSingleton<IHttpContextAccessor,HttpContextAccessotr>();  // 這一步很重要
        _services.Add(typeof(ITenantResolver), typeof(TImp), lifttime);
        return this;
    }
    
    public TenantBuilder<T> WithStore<TIml>(ServiceLifetime lifttime = ServiceLifetime.Transient) {
        _services.Add(typeof(ITenantStore), typeof(TIml), lifetime);
        return this;
    }
}

所以調用我們就變成這樣了

services.AddMultiTenancy()
        .WithTenantResolver<DomainTenantResolver>()
        .WithTenantStore<InMemoryTenatnStore>();

這樣看起來是不是更具表義化和優雅了呢。

我們重構了這一點，還有一點讓我不滿意。那就是為了獲取當前用戶租戶信息，我必須得註入兩個服務類 —— 解析類和存儲類。這點既然想到了還是要解決的，因為很簡單。就是平常我們使用的外觀模式。

我們加入一個特定租戶服務類來代替這兩個類不就好了麽。

public class TenantAppService<T> where T : Tenant {
    private readonly ITenantResolver _tenantResolver;
    private readonly ITenantStore _tenantStore;
    
    public TenantAppService(ITenantResolver tenantResolver, ITenantStore tenantStore) {
        _tenantResolver = tenantResolver;
        _tenantStore = tenantStore;
    }
    
    public async Task<T> GetTenantAsync() {
        var identifier = await _tenantResolver.GetTenantIdentifierAsync();
        return await _tenantStore.GetTenantAsync(identifier);
    }
}

這樣我們就只需要註入 TenantAppService 即可。

其實現在我們實現一個多租戶系統已經達到 90% 了。剩下的就是如何在數據訪問層根據獲取的租戶信息切換資料庫。實現方法其實也很簡單，就是在註冊完多租戶後，在資料庫上下文選擇鏈接字元串那裡替換你獲取的多租戶信息所對應的資料庫 ID 即可。具體的代碼實現這個後面再聊。