完全理解微商城多租戶Saas架構設計

完全理解微商城多租戶Saas架構設計

原文連接:https://blog.csdn.net/haponchang/article/details/104246317,感謝做者提供這麼好的總結!web

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),使用表進行數據隔離數據庫。底層庫好比是:DB二、ORACLE等,一個數據庫下能夠有多個SCHEMA。

應用程序需對接多個租戶的數據庫。

對租戶的管理由配置中心(Config Server)管理,同模式二。

優勢:爲安全性要求較高的租戶提供了必定程度的邏輯數據隔離,並非徹底隔離;每一個數據庫可支持更多的租戶數量。

問題:數據庫層面,若是出現故障,數據恢復比較困難,由於恢復數據庫將牽涉到其餘租戶的數據;應用層面,配置中心須要對租戶信息進行完整且合理的分配和維護。

3.4 一套服務+一套數據庫(相同schema)

模型與模型三的差異在於共享數據庫,共享 Schema,共享數據表。也就是說共同使用一個數據庫一個表使用字段進行數據隔離。如表中增長TenantID多租戶的數據字段。這是共享程度最高、隔離級別最低的模式。

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

優勢:方案的維護和購置成本低,容許每一個數據庫支持的租戶數量最多。

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

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

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

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

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

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

數據庫模式參考模式四。

優勢:有利於定製不一樣租戶的個性化需求。例如:交互界面不一樣、工做流不一樣等等。

服務只須要根據用戶需求在前臺作相應的橫向擴展便可;

不一樣租戶間服務相互獨立,互不影響。

缺點:模塊劃分須要作好劃分,重點注重業務之間的低耦合;

調用鏈路變長,須要作必定的優化處理;

模塊縱向拆分後,後期研發和運維難度均會有所增長;

好文收集不易,請轉發或在看,謝謝!

相關文章
相關標籤/搜索