徹底理解微商城多租戶Saas架構設計

原文鏈接：https://blog.csdn.net/haponchang/article/details/104246317，感謝作者提供這麼好的總結！

1.具體的SaaS架構必須

1.先仔細選擇最適合應用程式需求的租戶模型，

2.需要根據租戶模型來選定最終的架構，即應用程式設計和管理、每個租戶的數據如何映射到存儲等等。

避免因租戶模型的切換而付出昂貴的代價。

租戶模型  --》 應用程式設計 + 數據設計方案

2.影響租戶模型的相關因素包括：

2.1可擴展性（Scalability）

• 租戶的數量級
• 每個租戶的存儲級別
• 整體存儲
• 工作負載

2.2租戶隔離性（Tenant isolation）

• 數據隔離和性能（是否一個租戶的負載會影響到其他租戶）

2.3單租戶成本（Per-tenant cost）

• 資料庫成本

2.4 開發複雜度（Development complexity）

• 數據結構的變化
• 查詢語句的變化

2.5運維複雜度（Operational complexity）

• 性能監控
• 數據結構schema管理
• 租戶數據恢復
• 災備

2.4可定製化程度（Customizability）

根據租戶的需求自定義架構的容易程度
這個租戶的討論集中在數據層。但考慮一下應用層。應用程式層被視為一個整體實體。如果將應用程式劃分為許多小型組件，您的租戶模型選擇可能會發生變化。對於租戶和存儲技術或使用的平臺，您可以對其他組件進行不同的處理。

3 常見的架構模式有以下幾種：

3.1獨立服務+獨立資料庫

這個模型中，應用層和數據層都是隔離的。

應用程式的每個實例都是獨立實例。

租戶擁有自己獨立的資料庫，每個應用程式實例只需要一個資料庫。

對租戶的管理獨立於系統之外，對於每一個租戶，整個應用程式需要重覆安裝一次。供應商都可以為租戶管理軟體。每個應用程式實例都配置為連接到其相應的資料庫。

優點：為不同的租戶提供獨立的應用實例和資料庫，有助於簡化數據模型和業務模型的擴展設計，滿足不同租戶的獨特需求；如果出現故障，恢復系統或數據均比較簡單，系統間也不會相互影響。

問題：資料庫層面，每個租戶資料庫都作為獨立資料庫進行部署。該模型提供了最大的資料庫隔離。但隔離需要為每個資料庫分配足夠的資源來處理其高峰負載。這裡重要的是， 彈性池不能用於部署在不同資源組或不同訂閱中的資料庫。這種限制使得這種獨立的單租戶應用程式模型成為從整體資料庫成本角度來看最昂貴的解決方案；應用層面，每個租戶若存在個性化定製，則需要對項目進行橫向擴展，擴展時務必需要保證與主幹版本的相容性問題。運維層面，應用和資料庫的安裝數量會隨租戶的數量線性遞增，隨之帶來維護成本和購置成本的增加。

3.2一套服務+獨立資料庫

這個模型中，應用層是共用的，數據層都是隔離的。

應用程式僅部署一套，所有租戶實例共用。

租戶仍擁有自己獨立的資料庫，應用程式需對接多個租戶的資料庫。

對租戶的管理由配置中心（Config Server）管理，配置中心提供了配置，監視和管理共用所需的功能，供應商使用這些工具為租戶管理軟體。對於每一個租戶，整個應用程式僅需要安裝一次，應用程式實際請求結合配置中心請求相應的資料庫。

優點：為不同的租戶提供獨立資料庫，有助於簡化數據模型擴展設計，滿足不同租戶的獨特需求；如果出現故障，數據恢復均比較簡單，也可以自動將單個租戶恢復到較早的時間點。因為恢復只需要恢復存儲租戶的一個單租戶資料庫。這種恢復對其他租戶沒有影響，這證實了管理運營處於每個租戶的細粒度級別。應用層面的維護成本和購置成本有所減少。

問題：資料庫層面，同模型一；應用層面，每個租戶若存在個性化定製，則需要對項目進行橫向擴展，擴展時務必需要保證與主幹版本的相容性問題。運維層面，資料庫的運維問題同模式一，應用層面的運維在版本控制的問題上難度有所增加。

3.3 一套服務+一套資料庫（不同schema）

這個模型中，應用層是共用的，資料庫共用，但數據是隔離的。

應用程式和資料庫僅部署一套，所有租戶共用。

多個或所有租戶共用Database，也就是說共同使用一個資料庫，但是每個租戶一個Schema（也可叫做一個user），使用表進行數據隔離資料庫。底層庫比如是：DB2、ORACLE等，一個資料庫下可以有多個SCHEMA。

應用程式需對接多個租戶的資料庫。

對租戶的管理由配置中心（Config Server）管理，同模式二。

優點：為安全性要求較高的租戶提供了一定程度的邏輯數據隔離，並不是完全隔離；每個資料庫可支持更多的租戶數量。

問題：資料庫層面，如果出現故障，數據恢複比較困難，因為恢複數據庫將牽涉到其他租戶的數據；應用層面，配置中心需要對租戶信息進行完整且合理的分配和維護。

3.4 一套服務+一套資料庫（相同schema）

模型與模型三的差別在於共用資料庫，共用 Schema，共用數據表。也就是說共同使用一個資料庫一個表使用欄位進行數據隔離。如表中增加TenantID多租戶的數據欄位。這是共用程度最高、隔離級別最低的模式。

簡單來講，即每插入一條數據時都需要有一個客戶的標識。這樣才能在同一張表中區分出不同客戶的數據，這也是我們系統目前用到的(tenant_id)。

優點：方案的維護和購置成本低，允許每個資料庫支持的租戶數量最多。

缺點：隔離級別最低，安全性最低，需要在設計開發時加大對安全的開發量；數據備份和恢復最困難，需要逐表逐條備份和還原。

3.5網關+前臺+中台+數據存儲

模式五與之前的模式的最大區別是，在原有的web Service進行細化拆分，優化成 網關+前臺+中台+數據存儲的模式。

網關用於接收租戶的請求，併發送給前臺。

前臺的數量與租戶一致，每一個租戶對應一個前臺服務，方便針對租戶進行個性化定製。

中台負責提供處理所有的業務請求，中台不關心租戶是誰，將重心關註在業務的處理上。配置中心用於配置租戶的介面許可權、流程定製等相關配置信息。結合業務邏輯返回給前臺特定租戶的相關信息。

資料庫模式參考模式四。

優點：有利於定製不同租戶的個性化需求。例如：交互界面不同、工作流不同等等。

服務只需要根據用戶需求在前臺做相應的橫向擴展即可；

不同租戶間服務相互獨立，互不影響。

缺點：模塊劃分需要做好劃分，重點註重業務之間的低耦合；

調用鏈路變長，需要做一定的優化處理；

模塊縱向拆分後，後期研發和運維難度均會有所增加；

好文收集不易，請轉發或在看，謝謝！