如何自行實現一個多租戶系統
阿新 • • 發佈：2020-03-16
# 如何自行實現一個多租戶系統
注意：前情概要描述的文字比較多，說的是我的思考過程，不感興趣的可以直接到跳到 “解析租戶資訊” 一節。
現如今框架滿天飛的環境下，好像很少機會需要自己來實現一個模組。畢竟這樣能節省很多的開發時間，提高效率。
這就是框架的好處，也是我們使用框架的直接原因。
情況總有例外，假設剛好我們公司沒有用到框架，用的就是 .netcore 平臺新建專案，直接開幹一把唆。由於前期工作沒有考慮周全，現在發現公司新建的平臺專案的業務資料越來越大，提供給使用者的數量越來越多。但是這些不同的使用者的資料肯定不能互相干擾。
舉個例子說明，例如我舉個跟我公司接近的一種情況，公司再搭建資料平臺，來給不同學校提供資料。並且我們的資料平臺要記錄合作學校對應的學生和老師。前面有假設提到公司前期考慮不周，我們把所有的學校放在 school 表中，所有學生放在 student 表中。所有老師放在 teacher 表中。這樣當公司系統在給他們（使用者）提供資料的時候，是不是每次都要判斷當前使用者在哪個學校，然後再把對應的學校資料推送給他們。不僅如此，對資料敏感的增刪改操作對這種混在一起資料要各位小心。一不小心，可能就會發生誤刪其他學校的資訊。
為了有效的解決這個問題，我們第一要做的就是要將資料分開管理，彼此互不干擾。這是我們要實現的最終目的。
想要的效果有了，現在的問題是能不能實現，該如何實現，怎麼實現才算好。
我們做事情的目的就是解決問題，在前面我們分析了我們要把資料在一個系統中隔離。那麼我們自然能想到的就是以學校為領域劃分為不同的庫。這樣我們在系統執行的時候就能做到在使用者選擇對應的學校登陸系統時，就只能訪問這個學校的所有資訊了。
到這裡，我們就很清晰了，如果我們平時多看多聽到別人談論新的知識點或框架時，我們就會知道對於這種情況，“多租戶”就是為了這種情況而誕生的。
既然要做 “多租戶” 系統，並且團隊之間沒有使用市面上的多租戶框架。那麼我們就得自己實現一個了。那麼要做的第一件就是要了解 “多租戶” 的概念。正所謂知己知彼，方能戰無不勝。
# 什麼是多租戶
我們來看下維基百科對多租戶的定義是什麼（以下是概述）
多租戶軟體架構就是在同一個系統例項上執行不同使用者，能做到應用程式共享，服務自治，並且還能做到資料互相隔離的軟體架構思想。一個租戶就相當於一組使用者（比如針對學校來說，一個學校就是一個租戶，這個租戶下有學生，老師作為使用者（一組使用者））。
現在我們總結一下我們要做什麼？
我們要實現：
1. 相同的應用程式 app 下
2. 解析出登陸系統的（當前使用者）是屬於哪一個租戶（對應到例子就是學校）。
3. 根據解析出來的租戶資訊，來訪問對應的資料庫資訊。
現在我們就來實現上面說的步驟。第一步不用想，肯定要得一個 app 下。
# 解析租戶資訊
現在我們要設計如何才能讓系統檢測到當前使用者的租戶資訊。
現階段我們能想到的解析方式有三種：
1. 域名：例如 tenant1.example.com，tenant2.example.com
2. URL：例如 www.example.com/tenant1/，www.example.com/tenant2
3. header：例如 [x-header: 'tenant1']，[x-header: 'tenant2']
一下子有這麼多解決方式，是不是自信心起來了，有木有。
具體如何用程式碼實現呢？首先要定義一個 “租戶” 的資訊體，為了方便表述我這裡用的是類（當然也可以用介面）
```c#
public class Tenant {
public string Identifier { get; set;}
public string Id { get; set;}
}
```
只要繼承了這個租戶類，就表示擁有了這個租戶資訊。有了租戶之後，我們緊接著要做的就是解析了。因為前面有討論我們解析方式有三種，這裡我主要討論第一種的實現方案。正是因為有多種可能，解析方式對於架構來說是不穩定的，所以我們要封裝變化來抽象畫。我們先定一個解析租戶介面類，然後提供一個實現類具體以域名方式解析，這樣封裝就達到對修改封閉，新增開放（OCP）的目的了。例如使用者可以自行繼承介面用 URL 方式解析租戶資訊。
```c#
public interface ITenantResolver {
Task GetTenantIdentifierAsync();
}
public class DomainTenantResolver : ITenantResolver {
private readonly IHttpContextAccessor _accessor;
public DomainTenantResolver(IHttpContextAccessor accessor) {
_accessor = accessor;
}
// 這裡就解析道了具體的域名了，從而就能得知當前租戶
public async Task GetTenantIdentifierAsync() {
return await Task.FromResult(_accessor.HttpContext.Request.Host.Host);
}
}
```
接著我們拿到租戶識別符號，要幹嘛呢？自然是要存起來的，好讓系統很方便的獲取當前使用者的租戶資訊。
# 儲存租戶資訊
關於儲存功能，同樣我們選擇抽象出來一個 `ITenantStore` 介面。為什麼要抽象出來，作為一個基礎功能架構設計。我們就應該考慮這個功能的解決方案是否是穩定的。明顯，對於儲存來說，方式太多了。所以作為系統，要提供一個基本實現的同時還要供開發者方便選擇其他方式。
```c#
public interface ITenantStore {
Task GetTenantAsync(string identifier);
}
```
關於儲存，其實我們可以選擇將租戶資訊放入記憶體中，也可以選擇放入配置檔案，當然你選擇將租戶資訊放入資料庫也是沒問題的。
> 現在的最佳實踐是將一些敏感資訊，比如每個租戶對應的連結字串都是以 Option 配置檔案方式儲存的。利用 .netcore 內建 DI 做到即拿即用。
這裡為了簡便，我選擇用硬編碼的方式儲存租戶資訊
```c#
public class InMemoryTenantStore: ITenantStore {
private Tenant[] tenantSource = new[] {
new Tenant{ Id = "4da254ff-2c02-488d-b860-cb3b6363c19a", Identifier = "localhost" }
};
public async Task GetTenantAsync(string identifier) {
var tenant = tenantSource.FirstOrDefault(p => p.Identifier == identifier);
return await Task.FromResult(tenant);
}
}
```
好了，現在我們租戶資訊有了，解析器也提供了，儲存服務也決定了。那麼接下來就只剩下什麼了？
# 進入管道捕獲源頭
剩下的就是找到請求的源頭，很顯然，.netcore 優良的設計，我們可以很方便的將上述我們準備的服務安排至管道中。那就是註冊服務（AddXXXService）和中介軟體（UseXXX）。
所以我們這一步要做的就是
1. 註冊解析租戶資訊服務
2. 註冊中介軟體，好讓每一次請求發起時截獲資訊將使用者的租戶資訊存至這個請求（HttpContext）裡面，好讓系統隨時訪問當前使用者租戶資訊。
## 註冊服務類
這個太簡單了，.netcore 的原始碼給了我們很好的範例
```c#
public static class ServiceCollectionExtensions {
public static AddMultiTenancy(this IServiceColletion services, Action registerAction) where T : Tenant {
service.TryAddSingleton(); // 這一步很重要
registerAction?.Invoke(services);
}
}
```
呼叫：
```c#
// Startup.cs ConfigureServices
services.AddMultiTenancy(s => {
// 註冊解析類
s.AddScoped(typeof(ITenantResolver), typeof(DomainTenantResolver));
// 註冊儲存
s.AddScoped(typeof(ITenantStore), typeof(InMemoryStore));
})
```
這樣我們就能在系統中比如控制器，注入這兩個類來完成對當前租戶資訊的訪問。
註冊服務解決了，然後是中介軟體
## 註冊中介軟體
中介軟體所幹的事，很簡單，就是捕獲進來管道的請求上下文，然後解析得出租戶資訊，然後把對應的租戶資訊放入請求上下文中。
```c#
class MultiTenantMiddleware 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)) as TenantAppService;
// 這裡也可以放到其他地方，比如 context.User.Cliams 中
context.Items.Add("localhost", await tenantService.GetTenantAsync());
}
if (_next != null)
await _next(context);
}
}
```
這樣我們就實現了整個請求對當前租戶操作過程了。所以本文就結束了。
不好意思，開個玩笑。還沒結束，其實上面是我第一版的寫法。不知道大家有沒有發現，我這樣寫其實是有 “問題” 的。大毛病沒有，就是對開發者不友好。
首先，在 ConfigureServices 方法裡的註冊操作，我的 AddMultiTenancy 方法不純粹。這是我當時寫這個 demo 時候感覺特別明顯的。因為起初我的方法簽名是不帶回調函式 action 的。
```c#
public static IServiceCollection AddMultiTenancy(this IServiceColletion services) where T : Tenant {
services.TryAddSingleton(); // 這一步很重要
services.Add(typeof(ITenantResolver), typeof(ImlITenantResolver), LifetimeScope);
services.Add(typeof(ITenantStore), typeof(ImlITenantStore), LifetimeScope);
return services;
}
```
但是在註冊租戶解析類和儲存類時，發現沒有實現型別和生命週期做引數，根本無法註冊。如果把兩個引數當成方法簽名，那不僅使這個方法變得醜陋，還固話了這個方法的使用。
所以最後我改成了上面用回撥的方式，暴露給開發者自己去註冊。所以這就要求開發者必須要清楚要註冊那些內容。
所以後來一次偶然的機會看到相關的資料，告訴我其實可以藉助 Program.cs 中的 Builder 模式改善程式碼，可以讓程式碼結構更加表義化。第二版如下
```c#
public static class ServiceCollectionExtensions {
public static TenantBuilder AddMultiTenancy(this IServiceColletion services) where T : Tenant {
return new TenantBuilder(services);
}
}
```
```c#
public class TenantBuilder where T : Tenant {
private readonly IServiceCollection _services;
public TenantBuilder(IServiceCollection services) {
_services = services;
}
public TenantBuilder WithTenantResolver(ServiceLifetime lifttime = ServiceLifetime.Transient) where TIml : ITenantResolver {
_services.TryAddSingleton(); // 這一步很重要
_services.Add(typeof(ITenantResolver), typeof(TImp), lifttime);
return this;
}
public TenantBuilder WithStore(ServiceLifetime lifttime = ServiceLifetime.Transient) {
_services.Add(typeof(ITenantStore), typeof(TIml), lifetime);
return this;
}
}
```
所以呼叫我們就變成這樣了
```c#
services.AddMultiTenancy()
.WithTenantResolver()
.WithTenantStore();
```
這樣看起來是不是更具表義化和優雅了呢。
我們重構了這一點，還有一點讓我不滿意。那就是為了獲取當前使用者租戶資訊，我必須得注入兩個服務類 —— 解析類和儲存類。這點既然想到了還是要解決的，因為很簡單。就是平常我們使用的外觀模式。
我們加入一個特定租戶服務類來代替這兩個類不就好了麼。
```c#
public class TenantAppService where T : Tenant {
private readonly ITenantResolver _tenantResolver;
private readonly ITenantStore _tenantStore;
public TenantAppService(ITenantResolver tenantResolver, ITenantStore tenantStore) {
_tenantResolver = tenantResolver;
_tenantStore = tenantStore;
}
public async Task GetTenantAsync() {
var identifier = await _tenantResolver.GetTenantIdentifierAsync();
return await _tenantStore.GetTenantAsync(identifier);
}
}
```
這樣我們就只需要注入 TenantAppService 即可。
其實現在我們實現一個多租戶系統已經達到 90% 了。剩下的就是如何在資料訪問層根據獲取的租戶資訊切換資料庫。實現方法其實也很簡單，就是在註冊完多租戶後，在資料庫上下文選擇連結字串那裡替換你獲取的多租戶資訊所對應的資料庫 ID 即可。具體的程式碼實現這個後面再聊。
# 總結
回顧一下，我們目前做的事。
1. 發現問題：資料混在在一起無法做到完美的資料隔離，不好控制。
2. 瞭解原理：什麼是多租戶
3. 解決方案：為了解決問題想到的可實現的技術方案
4. 在架構上考慮如何優化重構一個模組。
發現沒有，我們做事一定是要 “帶著問題解決問題”。首先是解決問題，然後才是重構。千萬不要在一開始就想著要重構。
其實我們在解決一個問題時，我們專案架構可能沒有其中某一個模組，當要用到這個模組時，我們怎麼做的。其實一個快速有效的訪問，就是去看有這個模組功能開源框架，去學習裡面的思想。看他們是如何做的。然後有了思路就可以依葫蘆畫瓢了，甚至是可以直接貼上拷貝。
參考資料：https://michael-mckenna.com/multi-tenant-asp-dot-net-core-application-tenant-resolution **推薦閱讀**