多租戶場景下的 SaaS 平臺,該如何設計?

9 評論 18919 瀏覽 222 收藏 17 分鐘

很多人對 SaaS 平臺的多租戶設計都缺乏概念上的支撐,因此會覺得難以理解,本篇文章梳理了一下 SaaS 系統的多租戶設計的結構,以及各類設計的特點,相信對 SaaS 產品經理會有不小的幫助。

前幾天和幾個搞技術的同事體驗了一家公司的 SaaS 系統,從運營平臺,到租戶授權平臺再到業務應用,一路配置起來到應用步驟挺繁瑣的,以至于技術同事都不明白為什么會這么復雜。才發現,他們對 SaaS 平臺的多租戶設計其實了解很少,由于缺乏概念上的支撐,因此會覺得難以理解這樣的設計。

對于剛接觸 SaaS 平臺的產品經理來說估計也是有很多不明白的地方,本篇就來講講 SaaS 平臺的多租戶設計。

一、以釘釘來看實際多租戶場景

在講設計之前,我們先以“釘釘”為例,來看看一個 SaaS 平臺是如何運作的。相信大部分B 端產品經理都體驗過釘釘,我們分兩個維度來講釘釘的租戶注冊到使用的流程。

一個是從個人視角來看使用釘釘的流程,下面圖就是個人使用釘釘的流程。這個流程省略了個人注冊和其他人加好友聊天的功能,那個其實不算 B 端的業務范疇了。

講講 SaaS 平臺的多租戶設計

這里的關鍵是你要使用某個企業(或團隊,以下我們統一稱為租戶)下的功能,首先你需要被邀請加入某個租戶。而且,一個賬號可以被邀請加入多個租戶。

如果你屬于多個租戶,那么和某個租戶相關的操作你需要先切換到該租戶下才可以使用。比如我們的工作臺、云盤這些就和租戶有關,下面的圖就是釘釘的工作臺,默認會有一個租戶,可以通過下拉方式切換租戶。

講講 SaaS 平臺的多租戶設計

那么從租戶的角度來說,是什么樣的呢?流程如下圖所示。

講講 SaaS 平臺的多租戶設計

與個人不同,對于租戶來說,多了創建團隊、企業認證和邀請成員幾個步驟。這屬于管理員類的功能,其中企業認證不是必需的,只是經過認證的企業可用的功能和資源多一些。

通過釘釘的例子我們會得到如下的實體關系:

  • 一個平臺有很多個租戶;
  • 一個平臺也有很多用戶;
  • 一個用戶屬于多個租戶,一個租戶也有很多個用戶。

講講 SaaS 平臺的多租戶設計

這個是基礎的關系,務必要明白。所以實際上一般 SaaS 平臺會有三個后臺:

  1. 運營管理后臺:即平臺運營管理的后臺系統,通常用于管理租戶,主要是租戶的權限、資源的分配管理;這個平臺我們作為 SaaS 用戶是接觸不到的,但是作為 SaaS 產品設計是必不可少的。
  2. 租戶管理后臺:即租戶使用的管理后臺,主要是用于租戶的管理員管理成員和分配租戶內部成員的權限、資源。
  3. 業務應用:也就是實際租戶的各個成員使用的業務系統,比如我們平時使用的釘釘的桌面端、App 其實都算是業務應用。這個業務應用其實是有多個的。比如釘釘自帶的 OA 審批、考勤系統、智能填表等等,其實都是一個個業務應用。有些設計為了簡化,在后臺系統上,會將租戶管理后臺和業務應用合并為一個后臺。

二、租戶權限與資源管理

對于一個平臺,租戶是其服務的主要對象,也是最終的買單人,即 SaaS 系統的訂閱者。因此,SaaS 的運營管理后臺的一個核心職能就是管理平臺上的租戶的權限和資源管理。權限的管理和 SaaS 平臺的訂閱模式有比較大的關系,從抽象角度上來說也可以認為是一種資源。我們常見的 SaaS 在權限這塊有兩種方式:

  1. 按銷售版本訂閱:這種不同的版本會有不同的功能。一般用于平臺本身的業務應用是單體應用,即權限是在應用內,按租戶訂閱的版本不同分配不同的功能。
  2. 按應用訂閱:這種是平臺比較大了,平臺會有若干個應用,租戶首先選擇開通平臺中的某些應用。當然,應用內可以再細分出銷售版本,釘釘其實就是這種模式。這種模式比較重,但是擴展性會比較好,適用于有心構建開放應用平臺的 SaaS 產品。

