本文來說下什么是多租戶saas架構設計

概述

今天談下云平臺下的多租戶架構，不論是在公有云還是私有云平臺，是設計一個面向最終組織或用戶的SaaS應用還是面向業務系統的PaaS平臺，多租戶都是前期架構設計的一個關鍵內容，因此有必要對里面的一些核心要點進一步說明，

多租戶架構

首先還是看下百度百科對多租戶的一些關鍵說明如下：

多租戶技術（英語：multi-tenancy technology）或稱多重租賃技術，是一種軟體架構技術，它是在探討與實作如何于多用戶的環境下共用相同的系統或程式組件，并且仍可確保各用戶間資料的隔離性，多租戶簡單來說是指一個單獨的實體可以為多個組織服務，多租戶技術為共用的資料中心內如何以單一系統架構與服務提供多數客戶端相同甚至可定制化的服務，并且仍然可以保障客戶的資料隔離，一個支持多租戶技術的系統需要在設計上對它的資料和配置進行虛擬磁區，從而使系統的每個租戶或稱組織都能夠使用一個單獨的系統實體，并且每個租戶都可以根據自己的需求對租用的系統實體進行個性化配置，

多租戶技術可以實作多個租戶之間共享系統實體，同時又可以實作租戶的系統實體的個性化定制，通過使用多租戶技術可以保證系統共性的部分被共享，個性的部分被單獨隔離，通過在多個租戶之間的資源復用，運營管理維護資源，有效節省開發應用的成本，而且，在租戶之間共享應用程式的單個實體，可以實作當應用程式升級時，所有租戶都可以同時升級，同時，因為多個租戶共享一份系統的核心代碼，因此當系統升級時，只需要升級相同的核心代碼即可，

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

比如我們開發一個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種share everything的模式，在這種模式下資料庫和應用都為一套，

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

一個是系統本身元資料和基礎主資料的隔離（用戶，角色，權限，資料字典，流程模板），一個是系統運行程序中產生的動態資料的隔離，一個是業務系統底層所涉及到的計算資源和存盤資源的隔離，

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

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

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

多租戶除了隔離外，另外一個重點就是能夠為各個租戶按需要實時地提供各種計算資源和存盤資源，而且有清楚定義的資料采集和計費模型，由于資源池是共享的，我們必須要能夠準確地采集到各個租戶對實際資源的使用情況，以方便進行多租戶的計費，

共享資源時候的資源隔離

當在IaaS云平臺的時候，一臺物理機可以虛擬化為多臺虛擬云主機提供給不同的租戶使用，虛擬機可以做到在計算，網路，存盤等方面的資源邏輯隔離，也就是說一個租戶本身導致的虛擬機使用例外或性能問題，并不會影響到其它租戶使用的虛擬機，

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

比如當前有A，B，C，D四個租戶在使用SaaS版本的CRM系統，那么我們就需要考慮是不是會出現由于A租戶出現的大并發和大資料量訪問而導致了剩余的三個租戶無法正常使用系統，要做到這點，我們就必須做到面向租戶的服務容量控制，服務限流等能力，

多租戶下的資源計費

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

但是對于SaaS應用來說，要做到按資源使用情況計費就比較復雜，因此一般的SaaS應用會簡單地根據用戶注冊數，并發數或存盤容量分配來進行組合計費，當然如果是非共享資源模式的多租戶架構，相當來說就更加容易按資源使用來進行計費，

多租戶下的分域和分組

即使是資源完全共享下的多租戶架構，仍然不建議采用一個大集群來為所有租戶提供服務，而是應該對大集群進行分域或分組，或者多大的集群資源進行磁區或分片處理，讓不同的租戶分配到不同的集群組或分片上面，

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

多租戶下的資料庫擴展

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

獨立資料庫模式為每個租戶分配一個獨立的資料庫，其在SID層就是完全獨立的，而對于共享資料庫但是Schema獨立這種模式下，SID只有一個，但是當入駐新的租戶的時候會單獨新生成一個獨立的Schema，

最后一種模式就是完全共享資料庫，SID和Schema都只有一套，在這種模式下核心是所有資料庫表都需要增加租戶ID欄位對資料進行多租戶隔離，以保障某一個租戶登錄系統只能夠看到自己租戶下的相關資訊，如果是一個完整的多租戶應用，還需要考慮第二層按用戶，組織，角色群組等進行第二級的資料隔離，以滿足業務系統的使用需求，

可以看到獨立資料庫模式資源利用率低，但是資料隔離性最好；而完全共享模式下資源利用率高，但是資料隔離性最弱，因此具體采用哪種模式仍然需要根據實際租戶的需求來進行靈活創建和配置，一個靈活的SaaS應用實際需要同時靈活支撐上面三種模式，

本文小結

本文詳細介紹了什么是多租戶saas架構設計以及與其相關的基本概念，