如何自行實作一個多租戶系統
注意：前情概要描述的文字比較多，說的是我的思考程序，不感興趣的可以直接到跳到 “決議租戶資訊” 一節，
現如今框架滿天飛的環境下，好像很少機會需要自己來實作一個模塊，畢竟這樣能節省很多的開發時間，提高效率，
這就是框架的好處，也是我們使用框架的直接原因，
情況總有例外，假設剛好我們公司沒有用到框架，用的就是 .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 即可，具體的代碼實作這個后面再聊，
總結
回顧一下，我們目前做的事，
- 發現問題：資料混在在一起無法做到完美的資料隔離，不好控制，
- 了解原理：什么是多租戶
- 解決方案：為了解決問題想到的可實作的技術方案
- 在架構上考慮如何優化重構一個模塊，
發現沒有，我們做事一定是要 “帶著問題解決問題”，首先是解決問題，然后才是重構，千萬不要在一開始就想著要重構，
其實我們在解決一個問題時，我們專案架構可能沒有其中某一個模塊，當要用到這個模塊時，我們怎么做的，其實一個快速有效的訪問，就是去看有這個模塊功能開源框架，去學習里面的思想，看他們是如何做的，然后有了思路就可以依葫蘆畫瓢了，甚至是可以直接粘貼拷貝，
參考資料：https://michael-mckenna.com/multi-tenant-asp-dot-net-core-application-tenant-resolution 推薦閱讀
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/56744.html
標籤：.NET Core