雲平臺下的多租戶架構-你應該理解的一些關鍵點

比如我們開發一個SaaS雲服務的CRM系統。

這個系統部署在公有云端可以開放給多個企業客戶使用。

那麼我們就遇到了一個關鍵問題。

即是否當新入駐一個新的企業 ... MdEditor 雲平臺下的多租戶架構-你應該理解的一些關鍵點 語言:CN/TW/HK 時間 2021-06-0807:47:49 人月聊IT 主題: 技術 今天談下雲平臺下的多租戶架構，不論是在公有云還是私有云平臺，是設計一個面向最終組織或使用者的SaaS應用還是面向業務系統的PaaS平臺，多租戶都是前期架構設計的一個關鍵內容，因此有必要對裡面的一些核心要點進一步說明。

多租戶架構概述首先還是看下百度百科對多租戶的一些關鍵說明如下：多租戶技術（英語：multi-tenancytechnology）或稱多重租賃技術，是一種軟體架構技術，它是在探討與實現如何於多使用者的環境下共用相同的系統或程式元件，並且仍可確保各使用者間資料的隔離性。

多租戶簡單來說是指一個單獨的例項可以為多個組織服務。

多租戶技術為共用的資料中心內如何以單一系統架構與服務提供多數客戶端相同甚至可定製化的服務，並且仍然可以保障客戶的資料隔離。

一個支援多租戶技術的系統需要在設計上對它的資料和配置進行虛擬分割槽，從而使系統的每個租戶或稱組織都能夠使用一個單獨的系統例項，並且每個租戶都可以根據自己的需求對租用的系統例項進行個性化配置。

多租戶技術可以實現多個租戶之間共享系統例項，同時又可以實現租戶的系統例項的個性化定製。

通過使用多租戶技術可以保證系統共性的部分被共享，個性的部分被單獨隔離。

通過在多個租戶之間的資源複用，運營管理維護資源，有效節省開發應用的成本。

而且，在租戶之間共享應用程式的單個例項，可以實現當應用程序升級時，所有租戶都可以同時升級。

同時，因為多個租戶共享一份系統的核心程式碼，因此當系統升級時，只需要升級相同的核心程式碼即可。

這段描述可能理解起來比較囉嗦，我們還是從簡單的場景來進行說明。

比如我們開發一個SaaS雲服務的CRM系統。

這個系統部署在公有云端可以開放給多個企業客戶使用。

那麼我們就遇到了一個關鍵問題。

即是否當新入駐一個新的企業客戶的時候，我們都需要重新在部署一套應用給這個客戶使用？如果是這樣，那麼當新客戶入駐的時候，將帶來具體的人工投入和資源投入成本。

因此實際的情況是我們希望新增加客戶的時候，仍然還是已有的那套應用系統。

但是對於最終的入駐客戶來說，我們又希望客戶完全感知不到這點，就像是單獨給他們部署了一套系統一樣。

雖然很多客戶使用同一套應用，但是能夠很好地做到資源和資料的隔離。

而這正好就是多租戶架構的一個關鍵點。

多租戶，多組織，使用者區別接著談下一些常見概念的關鍵區別。

多租戶和多組織實際上在雲端計算和多租戶這些概念出來前，就已經有多組織的概念。

比如常說的類似Oracle,SAP等ERP系統都是支援多組織架構。

多組織架構簡單來說就是對於一個大的集團性質企業，企業本身涉及到子公司或分公司，子公司可能涉及到獨立法人也可能涉及到需要獨立輸出財務報表，或者相關公司還在海外涉及到不同的財務和會計準則。

基於以上各種場景持續了多組織架構。

一個多組織架構支撐集團所有的企業都上同一套ERP系統，裡面通過法人，財務賬簿，OU等設定進行了多組織的支撐。

而不是單獨為一個子公司再去部署一套獨立的應用系統。

從這個概念來看多組織和多租戶相當類似。

那麼兩者的關鍵區別點在哪裡？簡單總結來說多組織架構重點考慮的是資料層面的隔離，但是對於多租戶架構更多的還需要考慮資源層面的隔離。

多組織架構一般不會考慮類似雲平臺中的計費和計量管理，資料隔離更多是為了後續財務和資料安全管控要求，而多租戶架構則需要考慮計費和計量管理。

多組織架構下一般資源全共享，而多租戶架構下資源是否共享和資源安全管控要求相關。