兩種模式的結構對比如下兩張圖所示,當然,多應用的 SaaS 平臺每個應用也可以單獨再分出一層銷售版本來。

講講 SaaS 平臺的多租戶設計

講講 SaaS 平臺的多租戶設計

資源一般來說會分為兩類,一類是平臺級資源,一類是應用內資源。平臺級資源由平臺統一管理,比如釘釘里的釘盤容量,應用的使用期限等。

應用內資源即各個應用自身的資源,比如授權使用的賬號數(當然平臺級有些也會有總的賬號數限制)、短信條數等。

這種資源管理的原則是誰維護誰管理,也就是平臺維護的資源由平臺管理,應用維護的資源由應用管理,下面是資源的關系結構圖。一般來說,資源會需要租戶購買,或者平臺會定期發放免費資源(比如釘釘的“短信釘”就是按月有免費的額度可以使用)。

講講 SaaS 平臺的多租戶設計

三、菜單管理

既然涉及到不同銷售版本,就會有菜單的管理,也就是需要將菜單統一管理,然后再把菜單組合成銷售版本,最后根據租戶購買的版本進行授權,最終落到客戶那邊呈現的就是可用的菜單。

這里同樣會涉及一個問題,就是菜單歸平臺管還是歸應用管。這兩種模式其實現實中都有。我們遇到的平臺就是平臺統一管理,也就是應用首先要在平臺配置菜單,這樣租戶才可以使用。

個人來說,不推薦這種由平臺統一管理的方式。一方面是導致平臺和應用強耦合,如果平臺有第三方應用的話,意味著第三方需要和平臺要同步菜單;另一方面是限制了平臺的靈活性,因為既然是菜單,要統一管理就需要有一套標準的菜單管理模式,這就要求應用必須按照平臺的規則來。還有一個是,平臺要給應用開發者(或運營者)開放賬號管理菜單,實際上也增加了復雜度。

實際上,應用開發方也會有對應的運營團隊,平臺只需要給租戶和應用開發方提供溝通的渠道就可以了。比如,租戶訂閱某個應用成功后,通知應用開發方及時維護租戶的權限即可。

因為,實際 B 端企業訂閱某個應用,會有個下單付款過程,一般付款都是采用匯款的方式(我們在釘釘上購買第三方應用的時候也是單獨付款給第三方,而不是經過支付寶這類通道),這就意味著付款成功后才會介入服務。

當然,也有免費提供試用期的,這個時候只要租戶訂閱應用,應用開發方的售后團隊就可以提前介入提供服務,實際上后續付費后也能接得上。

有了菜單管理后,SaaS 的實體關系變成了下面的樣子,這里省略了資源,實際資源和銷售版本有點類似,只是會有平臺級和應用內資源??偨Y來說,各個實體的關系如下:

  • 一個平臺會有多個應用;
  • 一個應用會有多個菜單,通過菜單組合成多種銷售版本;
  • 租戶屬于1個平臺,租戶可以根據自身需要訂閱多個平臺下的應用的某個銷售版本。
  • 租戶擁有多個用戶,用戶也可以屬于多個租戶,但用戶則屬于同一個平臺。

講講 SaaS 平臺的多租戶設計

四、多租戶設計核心要點

有了上面的整體概念后,我們就知道 SaaS 的多租戶設計的核心要點了,整理如下圖所示。這里說明幾點:

1. 用戶和賬號的區別

對于平臺來說,注冊的賬號實際是平臺用戶,要通過用戶來確定用戶的唯一性。

同時,為了用戶能夠切換租戶,需要有用戶租戶管理(即用戶屬于哪些租戶);對于租戶來說,用戶其實就是賬號,也就是我這個租戶下開通了哪些賬號,一般一個賬號就對應一個員工。

需要注意的是,租戶下的賬號可以注銷的(或者是禁用),比如說員工離職了,他還可以使用平臺,但是無法使用該租戶下的功能。

2. 訂單管理

平臺、應用和租戶都能夠看到訂單,只是范圍不同。平臺管理整個平臺的訂單(不包含應用內自己的資源訂單,除非平臺覆蓋到了應用內的交易環節),應用內管理應用自身產生的的訂單,而租戶看到的是自己的訂單。

