mybatis 多租户saas_彻底理解微商城多租户Saas架构设计
原文鏈接：https://blog.csdn.net/haponchang/article/details/104246317，感謝作者提供這么好的總結(jié)！
1.具體的SaaS架構(gòu)必須
1.先仔細選擇最適合應(yīng)用程序需求的租戶模型，
2.需要根據(jù)租戶模型來選定最終的架構(gòu)，即應(yīng)用程序設(shè)計和管理、每個租戶的數(shù)據(jù)如何映射到存儲等等。
避免因租戶模型的切換而付出昂貴的代價。
租戶模型 ?--》 應(yīng)用程序設(shè)計 +?數(shù)據(jù)設(shè)計方案
2.影響租戶模型的相關(guān)因素包括：
2.1可擴展性(Scalability)
- 租戶的數(shù)量級
- 每個租戶的存儲級別
- 整體存儲
- 工作負載
2.2租戶隔離性(Tenant isolation)
- 數(shù)據(jù)隔離和性能(是否一個租戶的負載會影響到其他租戶)
2.3單租戶成本(Per-tenant cost)
- 數(shù)據(jù)庫成本
2.4 開發(fā)復(fù)雜度(Development complexity)
- 數(shù)據(jù)結(jié)構(gòu)的變化
- 查詢語句的變化
2.5運維復(fù)雜度(Operational complexity)
- 性能監(jiān)控
- 數(shù)據(jù)結(jié)構(gòu)schema管理
- 租戶數(shù)據(jù)恢復(fù)
- 災(zāi)備
2.4可定制化程度(Customizability)
根據(jù)租戶的需求自定義架構(gòu)的容易程度 這個租戶的討論集中在數(shù)據(jù)層。但考慮一下應(yīng)用層。應(yīng)用程序?qū)颖灰暈橐粋€整體實體。如果將應(yīng)用程序劃分為許多小型組件，您的租戶模型選擇可能會發(fā)生變化。對于租戶和存儲技術(shù)或使用的平臺，您可以對其他組件進行不同的處理。
3 常見的架構(gòu)模式有以下幾種：
3.1獨立服務(wù)+獨立數(shù)據(jù)庫
這個模型中，應(yīng)用層和數(shù)據(jù)層都是隔離的。
應(yīng)用程序的每個實例都是獨立實例。
租戶擁有自己獨立的數(shù)據(jù)庫，每個應(yīng)用程序?qū)嵗恍枰粋€數(shù)據(jù)庫。
對租戶的管理獨立于系統(tǒng)之外，對于每一個租戶，整個應(yīng)用程序需要重復(fù)安裝一次。供應(yīng)商都可以為租戶管理軟件。每個應(yīng)用程序?qū)嵗寂渲脼檫B接到其相應(yīng)的數(shù)據(jù)庫。
優(yōu)點：為不同的租戶提供獨立的應(yīng)用實例和數(shù)據(jù)庫，有助于簡化數(shù)據(jù)模型和業(yè)務(wù)模型的擴展設(shè)計，滿足不同租戶的獨特需求；如果出現(xiàn)故障，恢復(fù)系統(tǒng)或數(shù)據(jù)均比較簡單，系統(tǒng)間也不會相互影響。
問題：數(shù)據(jù)庫層面，每個租戶數(shù)據(jù)庫都作為獨立數(shù)據(jù)庫進行部署。該模型提供了最大的數(shù)據(jù)庫隔離。但隔離需要為每個數(shù)據(jù)庫分配足夠的資源來處理其高峰負載。這里重要的是， 彈性池不能用于部署在不同資源組或不同訂閱中的數(shù)據(jù)庫。這種限制使得這種獨立的單租戶應(yīng)用程序模型成為從整體數(shù)據(jù)庫成本角度來看最昂貴的解決方案；應(yīng)用層面，每個租戶若存在個性化定制，則需要對項目進行橫向擴展，擴展時務(wù)必需要保證與主干版本的兼容性問題。運維層面，應(yīng)用和數(shù)據(jù)庫的安裝數(shù)量會隨租戶的數(shù)量線性遞增，隨之帶來維護成本和購置成本的增加。
3.2一套服務(wù)+獨立數(shù)據(jù)庫
這個模型中，應(yīng)用層是共享的，數(shù)據(jù)層都是隔離的。
應(yīng)用程序僅部署一套，所有租戶實例共享。
租戶仍擁有自己獨立的數(shù)據(jù)庫，應(yīng)用程序需對接多個租戶的數(shù)據(jù)庫。
對租戶的管理由配置中心(Config Server)管理，配置中心提供了配置，監(jiān)視和管理共享所需的功能，供應(yīng)商使用這些工具為租戶管理軟件。對于每一個租戶，整個應(yīng)用程序僅需要安裝一次，應(yīng)用程序?qū)嶋H請求結(jié)合配置中心請求相應(yīng)的數(shù)據(jù)庫。
優(yōu)點：為不同的租戶提供獨立數(shù)據(jù)庫，有助于簡化數(shù)據(jù)模型擴展設(shè)計，滿足不同租戶的獨特需求；如果出現(xiàn)故障，數(shù)據(jù)恢復(fù)均比較簡單，也可以自動將單個租戶恢復(fù)到較早的時間點。因為恢復(fù)只需要恢復(fù)存儲租戶的一個單租戶數(shù)據(jù)庫。這種恢復(fù)對其他租戶沒有影響，這證實了管理運營處于每個租戶的細粒度級別。應(yīng)用層面的維護成本和購置成本有所減少。
問題：數(shù)據(jù)庫層面，同模型一；應(yīng)用層面，每個租戶若存在個性化定制，則需要對項目進行橫向擴展，擴展時務(wù)必需要保證與主干版本的兼容性問題。運維層面，數(shù)據(jù)庫的運維問題同模式一，應(yīng)用層面的運維在版本控制的問題上難度有所增加。
3.3 一套服務(wù)+一套數(shù)據(jù)庫(不同schema)
這個模型中，應(yīng)用層是共享的，數(shù)據(jù)庫共享，但數(shù)據(jù)是隔離的。
應(yīng)用程序和數(shù)據(jù)庫僅部署一套，所有租戶共享。
多個或所有租戶共享Database，也就是說共同使用一個數(shù)據(jù)庫，但是每個租戶一個Schema(也可叫做一個user)，使用表進行數(shù)據(jù)隔離數(shù)據(jù)庫。底層庫比如是：DB2、ORACLE等，一個數(shù)據(jù)庫下可以有多個SCHEMA。
應(yīng)用程序需對接多個租戶的數(shù)據(jù)庫。
對租戶的管理由配置中心(Config Server)管理，同模式二。
優(yōu)點：為安全性要求較高的租戶提供了一定程度的邏輯數(shù)據(jù)隔離，并不是完全隔離；每個數(shù)據(jù)庫可支持更多的租戶數(shù)量。
問題：數(shù)據(jù)庫層面，如果出現(xiàn)故障，數(shù)據(jù)恢復(fù)比較困難，因為恢復(fù)數(shù)據(jù)庫將牽涉到其他租戶的數(shù)據(jù)；應(yīng)用層面，配置中心需要對租戶信息進行完整且合理的分配和維護。
3.4 一套服務(wù)+一套數(shù)據(jù)庫(相同schema)
模型與模型三的差別在于共享數(shù)據(jù)庫，共享 Schema，共享數(shù)據(jù)表。也就是說共同使用一個數(shù)據(jù)庫一個表使用字段進行數(shù)據(jù)隔離。如表中增加TenantID多租戶的數(shù)據(jù)字段。這是共享程度最高、隔離級別最低的模式。
簡單來講，即每插入一條數(shù)據(jù)時都需要有一個客戶的標識。這樣才能在同一張表中區(qū)分出不同客戶的數(shù)據(jù)，這也是我們系統(tǒng)目前用到的(tenant_id)。
優(yōu)點：方案的維護和購置成本低，允許每個數(shù)據(jù)庫支持的租戶數(shù)量最多。
問題：隔離級別最低，安全性最低，需要在設(shè)計開發(fā)時加大對安全的開發(fā)量；數(shù)據(jù)備份和恢復(fù)最困難，需要逐表逐條備份和還原。
3.5網(wǎng)關(guān)+前臺+中臺+數(shù)據(jù)存儲
模式五與之前的模式的最大區(qū)別是，在原有的web Service進行細化拆分，優(yōu)化成 網(wǎng)關(guān)+前臺+中臺+數(shù)據(jù)存儲的模式。
網(wǎng)關(guān)用于接收租戶的請求，并發(fā)送給前臺。
前臺的數(shù)量與租戶一致，每一個租戶對應(yīng)一個前臺服務(wù)，方便針對租戶進行個性化定制。
中臺負責提供處理所有的業(yè)務(wù)請求，中臺不關(guān)心租戶是誰，將重心關(guān)注在業(yè)務(wù)的處理上。配置中心用于配置租戶的接口權(quán)限、流程定制等相關(guān)配置信息。結(jié)合業(yè)務(wù)邏輯返回給前臺特定租戶的相關(guān)信息。
數(shù)據(jù)庫模式參考模式四。
優(yōu)點：有利于定制不同租戶的個性化需求。例如：交互界面不同、工作流不同等等。服務(wù)只需要根據(jù)用戶需求在前臺做相應(yīng)的橫向擴展即可；?不同租戶間服務(wù)相互獨立，互不影響。
問題：模塊劃分需要做好劃分，重點注重業(yè)務(wù)之間的低耦合；調(diào)用鏈路變長，需要做一定的優(yōu)化處理；模塊縱向拆分后，后期研發(fā)和運維難度均會有所增加；
好文收集不易，請轉(zhuǎn)發(fā)或在看，謝謝！
總結(jié)
以上是生活随笔為你收集整理的mybatis 多租户saas_彻底理解微商城多租户Saas架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