租戶和使用者租戶和使用者實際是不同的兩個概念，租戶更多的是為了資源管理和計費計量使用，而使用者更多的是為了業務功能和授權使用。

租戶和使用者有時候也是一一對應的關係，比如你開發一個面向個人使用者的線上郵箱SaaS應用，那麼這個時候租戶和使用者本身是對應的，租戶即使用者。

但是如果你開發的是一個面向企業的SaaS應用系統，那麼這個時候租戶對應的是組織這個層面，即入駐的企業是租戶，對應企業入駐後，SaaS應用會先給企業分配一個管理員賬號，這個時候管理員再去詳細的錄入企業裡面的具體使用者賬號。

也就是說租戶是第一層，而下面的組織架構和使用者是第二層。

SaaS應用和PaaS平臺的多租戶注意對於SaaS應用和PaaS平臺本身都有多租戶的概念。

對於SaaS應用來說，比如一個toB的SaaS應用服務。

最終面對的是企業和終端使用者，因此每一個入駐的企業組織就是租戶。

而對於PaaS平臺來說，比如我們在企業內部建設一個公共流程平臺，這個流程平臺即企業私有云內部的PaaS平臺一部分，那麼這個平臺本身也需要進行多租戶設計，而這個平臺的租戶實際是各個需要使用流程引擎能力的業務系統。

對於類似容器雲PaaS平臺，訊息，快取各種PaaS技術服務，都可以看到實際上各個業務系統就是最終的租戶。

還是拿上面的例子來說。

如果企業內部的公共流程平臺提供給多個業務系統開發商使用，類似用友在該企業本身開發了CRM和SRM兩個業務系統。

那麼實際管理方式可以是CRM和SRM單獨進行租戶申請和註冊。

也可以是兩層結構，即還是先進行組織申請，組織作為第一層租戶。

但是組織接入後還需要維護需要接入的業務系統，業務系統作為第二層租戶。

第一層的組織實際只是一個抽象的租戶集的概念。

而實際的資源管理，計量計費等可以細粒度地管理到業務系統這個層級。

多租戶架構設計和資源隔離在多租戶和雲結合的情況下，IaaS基礎資源層的共享已經會變化為最基本的要求。

那麼在Iaas層之上來談主要則包括兩個方面的內容，即應用是一套還是多套？資料庫是一套還是多套？最徹底的多租戶即上圖中的第6種shareeverything的模式，在這種模式下資料庫和應用都為一套。

多租戶我們首先考慮隔離，在多租戶下的隔離包括了幾個方面的內容。

一個是系統本身元資料和基礎主資料的隔離（使用者，角色，許可權，資料字典，流程模板），一個是系統執行過程中產生的動態資料的隔離，一個是業務系統底層所涉及到的計算資源和儲存資源的隔離。

在應用一套，資料庫多套或多schema分離情況，我們比較容易實現計算資源和儲存資源的單獨分配，但是在完全shareeverthing的情況下，對於計算和儲存資源的隔離則需要我們的PaaS應用本身去考慮。

在當前雲原生和容器下，整個動態部署和持續交付都更加容易，那麼為了更好地進行資源隔離，我們完全可以為單獨的大租戶動態的擴充套件一套獨立的容器叢集為該租戶服務，即實現該租戶能夠單獨使用一組容器資源池而非共享。

在私有云下的多租戶，往往隔離又不是絕對的，在能夠完全隔離的情況下又需要支撐跨租戶或組織的資料共享，可以看到如果存在這種需求，在Shareeverthing的情況下是比較容易滿足的。

多租戶除了隔離外，另外一個重點就是能夠為各個租戶按需要實時地提供各種計算資源和儲存資源，而且有清楚定義的資料採集和計費模型。

由於資源池是共享的，我們必須要能夠準確地採集到各個租戶對實際資源的使用情況，以方便進行多租戶的計費。

共享資源時候的資源隔離當在IaaS雲平臺的時候，一臺物理機可以虛擬化為多臺虛擬雲主機提供給不同的租戶使用，虛擬機器可以做到在計算，網路，儲存等方面的資源邏輯隔離。

也就是說一個租戶本身導致的虛擬機器使用異常或效能問題，並不會影響到其它租戶使用的虛擬機器。

到了SaaS層多租戶，實際上仍然需要考慮租戶下面的資源管理，特別是在多個租戶共享一套底層資源的情況下。

比如當前有A，B，C，D四個租戶在使用SaaS版本的CRM系統，那麼我們就需要考慮是不是會出現由於A租戶出現的大併發和大資料量訪問而導致了剩餘的三個租戶無法正常使用系統。

