

一、每個租戶提供獨立的數據庫
這種方案就是所有租戶共享同一個應用,但應用後端會連接多個數據庫,每個租戶一個數據庫,這樣租戶間的數據就實現了物理隔離,其部署架構圖如下所示:
從上圖可以看出,每個租戶都有自己獨立的數據庫,因此對每個租戶的數據進行備份和還原是很容易的,但是此種方案存在一個弊端就是租戶的開銷比較大,相比於另外2種方案,開銷主要耗費在硬件方面,為了支持多數據庫實例及保持數據庫較高的性能,我們可能需要將數據庫部署到單獨的服務器上,隨著租戶數量不斷的遞增,那麽開銷也會成倍的增長,導致運營成本的增加,但是這種方案卻是3種方案中數據隔離性最高的一種,雖然這種隔離仍然屬於邏輯上的隔離,通常使用這種方案的租戶對安全的要求非常高,比如像金融、醫療客戶,他們要求數據要有很強的隔離並且對支出。需要註意的是,在3種方案種,多租戶應用負責將用戶請求路由到不同的數據源上,路由的依據可以在用戶請求頭上做某些識別,如發送的請求頭可以構造成下面的格式:
> GET /index HTTP/1.1
> Host: localhost:8080
> User-Agent: Mozilla/5.0
> Accept: */*
> X-TENANT-ID: tenant_1
後臺接收到請求後根據 X-TENANT-ID 字段來識別用戶,也可以通過url模式來識別租戶,如為每個租戶都設置一個獨立的URL模式,如 tenant1 用戶的 url 為 tenant1.app.com,或者最直接的方式就是在用戶登錄後將其用戶信息保存在 session 中,每次請求從 session 中獲取用戶 ID。
二、每個租戶提供獨立的表空間
本方案就是所有租戶共享同一個應用,應用後端只連接一個數據庫,每個租戶在數據庫實例中擁有一個獨立的表空間,其部署架構圖如下所示:
從上圖可以看出,這種設計應用後端只連接了一個數據庫實例,數據庫實例中存在多個表空間,每個表空間屬於不同的租戶,但每個表空間內都存在相同的表,一般適用於表空間小於 100 張表的系統,這種方案無論是對於用戶還是對運維來說都是一個比較好的這種方案,因為從硬件方面來說一般只需要一臺性能足夠強勁的服務器就可以支撐上百用戶,適合預算有限但又對數據隔離有較大需求的客戶,從維護方面看,對每個租戶的數據庫進行備份和恢復也非常簡單,缺點可能就是備份出來的文件數量比較多,需要額外的進行管理。
三、按字段區分租戶
本方案是多租戶方案中最簡單的設計模式了,幾乎所有的信息系統或多或少都用過這種設計,即在每張表中都添加一個字段(如租戶id或租戶代碼)來標識每條數據屬於哪個租戶,很像外鍵的作用,當進行查詢的時候每條語句都要添加該字段作為過濾條件,其特點是所有租戶的數據全都存放在同一個表中,數據的隔離性是最低的,完全是通過字段來區分的,適用於預算及其有限的、對數據隔離要求不高及數據量不大的低端用戶。這種設計方式相較於前兩種在成本上是最廉價的,但維護起來很麻煩,比如要對用戶進行數據備份,就會把所有租戶的數據都備份,想要單獨備份某個租戶的數據需要特殊處理,而要恢復數據也要所有租戶的數據一起恢復,想要恢復某個用戶的數據需要將用戶數據單獨提取出來再恢復,操作起來很麻煩,不具有實際的可操作性,其設計架構如下所示:
從上面的圖中可以看出所有租戶的數據都位於同一個表空間中,表空間中存放著租戶共享表,每個表中通過“tenant_id”字段來區分不同租戶的數據,這種模式雖然是最簡單但卻喪失了為租戶可定制的可能性,如果要對表進行擴展那麽所有租戶都要受到影響。
四、總結
以上就是多租戶架構模式常見的三種方案,它們各有優缺點,而在實際中到底采用哪種設計方案,要與企業所面向的用戶群體、業務量等方面相結合才能決定采用哪種方案是最合理也是最經濟的,下面就從不同的方面對三種方案進行歸納:
數據隔離性 可定制性 可承載租戶數 租戶開銷 可維護性(備份恢復) 運營成本 獨立的數據庫 高 高 少 高 優 高 獨立的表空間 中 中 多 中 優 中 按字段區分租戶 低 低 較多 低 中 低
以上基本講解了多租戶的架構模式,下一講我將用代碼的方式實現一個“獨立的表空間”的多租戶系統,因為這種方案在保證數據隔離的情況下,對企業來說也是最經濟的,大部分都采用這種方案,敬請關註。
參考文檔:
https://msdn.Microsoft.com/en-us/library/aa479086.aspx
Tags: 租戶 客戶 軟件 架構 我們 計算
文章來源: