SaaS多租戶應用程序與數據庫數據隔離方案設計與選擇
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
![]() 軟件即服務 (Software as a service,SaaS) 是一種通過互聯網按需交付軟件應用程序的方法,通常采用訂閱方式。借助 SaaS,云服務提供商 (CSP) 可以托管和管理應用程序軟件和底層基礎設施,保證系統的可靠性。用戶可以通過手機或電腦上的網絡連接到應用程序。 通俗地講,就是將用戶的服務器相關硬件、操作系統、應用程序搬到云上,讓軟件提供商來維護。SaaS的優勢多用于ToB的業務,將客戶本地部署的系統遷移到云上,方方便客戶的同時,軟件提供商也創新了盈利模式。 SaaS對客戶來說有什么優勢呢?
客戶本地數據遷移到云上或者直接訂閱使用云上產品,不可避免需要關注數據的安全隔離。使用單租戶模式還是實現多租戶數據共存與訪問,企業在系統設計之初必須規劃多租戶的架構解決方案。 我們了解下租戶概念:
相信大家也有個疑問,在多租戶場景中,為什么要進行用戶數據隔離?操作數據時加條件篩選不也可以嗎?如下查詢:
如果開發者在某個地方漏掉 tenant_id 條件,可能出現以下問題:
通過數據隔離,上述問題就可以完全避免。盡管在操作數據時加條件在一定程度上可以實現多租戶數據的隔離,但它存在明顯的安全問題。在實際場景中,數據隔離通常是通過物理或邏輯上的手段綜合實現的,具體包括分庫分表、分區、租戶標識符控制等方式。 多租戶場景之所以要數據隔離,完全是出于數據安全與隱私保護。數據隔離可以降低數據泄露潛在風險、增強用戶對企業系統的信任、符合隱私法規(如GDPR、CCPA等)。 多租戶的架構中,最常見的方案主要有四種:
接下來,我簡單介紹這幾種方案的優劣情況和使用場景。
優點:
缺點:
場景:
優點:
缺點:
場景:
優點:
缺點:
場景:
優點:
缺點:
場景:
在設計有效的多租戶數據庫時,必須仔細平衡數據隔離、可擴展性、性能和安全性。對于成功運行的多租戶系統,每一個要素都至關重要。隨著租戶數量的增加,數據庫需要具有可擴展性,以便處理增加的負載。為了保證數據庫能夠快速有效地訪問數據,性能至關重要。對于這些應用程序,需要考慮實時數據訪問。 租戶數據庫的設計方案,需要結合自身的業務選型。在數據庫方面,實現數據隔離主要有數據庫、schema、行級這三種。當然也有分區模式和混合模式。 這三個方案會面臨的問題,我簡單總結如下: 通常SaaS場景下的單個租戶數據量不會太大,一般從幾十MB至幾十GB。新方案初期難確定容量大小,當服務器性能無法滿足時,再新增服務器分配新租戶來使用。因此設計數據庫的時候,需要一個專門存儲租戶信息的數據庫,該數據庫用于管理租戶、同時也記錄該租戶數據所在的數據庫連接信息。 如果明確租戶增長不會太大,且業務功能的使用也不同(較多表可能存在數據傾斜),數據量都是幾十GB的,推薦使用數據庫隔離模式。我們可以將幾十個數據庫放在同一個實例中,有效利用計算資源。數據庫隔離模式也適合schema隔離模式,當然需要考慮上面提到面臨的問題。 當租戶數量達成千上萬的時候,或者未來租戶數能達到這個量級,數據庫隔離模式就不必再考慮了,schema隔離模式確實可以考慮。能使用schema模式的常見關系型數據庫,如Oracle、SQL Server、PostgreSQL,但如果使用 PostgreSQL 的多schema隔離模式,autovacuum 可能會頻繁執行,將是比較大的性能問題! 當上萬的租戶、或者數據量少的租戶,推薦使用行級隔離。行級隔離的基本原理是,當用戶操作數據庫表時,系統判斷是否是某個租戶的數據,必須在連接會話中獲取能識別租戶的信息,如租戶賬號、租戶ID等。獲取到的信息需要與表中的行數據進行篩選匹配,如匹配表中字段tenant_id中的值,這樣操作的數據只能是該連接的租戶數據。 行級隔離不是簡單地加where條件篩選指定的租戶,因為無法不免有漏掉條件的可能。使用行級別安全(Row Level Security,RLS),即使不加租戶相關條件,租戶也只能操作自己的數據,達到租戶之間的數據安全隔離。目前Oracle、SQL Server、PostgreSQL 等都支持行級別安全。 使用RLS也可能存在數據傾斜,導致數量差異大的租戶操作SQL的執行計劃不準確,該如何處理呢?前面提到過混合場景和分區方案就是其中的解決方案。數據庫少的租戶可使用RLS方案,數據量大的租戶可以使用數據庫或schema方案。另外還可以使用分區方案,分區方案只是輔助RLS解決數據傾斜問題,不作為正式的租戶隔離方案。對于數據量大的租戶,可以將表進行分區,一個或多個分區存儲大租戶的數據,另一個分區存儲數據量少的租戶。 我這里介紹兩種案例:
SQL Server有真正的行級隔離方案,但這里我介紹的是另一種非正式的隔離方案,可以說也是一種通用方案,在其他數據庫都可以實現。 該方案在視圖中添加where條件,識別當前上下文環境的登錄用戶ID,到表中進行篩選。以下是一個完整的簡單示例。
應用程序只操作視圖,每張視圖背后都對應一張表。由于視圖已經隔離了用戶數據,任何用戶都不可能操作其他用戶的數據。如果表結構發生變化,可以通過存儲過程sp_refreshview刷新視圖定義。這是我以前公司用的一種租戶隔離方案,類似RLS。當前你也可以使用SQL Server 官方真正的“行級別安全性(RLS)”設計租戶隔離。
另一個實際的案例就是PostgreSQL的“行級安全策略(RLS)”。每張表都存在字段tenant_id,存儲租戶id,租戶id的管理可以從平臺數據庫中獲取。
我們定義策略參數app.tenant_id,當租戶連接數據庫時,需要設置app.tenant_id的值。當訪問表的時候,rls策略將獲取上下文信息app.tenant_id的參數值,相當于將“tenant_id=?” 拼接到where條件中,與前面的“SQL Server 使用視圖進行行級隔離”有相似之處。 數據庫級別與schema級別的數據隔離比較好理解,對租戶來說隔離性好,但不適合大量租戶的情況。一個企業的租戶數據量差異比較大,這就需要考慮產品是否真的符合租戶的業務場景。也就是說,企業內部需要對發布多個版本或多個產品滿足不同的客戶需求,在多租戶的數據庫設計方面也評估使用不同的數據隔離方案。 我們除了在數據庫選型、租戶架構選型之外,也要考慮云資源成本。客戶獲取成本、 客戶生命周期價值、月度經常性收入、 客戶流失率 是SaaS提供商特別關注的一些關鍵績效和業務指標。這些指標對于業務優化和增長至關重要,并且它們提供了SaaS公司財務狀況的全面概覽。針對租戶資源的成本占比、租戶均值成本等,評估租戶開銷是否超出了計劃。 閱讀原文:https://mp.weixin.qq.com/s/Ba_KqWY5a_SAKN4RvPqH5Q 該文章在 2025/1/25 9:13:25 編輯過 |
關鍵字查詢
相關文章
正在查詢... |