徹底理解微商城多租戶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進行細化拆分，優化成 網關+前台+中台+數據存儲的模式。

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

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

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

數據庫模式參考模式四。

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

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

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

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

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

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

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