3. 租戶權限管理

平臺如果是純粹的平臺,那么其實可以沒有權限管理的,但是一般 SaaS 平臺不會是一個空架子,會有一個或多個核心抓手應用。這個就看平臺的設計了,是一開始就把自己的應用當作第三方等同對待還是特殊處理。

應用管理租戶的權限主要是銷售版本的管理,這個很多時候可以通過訂單自動同步管理。不過,要考慮特殊場景,比如租戶可能購買的是較低級版本,但是為了推廣高級版本,可能會在后臺給租戶開通高級版本的試用權限。

4. 租戶后臺

租戶后臺其實和業務應用可以混合在一起,只是管理員的權限不同而已。租戶后臺主要就是邀請成員(開賬號),進行授權管理(通常會有功能權限和數據權限),然后是自己在平臺消費的資源和訂單管理,主要是購買和查看為主。

5. 業務應用

一般是基層員工用的頻次更多,對于管理層更多提供的是報表類的功能。這里主要是能夠支持用戶切換租戶以及便于租戶下的成員使用租戶開通的業務應用功能。

講講 SaaS 平臺的多租戶設計

五、多租戶數據存儲設計

在技術上多租戶數據存儲有三種方式,最簡單的一種是共用數據表,也就是不同租戶的數據存儲在同一張數據表中,然后通過租戶 id 區分。這種適合小型的 SaaS應用,優點是開發實現簡單,缺點是不同租戶之間的操作數據會有一定的影響(因為操作的同一個數據表,如果多個租戶同時操作,會有并發性能問題)。

另一種是分表設計,即不同的租戶的數據表結構雖然相同,但是使用各自的數據表。比如說一個權限表名是 auth,那么 A 租戶的叫 a_auth,B 租戶的叫 b_auth。這種設計需要根據租戶動態創建表,一般表名會有租戶 id 來區分唯一性。隔離程度上,比共用表好很多,復雜性也高一些,同時由于是共用了數據庫,整體性能會受數據庫性能影響,也就是租戶之間的操作還是一定程度上會相互影響。

最后一種是分庫設計,就是不同的租戶使用不同的數據庫,這樣在數據上是完全隔離的。當然,技術實現上也最復雜了。對于業務系統比較重的垂直SaaS應用,建議是按這種方式設計。因為,深入客戶業務的 SaaS 系統一般都是高頻操作,隨著客戶量增加,如果不分離數據,會導致性能瓶頸出現。

當然,實際也可以采用漸進式的數據存儲設計,即客戶少的時候使用共用數據表,客戶稍微多的時候用分表設計,最后再使用分庫設計。這種前期成本低,后期會有數據遷移成本。

六、總結

本篇梳理了一下 SaaS 系統的多租戶設計的結構,各類設計的特點,相信對 SaaS 產品經理會有不小的幫助。對于 SaaS 系統的設計,如果要調研復雜的 SaaS 系統,推薦大家可以體驗阿里云后臺和釘釘,相比而言,云廠商的后臺雖然不太像 SaaS,但是基本的設計思想是一樣的,而且云廠商的設計更為復雜一些,涵蓋了多個業務子系統和多類資源分配。

作者:產品海豚灣;公眾號:產品海豚灣(ID:pm-dophin-bay)

本文由@產品海豚灣 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 很有幫助!

    來自重慶 回復
  2. 文章很清晰,666

    你好,順便想請問下您對跨租戶場景怎么看,跨租戶場景是否算個偽需求呢?
    我們目前的項目種有遇到一些關聯性比較強的租戶,業務會有交集,流程或者某個業務處理節點有跨租戶處理的需求,請問下您這是否有遇到過類似的場景,有沒有好的建議

    來自陜西 回復
    1. 你這種模式 ,其實就是總公司 子公司的結構,子公司之間又有數據交互關系,這樣的模式用不到SaaS,只要做好功能權限下放管理和數據權限管理就可以了

      來自陜西 回復
  3. 很有幫助!

    來自上海 回復
  4. 很清晰了

    來自江蘇 回復
  5. 寫得好,很有幫助!

    來自上海 回復
  6. 棒棒

    來自浙江 回復
  7. 寫得好吖!

    來自廣東 回復
    1. 謝謝肯定!

      來自湖南 回復