要做到這點，我們就必須做到面向租戶的服務容量控制，服務限流等能力。

多租戶下的資源計費如果是一個IaaS平臺的多租戶，可以看到對於彈性計算和彈性儲存資源都是單獨申請的，資源本身也是邏輯隔離，這個時候計費相對簡單。

但是對於SaaS應用來說，要做到按資源使用情況計費就比較複雜。

因此一般的SaaS應用會簡單地根據使用者註冊數，併發數或儲存容量分配來進行組合計費。

當然如果是非共享資源模式的多租戶架構，相當來說就更加容易按資源使用來進行計費。

多租戶下的分域和分組即使是資源完全共享下的多租戶架構，仍然不建議採用一個大叢集來為所有租戶提供服務，而是應該對大叢集進行分域或分組，或者多大的叢集資源進行分割槽或分片處理。

讓不同的租戶分配到不同的叢集組或分片上面。

這樣做的好處可以避免單個大叢集無限擴充套件導致的效能問題和管理難度，同時也提升了整個應用對外的容錯能力，比如A叢集全部故障，還可以快速的將A叢集流量切換到B叢集。

多租戶下的資料庫擴充套件在公有云下的多租戶，如果採用完全共享的模式，還必須考慮資料庫的可擴充套件性，多租戶架構服務下的資料庫可以是獨立資料庫，共享資料庫但是Schema獨立，完全共享資料庫幾種模式。

獨立資料庫模式為每個租戶分配一個獨立的資料庫，其在SID層就是完全獨立的。

而對於共享資料庫但是Schema獨立這種模式下，SID只有一個，但是當入駐新的租戶的時候會單獨新生成一個獨立的Schema。

最後一種模式就是完全共享資料庫，SID和Schema都只有一套，在這種模式下核心是所有資料庫表都需要增加租戶ID欄位對資料進行多租戶隔離，以保障某一個租戶登入系統只能夠看到自己租戶下的相關資訊。

如果是一個完整的多租戶應用，還需要考慮第二層按使用者，組織，角色群組等進行第二級的資料隔離，以滿足業務系統的使用需求。

可以看到獨立資料庫模式資源利用率低，但是資料隔離性最好；而完全共享模式下資源利用率高，但是資料隔離性最弱。

因此具體採用哪種模式仍然需要根據實際租戶的需求來進行靈活建立和配置，一個靈活的SaaS應用實際需要同時靈活支撐上面三種模式。

「技術」 中國十大領先全球的自主創新科技技術，你知道幾個？ androidJetpackCompose用Canvas畫一個鐘 window平臺oracle通過opatch打補丁注意事項 中國科學院深圳先進技術研究院一行到訪久久金集團參觀考察 6G技術或變革手機制造，多國已開始部署 寶馬為何排斥換電技術？答案只有一個 36歲生4個娃，牙齒竟全部掉光，牙病怎麼破？一項新技術有大用 港珠澳大橋憑這些技術被稱為“新世界七大奇蹟之一” 《數字金融反欺詐技術應用分析報告》釋出，新技術應用逐漸成熟 長吻鮠大規格魚種池塘高效養殖技術示範 「其他文章」 中心化和去中心化，叢集和分散式之間的區別和聯絡 對於記敘文寫作，三個關鍵點值得思考 寫作日更4年上1000天，我如何做到長週期的持續寫作 定製化軟體專案-從前期估算到成本收益分析 個人知識經驗分享-從免費到付費 做IT整合類大專案，真正成功交付並盈利的少之又少 從數字化到元宇宙-現實世界和抽象世界的統一 不惑隨筆-重新思考生命的價值和意義 做事從容則有餘味，做人從容則有餘年 千燈萬盞，不如心燈一盞 數字化轉型中的資料治理-從資料資產到資料服務 數字化轉型下企業IT應用和軟體自主可控分析 資料匯流排是否就是ESB服務匯流排，從企業應用整合場景說起 如何畫架構圖-你需要了解核心的內在構圖邏輯 專案經理思維和意識的轉變-從團隊管理到軟體生命週期 SOA介面服務執行監控報表需求分析 SOA實施深化-從技術平臺到提供厚服務層的業務平臺 頭條日更寫作1年整，個人原創文章整理和總結 微服務和DevOps，容器雲-加速ServiceMesh服務網格落地 分散式架構下混沌工程-提升雲原生應用的穩定性和可觀測性