Multi Tenancy相關介紹

眾所周知，雲計算可以劃分為以下幾個層次的服務——IaaS、PaaS和SaaS，而今天我們今天講的多租戶架構就是一種常見的 SaaS 軟體架構模式，或者說是商業模式。 通常，一個多租戶軟體指的是依托雲計算的彈性環境，搭建並使用一個單一的應用程式實例來服務多個客戶，每個客戶稱之為“租戶”來共用同一個軟體，很像現在很火的共用經濟，客戶們都只是來租用系統，按時收費，客戶是不需要提供或關心軟體的運行環境，只要開通賬號即可使用，方便快捷。舉個例子，假如我們推出了一款財務軟體，可以為企業提供財務方面的管理功能，按照傳統的部署方法，我們通常將程式、資料庫等組件都部署在客戶的伺服器上，這需要企業有自己的機房和伺服器並配備有相關專業知識的運維人員，但如果程式或其他組件出現 bug 等嚴重故障時，我們就需要派遣工程師到客戶現場進行救援恢復工作，耗時耗力，而有了以雲計算為依托的多租戶架構軟體，那麼我們就可以將這套財務軟體部署在自己的機房內，只要讓“租戶”註冊賬號，通過互聯網即可訪問系統，同時“租戶”們的數據相互隔離，只能看到自己的數據，軟體的安全性也得到了保障。最重要的是，當系統出現故障時，工程師可以快速定位問題，並將最新的補丁應用於系統上，將“租戶”服務中斷時間壓縮到最小，而不用花費大量的時間到現場進行排錯，同時也不必派遣工程師出差，為企業運維降低了成本。 由此可見，多租戶架構的軟體是雲計算時代軟體研發的一個重要方向，不僅對客戶提供了便捷，也節省了企業的成本，是一個雙贏的方案。

上面有句話可能不太嚴謹，通常只有小型的多租戶程式才只部署一個單一的運行實例，這種情況只適用於租戶較少、伺服器壓力負載低的用例，此時租戶的費用支出較為低廉，適合預算有限的客戶。但這種部署方案存在缺點就是由於多個租戶公用一套程式，一旦程式有 bug，那麼所有的租戶都會受到影響，且沒法為單獨租戶提供定製，靈活性低，不過一分價錢一分貨。其部署架構如下圖所示：

而對於中大型規模的應用來說，只部署一個實例就略顯單薄，並且也無法承載大量的用戶，這時就需要部署多個實例，併在多實例的基礎上進行負載均衡以保證性能。最重要的是，多實例的部署架構允許為每個租戶定製代碼，提供特色服務，其部署架構如下圖所示：

由於大型的多實例方案中需要加入負載均衡以及受商業、業務相關的因素的影響，會導致在多租戶架構之外包裹這更複雜的業務設計，因此本文就只討論單實例方案下的多租戶架構。從上面的介紹可知，在傳統的部署方案中，客戶數據始終是保留在自己的手中，而在雲計算時代，多租戶系統為用戶提供了一個集中式的數據存儲方案，這需要說服用戶將他們的數據保留在雲端，因此多租戶系統最為關鍵也是客戶最關心的便是數據的安全性，因此本文對多租戶系統的架構分析也是從數據的安全性方面作為切入點。由於用戶數據是集中存儲的，數據的安全性就是能否實現對數據的隔離，防止數據不經意或被他人惡意地獲取，多租戶系統架構主要有3種方案實現數據的隔離，即為每個租戶提供獨立的資料庫、獨立的表空間或按欄位區分租戶，下麵我們依次講解這3種方案。

一、每個租戶提供獨立的資料庫

這種方案就是所有租戶共用同一個應用，但應用後端會連接多個資料庫，每個租戶一個資料庫，這樣租戶間的數據就實現了物理隔離，其部署架構圖如下所示：

從上圖可以看出，每個租戶都有自己獨立的資料庫，因此對每個租戶的數據進行備份和還原是很容易的，但是此種方案存在一個弊端就是租戶的開銷比較大，相比於另外2種方案，開銷主要耗費在硬體方面，為了支持多資料庫實例及保持資料庫較高的性能，我們可能需要將資料庫部署到單獨的伺服器上，隨著租戶數量不斷的遞增，那麼開銷也會成倍的增長，導致運營成本的增加，但是這種方案卻是3種方案中數據隔離性最高的一種，雖然這種隔離仍然屬於邏輯上的隔離，通常使用這種方案的租戶對安全的要求非常高，比如像金融、醫療客戶，他們要求數據要有很強的隔離並且對支出也能負擔的起。需要註意的是，在3種方案種，多租戶應用負責將用戶請求路由到不同的數據源上，路由的依據可以在用戶請求頭上做某些識別，如發送的請求頭可以構造成下麵的格式：

1
2
3
4
5

> 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://www.mingzhe.org/blog/2017/08/01/multiple-tenants-architecture-introduction/