多租戶場景下的 SaaS 平臺,該如何設(shè)計(jì)?
很多人對 SaaS 平臺的多租戶設(shè)計(jì)都缺乏概念上的支撐,因此會覺得難以理解,本篇文章梳理了一下 SaaS 系統(tǒng)的多租戶設(shè)計(jì)的結(jié)構(gòu),以及各類設(shè)計(jì)的特點(diǎn),相信對 SaaS 產(chǎn)品經(jīng)理會有不小的幫助。
前幾天和幾個搞技術(shù)的同事體驗(yàn)了一家公司的 SaaS 系統(tǒng),從運(yùn)營平臺,到租戶授權(quán)平臺再到業(yè)務(wù)應(yīng)用,一路配置起來到應(yīng)用步驟挺繁瑣的,以至于技術(shù)同事都不明白為什么會這么復(fù)雜。才發(fā)現(xiàn),他們對 SaaS 平臺的多租戶設(shè)計(jì)其實(shí)了解很少,由于缺乏概念上的支撐,因此會覺得難以理解這樣的設(shè)計(jì)。
對于剛接觸 SaaS 平臺的產(chǎn)品經(jīng)理來說估計(jì)也是有很多不明白的地方,本篇就來講講 SaaS 平臺的多租戶設(shè)計(jì)。
一、以釘釘來看實(shí)際多租戶場景
在講設(shè)計(jì)之前,我們先以“釘釘”為例,來看看一個 SaaS 平臺是如何運(yùn)作的。相信大部分B 端產(chǎn)品經(jīng)理都體驗(yàn)過釘釘,我們分兩個維度來講釘釘?shù)淖鈶糇缘绞褂玫牧鞒獭?/p>
一個是從個人視角來看使用釘釘?shù)牧鞒?,下面圖就是個人使用釘釘?shù)牧鞒獭_@個流程省略了個人注冊和其他人加好友聊天的功能,那個其實(shí)不算 B 端的業(yè)務(wù)范疇了。
這里的關(guān)鍵是你要使用某個企業(yè)(或團(tuán)隊(duì),以下我們統(tǒng)一稱為租戶)下的功能,首先你需要被邀請加入某個租戶。而且,一個賬號可以被邀請加入多個租戶。
如果你屬于多個租戶,那么和某個租戶相關(guān)的操作你需要先切換到該租戶下才可以使用。比如我們的工作臺、云盤這些就和租戶有關(guān),下面的圖就是釘釘?shù)墓ぷ髋_,默認(rèn)會有一個租戶,可以通過下拉方式切換租戶。
那么從租戶的角度來說,是什么樣的呢?流程如下圖所示。
與個人不同,對于租戶來說,多了創(chuàng)建團(tuán)隊(duì)、企業(yè)認(rèn)證和邀請成員幾個步驟。這屬于管理員類的功能,其中企業(yè)認(rèn)證不是必需的,只是經(jīng)過認(rèn)證的企業(yè)可用的功能和資源多一些。
通過釘釘?shù)睦游覀儠玫饺缦碌膶?shí)體關(guān)系:
- 一個平臺有很多個租戶;
- 一個平臺也有很多用戶;
- 一個用戶屬于多個租戶,一個租戶也有很多個用戶。
這個是基礎(chǔ)的關(guān)系,務(wù)必要明白。所以實(shí)際上一般 SaaS 平臺會有三個后臺:
- 運(yùn)營管理后臺:即平臺運(yùn)營管理的后臺系統(tǒng),通常用于管理租戶,主要是租戶的權(quán)限、資源的分配管理;這個平臺我們作為 SaaS 用戶是接觸不到的,但是作為 SaaS 產(chǎn)品設(shè)計(jì)是必不可少的。
- 租戶管理后臺:即租戶使用的管理后臺,主要是用于租戶的管理員管理成員和分配租戶內(nèi)部成員的權(quán)限、資源。
- 業(yè)務(wù)應(yīng)用:也就是實(shí)際租戶的各個成員使用的業(yè)務(wù)系統(tǒng),比如我們平時使用的釘釘?shù)淖烂娑?、App 其實(shí)都算是業(yè)務(wù)應(yīng)用。這個業(yè)務(wù)應(yīng)用其實(shí)是有多個的。比如釘釘自帶的 OA 審批、考勤系統(tǒng)、智能填表等等,其實(shí)都是一個個業(yè)務(wù)應(yīng)用。有些設(shè)計(jì)為了簡化,在后臺系統(tǒng)上,會將租戶管理后臺和業(yè)務(wù)應(yīng)用合并為一個后臺。
二、租戶權(quán)限與資源管理
對于一個平臺,租戶是其服務(wù)的主要對象,也是最終的買單人,即 SaaS 系統(tǒng)的訂閱者。因此,SaaS 的運(yùn)營管理后臺的一個核心職能就是管理平臺上的租戶的權(quán)限和資源管理。權(quán)限的管理和 SaaS 平臺的訂閱模式有比較大的關(guān)系,從抽象角度上來說也可以認(rèn)為是一種資源。我們常見的 SaaS 在權(quán)限這塊有兩種方式:
- 按銷售版本訂閱:這種不同的版本會有不同的功能。一般用于平臺本身的業(yè)務(wù)應(yīng)用是單體應(yīng)用,即權(quán)限是在應(yīng)用內(nèi),按租戶訂閱的版本不同分配不同的功能。
- 按應(yīng)用訂閱:這種是平臺比較大了,平臺會有若干個應(yīng)用,租戶首先選擇開通平臺中的某些應(yīng)用。當(dāng)然,應(yīng)用內(nèi)可以再細(xì)分出銷售版本,釘釘其實(shí)就是這種模式。這種模式比較重,但是擴(kuò)展性會比較好,適用于有心構(gòu)建開放應(yīng)用平臺的 SaaS 產(chǎn)品。
兩種模式的結(jié)構(gòu)對比如下兩張圖所示,當(dāng)然,多應(yīng)用的 SaaS 平臺每個應(yīng)用也可以單獨(dú)再分出一層銷售版本來。
資源一般來說會分為兩類,一類是平臺級資源,一類是應(yīng)用內(nèi)資源。平臺級資源由平臺統(tǒng)一管理,比如釘釘里的釘盤容量,應(yīng)用的使用期限等。
應(yīng)用內(nèi)資源即各個應(yīng)用自身的資源,比如授權(quán)使用的賬號數(shù)(當(dāng)然平臺級有些也會有總的賬號數(shù)限制)、短信條數(shù)等。
這種資源管理的原則是誰維護(hù)誰管理,也就是平臺維護(hù)的資源由平臺管理,應(yīng)用維護(hù)的資源由應(yīng)用管理,下面是資源的關(guān)系結(jié)構(gòu)圖。一般來說,資源會需要租戶購買,或者平臺會定期發(fā)放免費(fèi)資源(比如釘釘?shù)摹岸绦裴敗本褪前丛掠忻赓M(fèi)的額度可以使用)。
三、菜單管理
既然涉及到不同銷售版本,就會有菜單的管理,也就是需要將菜單統(tǒng)一管理,然后再把菜單組合成銷售版本,最后根據(jù)租戶購買的版本進(jìn)行授權(quán),最終落到客戶那邊呈現(xiàn)的就是可用的菜單。
這里同樣會涉及一個問題,就是菜單歸平臺管還是歸應(yīng)用管。這兩種模式其實(shí)現(xiàn)實(shí)中都有。我們遇到的平臺就是平臺統(tǒng)一管理,也就是應(yīng)用首先要在平臺配置菜單,這樣租戶才可以使用。
個人來說,不推薦這種由平臺統(tǒng)一管理的方式。一方面是導(dǎo)致平臺和應(yīng)用強(qiáng)耦合,如果平臺有第三方應(yīng)用的話,意味著第三方需要和平臺要同步菜單;另一方面是限制了平臺的靈活性,因?yàn)榧热皇遣藛?,要統(tǒng)一管理就需要有一套標(biāo)準(zhǔn)的菜單管理模式,這就要求應(yīng)用必須按照平臺的規(guī)則來。還有一個是,平臺要給應(yīng)用開發(fā)者(或運(yùn)營者)開放賬號管理菜單,實(shí)際上也增加了復(fù)雜度。
實(shí)際上,應(yīng)用開發(fā)方也會有對應(yīng)的運(yùn)營團(tuán)隊(duì),平臺只需要給租戶和應(yīng)用開發(fā)方提供溝通的渠道就可以了。比如,租戶訂閱某個應(yīng)用成功后,通知應(yīng)用開發(fā)方及時維護(hù)租戶的權(quán)限即可。
因?yàn)椋瑢?shí)際 B 端企業(yè)訂閱某個應(yīng)用,會有個下單付款過程,一般付款都是采用匯款的方式(我們在釘釘上購買第三方應(yīng)用的時候也是單獨(dú)付款給第三方,而不是經(jīng)過支付寶這類通道),這就意味著付款成功后才會介入服務(wù)。
當(dāng)然,也有免費(fèi)提供試用期的,這個時候只要租戶訂閱應(yīng)用,應(yīng)用開發(fā)方的售后團(tuán)隊(duì)就可以提前介入提供服務(wù),實(shí)際上后續(xù)付費(fèi)后也能接得上。
有了菜單管理后,SaaS 的實(shí)體關(guān)系變成了下面的樣子,這里省略了資源,實(shí)際資源和銷售版本有點(diǎn)類似,只是會有平臺級和應(yīng)用內(nèi)資源??偨Y(jié)來說,各個實(shí)體的關(guān)系如下:
- 一個平臺會有多個應(yīng)用;
- 一個應(yīng)用會有多個菜單,通過菜單組合成多種銷售版本;
- 租戶屬于1個平臺,租戶可以根據(jù)自身需要訂閱多個平臺下的應(yīng)用的某個銷售版本。
- 租戶擁有多個用戶,用戶也可以屬于多個租戶,但用戶則屬于同一個平臺。
四、多租戶設(shè)計(jì)核心要點(diǎn)
有了上面的整體概念后,我們就知道 SaaS 的多租戶設(shè)計(jì)的核心要點(diǎn)了,整理如下圖所示。這里說明幾點(diǎn):
1. 用戶和賬號的區(qū)別
對于平臺來說,注冊的賬號實(shí)際是平臺用戶,要通過用戶來確定用戶的唯一性。
同時,為了用戶能夠切換租戶,需要有用戶租戶管理(即用戶屬于哪些租戶);對于租戶來說,用戶其實(shí)就是賬號,也就是我這個租戶下開通了哪些賬號,一般一個賬號就對應(yīng)一個員工。
需要注意的是,租戶下的賬號可以注銷的(或者是禁用),比如說員工離職了,他還可以使用平臺,但是無法使用該租戶下的功能。
2. 訂單管理
平臺、應(yīng)用和租戶都能夠看到訂單,只是范圍不同。平臺管理整個平臺的訂單(不包含應(yīng)用內(nèi)自己的資源訂單,除非平臺覆蓋到了應(yīng)用內(nèi)的交易環(huán)節(jié)),應(yīng)用內(nèi)管理應(yīng)用自身產(chǎn)生的的訂單,而租戶看到的是自己的訂單。
3. 租戶權(quán)限管理
平臺如果是純粹的平臺,那么其實(shí)可以沒有權(quán)限管理的,但是一般 SaaS 平臺不會是一個空架子,會有一個或多個核心抓手應(yīng)用。這個就看平臺的設(shè)計(jì)了,是一開始就把自己的應(yīng)用當(dāng)作第三方等同對待還是特殊處理。
應(yīng)用管理租戶的權(quán)限主要是銷售版本的管理,這個很多時候可以通過訂單自動同步管理。不過,要考慮特殊場景,比如租戶可能購買的是較低級版本,但是為了推廣高級版本,可能會在后臺給租戶開通高級版本的試用權(quán)限。
4. 租戶后臺
租戶后臺其實(shí)和業(yè)務(wù)應(yīng)用可以混合在一起,只是管理員的權(quán)限不同而已。租戶后臺主要就是邀請成員(開賬號),進(jìn)行授權(quán)管理(通常會有功能權(quán)限和數(shù)據(jù)權(quán)限),然后是自己在平臺消費(fèi)的資源和訂單管理,主要是購買和查看為主。
5. 業(yè)務(wù)應(yīng)用
一般是基層員工用的頻次更多,對于管理層更多提供的是報(bào)表類的功能。這里主要是能夠支持用戶切換租戶以及便于租戶下的成員使用租戶開通的業(yè)務(wù)應(yīng)用功能。
五、多租戶數(shù)據(jù)存儲設(shè)計(jì)
在技術(shù)上多租戶數(shù)據(jù)存儲有三種方式,最簡單的一種是共用數(shù)據(jù)表,也就是不同租戶的數(shù)據(jù)存儲在同一張數(shù)據(jù)表中,然后通過租戶 id 區(qū)分。這種適合小型的 SaaS應(yīng)用,優(yōu)點(diǎn)是開發(fā)實(shí)現(xiàn)簡單,缺點(diǎn)是不同租戶之間的操作數(shù)據(jù)會有一定的影響(因?yàn)椴僮鞯耐粋€數(shù)據(jù)表,如果多個租戶同時操作,會有并發(fā)性能問題)。
另一種是分表設(shè)計(jì),即不同的租戶的數(shù)據(jù)表結(jié)構(gòu)雖然相同,但是使用各自的數(shù)據(jù)表。比如說一個權(quán)限表名是 auth,那么 A 租戶的叫 a_auth,B 租戶的叫 b_auth。這種設(shè)計(jì)需要根據(jù)租戶動態(tài)創(chuàng)建表,一般表名會有租戶 id 來區(qū)分唯一性。隔離程度上,比共用表好很多,復(fù)雜性也高一些,同時由于是共用了數(shù)據(jù)庫,整體性能會受數(shù)據(jù)庫性能影響,也就是租戶之間的操作還是一定程度上會相互影響。
最后一種是分庫設(shè)計(jì),就是不同的租戶使用不同的數(shù)據(jù)庫,這樣在數(shù)據(jù)上是完全隔離的。當(dāng)然,技術(shù)實(shí)現(xiàn)上也最復(fù)雜了。對于業(yè)務(wù)系統(tǒng)比較重的垂直SaaS應(yīng)用,建議是按這種方式設(shè)計(jì)。因?yàn)?,深入客戶業(yè)務(wù)的 SaaS 系統(tǒng)一般都是高頻操作,隨著客戶量增加,如果不分離數(shù)據(jù),會導(dǎo)致性能瓶頸出現(xiàn)。
當(dāng)然,實(shí)際也可以采用漸進(jìn)式的數(shù)據(jù)存儲設(shè)計(jì),即客戶少的時候使用共用數(shù)據(jù)表,客戶稍微多的時候用分表設(shè)計(jì),最后再使用分庫設(shè)計(jì)。這種前期成本低,后期會有數(shù)據(jù)遷移成本。
六、總結(jié)
本篇梳理了一下 SaaS 系統(tǒng)的多租戶設(shè)計(jì)的結(jié)構(gòu),各類設(shè)計(jì)的特點(diǎn),相信對 SaaS 產(chǎn)品經(jīng)理會有不小的幫助。對于 SaaS 系統(tǒng)的設(shè)計(jì),如果要調(diào)研復(fù)雜的 SaaS 系統(tǒng),推薦大家可以體驗(yàn)阿里云后臺和釘釘,相比而言,云廠商的后臺雖然不太像 SaaS,但是基本的設(shè)計(jì)思想是一樣的,而且云廠商的設(shè)計(jì)更為復(fù)雜一些,涵蓋了多個業(yè)務(wù)子系統(tǒng)和多類資源分配。
作者:產(chǎn)品海豚灣;公眾號:產(chǎn)品海豚灣(ID:pm-dophin-bay)
本文由@產(chǎn)品海豚灣 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
很有幫助!
文章很清晰,666
你好,順便想請問下您對跨租戶場景怎么看,跨租戶場景是否算個偽需求呢?
我們目前的項(xiàng)目種有遇到一些關(guān)聯(lián)性比較強(qiáng)的租戶,業(yè)務(wù)會有交集,流程或者某個業(yè)務(wù)處理節(jié)點(diǎn)有跨租戶處理的需求,請問下您這是否有遇到過類似的場景,有沒有好的建議
你這種模式 ,其實(shí)就是總公司 子公司的結(jié)構(gòu),子公司之間又有數(shù)據(jù)交互關(guān)系,這樣的模式用不到SaaS,只要做好功能權(quán)限下放管理和數(shù)據(jù)權(quán)限管理就可以了
很有幫助!
很清晰了
寫得好,很有幫助!
棒棒
寫得好吖!
謝謝肯定!