#頭條創作挑戰賽#
前言
和幾個搞技術的同僚體驗了一家公司的 SaaS 系統，從營運平台，到租戶授權平台再到業務應用，一路配置起來到應用步驟挺繁瑣的，以至于技術同僚都不明白為什麼會這麼複雜。才發現，他們對 SaaS 平台多租戶設計其實了解很少，由于缺乏概念上的支撐，是以會覺得難以了解這樣的設計。對于剛接觸 SaaS 平台的産品經理來說估計也是有很多不明白的地方，本篇就來講講 SaaS 平台的多租戶設計。
以“釘釘”為例看實際的多租戶場景
在講設計之前，我們先以“釘釘”為例，來看看一個 SaaS 平台是如何運作的。相信大部分B 端産品經理都體驗過釘釘，我們分兩個次元來講釘釘的租戶注冊到使用的流程。一個是從個人視角來看使用釘釘的流程，下面圖就是個人使用釘釘的流程。這個流程省略了個人注冊和其他人加好友聊天的功能，那個其實不算 B 端的業務範疇了。
這裡的關鍵是你要使用某個企業（或團隊，以下我們統一稱為租戶）下的功能，首先你需要被邀請加入某個租戶。而且，一個賬号可以被邀請加入多個租戶。如果你屬于多個租戶，那麼和某個租戶相關的操作你需要先切換到該租戶下才可以使用。比如我們的工作台、雲盤這些就和租戶有關，下面的圖就是釘釘的工作台，預設會有一個租戶，可以通過下拉方式切換租戶。
那麼從租戶的角度來說，是什麼樣的呢？流程如下圖所示。
與個人不同，對于租戶來說，多了建立團隊、企業認證和邀請成員幾個步驟。這屬于管理者類的功能，其中企業認證不是必需的，隻是經過認證的企業可用的功能和資源多一些。
通過釘釘的例子我們會得到如下的實體關系：
- 一個平台有很多個租戶；
- 一個平台也有很多使用者；
- 一個使用者屬于多個租戶，一個租戶也有很多個使用者。
這個是基礎的關系，務必要明白。是以實際上一般 SaaS 平台會有三個背景：
- 營運管理背景：即平台營運管理的背景系統，通常用于管理租戶，主要是租戶的權限、資源的配置設定管理；這個平台我們作為 SaaS 使用者是接觸不到的，但是作為 SaaS 産品設計是必不可少的。
- 租戶管理背景：即租戶使用的管理背景，主要是用于租戶的管理者管理成員和配置設定租戶内部成員的權限、資源。
- 業務應用：也就是實際租戶的各個成員使用的業務系統，比如我們平時使用的釘釘的桌面端、App 其實都算是業務應用。這個業務應用其實是有多個的。比如釘釘自帶的 OA 審批、考勤系統、智能填表等等，其實都是一個個業務應用。有些設計為了簡化，在背景系統上，會将租戶管理背景和業務應用合并為一個背景。
釘釘的團隊版是可以免費體驗的，是以如果大家有興趣可以建立團隊了解一下租戶管理背景的功能。
租戶權限和資源管理
對于一個平台，租戶是其服務的主要對象，也是最終的買單人，即 SaaS 系統的訂閱者。是以，SaaS 的營運管理背景的一個核心職能就是管理平台上的租戶的權限和資源管理。權限的管理和 SaaS 平台的訂閱模式有比較大的關系，從抽象角度上來說也可以認為是一種資源。我們常見的 SaaS 在權限這塊有兩種方式：
- 按銷售版本訂閱：這種不同的版本會有不同的功能。一般用于平台本身的業務應用是單體應用，即權限是在應用内，按租戶訂閱的版本不同配置設定不同的功能。
- 按應用訂閱：這種是平台比較大了，平台會有若幹個應用，租戶首先選擇開通平台中的某些應用。當然，應用内可以再細分出銷售版本，釘釘其實就是這種模式。這種模式比較重，但是擴充性會比較好，适用于有心建構開放應用平台的 SaaS 産品。
兩種模式的結構對比如下兩張圖所示，當然，多應用的 SaaS 平台每個應用也可以單獨再分出一層銷售版本來。
資源來說會分為兩類，一類是平台級資源，一類是應用内資源。平台級資源由平台統一管理，比如釘釘裡的釘盤容量，應用的使用期限等。應用内資源即各個應用自身的資源，比如授權使用的賬号數（當然平台級有些也會有總的賬号數限制）、短信條數等。這種資源管理的原則是誰維護誰管理，也就是平台維護的資源由平台管理，應用維護的資源由應用管理，下面是資源的關系結構圖。一般來說，資源會需要租戶購買，或者平台會定期發放免費資源（比如釘釘的“短信釘”就是按月有免費的額度可以使用）。
菜單管理
既然涉及到不同銷售版本，就會有菜單的管理，也就是需要将菜單統一管理，然後再把菜單組合成銷售版本，最後根據租戶購買的版本進行授權，最終落到客戶那邊呈現的就是可用的菜單。這裡同樣會涉及一個問題，就是菜單歸平台管還是歸應用管。這兩種模式其實作實中都有。我們遇到的平台就是平台統一管理，也就是應用首先要在平台配置菜單，這樣租戶才可以使用。個人來說，不推薦這種由平台統一管理的方式。一方面是導緻平台和應用強耦合，如果平台有第三方應用的話，意味着第三方需要和平台要同步菜單；另一方面是限制了平台的靈活性，因為既然是菜單，要統一管理就需要有一套标準的菜單管理模式，這就要求應用必須按照平台的規則來。還有一個是，平台要給應用開發者（或營運者）開放賬号管理菜單，實際上也增加了複雜度。
實際上，應用開發方也會有對應的營運團隊，平台隻需要給租戶和應用開發方提供溝通的管道就可以了。比如，租戶訂閱某個應用成功後，通知應用開發方及時維護租戶的權限即可。因為，實際 B 端企業訂閱某個應用，會有個下單付款過程，一般付款都是采用彙款的方式（我們在釘釘上購買第三方應用的時候也是單獨付款給第三方，而不是經過支付寶這類通道），這就意味着付款成功後才會介入服務。當然，也有免費提供試用期的，這個時候隻要租戶訂閱應用，應用開發方的售後團隊就可以提前介入提供服務，實際上後續付費後也能接得上。
有了菜單管理後，SaaS 的實體關系變成了下面的樣子，這裡省略了資源，實際資源和銷售版本有點類似，隻是會有平台級和應用内資源。總結來說，各個實體的關系如下：
- 一個平台會有多個應用；
- 一個應用會有多個菜單，通過菜單組合成多種銷售版本；
- 租戶屬于1個平台，租戶可以根據自身需要訂閱多個平台下的應用的某個銷售版本。
- 租戶擁有多個使用者，使用者也可以屬于多個租戶，但使用者則屬于同一個平台。
多租戶設計的核心要點
有了上面的整體概念後，我們就知道 SaaS 的多租戶設計的核心要點了，整理如下圖所示。這裡說明幾點：
- 使用者和賬号的差別：對于平台來說，注冊的賬号實際是平台使用者，要通過使用者來确定使用者的唯一性。同時，為了使用者能夠切換租戶，需要有使用者租戶管理（即使用者屬于哪些租戶）；對于租戶來說，使用者其實就是賬号，也就是我這個租戶下開通了哪些賬号，一般一個賬号就對應一個員工。需要注意的是，租戶下的賬号可以登出的（或者是禁用），比如說員工離職了，他還可以使用平台，但是無法使用該租戶下的功能。
- 訂單管理：平台、應用和租戶都能夠看到訂單，隻是範圍不同。平台管理整個平台的訂單（不包含應用内自己的資源訂單，除非平台覆寫到了應用内的交易環節），應用内管理應用自身産生的的訂單，而租戶看到的是自己的訂單。
- 租戶權限管理：平台如果是純粹的平台，那麼其實可以沒有權限管理的，但是一般 SaaS 平台不會是一個空架子，會有一個或多個核心抓手應用。這個就看平台的設計了，是一開始就把自己的應用當做第三方等同對待還是特殊處理。應用管理租戶的權限主要是銷售版本的管理，這個很多時候可以通過訂單自動同步管理。不過，要考慮特殊場景，比如租戶可能購買的是較低級版本，但是為了推廣進階版本，可能會在背景給租戶開通進階版本的試用權限。
- 租戶背景：租戶背景其實和業務應用可以混合在一起，隻是管理者的權限不同而已。租戶背景主要就是邀請成員（開賬号），進行授權管理（通常會有功能權限和資料權限），然後是自己在平台消費的資源和訂單管理，主要是購買和檢視為主。
- 業務應用：一般是基層員工用的頻次更多，對于管理層更多提供的是報表類的功能。這裡主要是能夠支援使用者切換租戶以及便于租戶下的成員使用租戶開通的業務應用功能。
多租戶的資料存儲設計
在技術上多租戶資料存儲有很三種方式，一個是共用資料表，也就是不同租戶的資料存儲在同一張資料表中，然後通過租戶 id 區分。這種适合小型的 SaaS應用，優點是開發實作簡單，缺點是不同租戶之間的操作資料會有一定的影響（因為操作的同一個資料表，如果多個租戶同時操作，會有并發性能問題）。
另一個是分表設計，即不同的租戶的資料表結構雖然相同，但是使用各自的資料表。比如說一個權限表名是 auth，那麼 A 租戶的叫 a_auth，B 租戶的叫 b_auth。這種設計需要根據租戶動态建立表，一般表名會有租戶 id 來區分唯一性。隔離程度上，比共用表好很多，複雜性也高一些，同時由于是共用了資料庫，整體性能會受資料庫性能影響，也就是租戶之間的操作還是一定程度上會互相影響。
最後一種是分庫設計，就是不同的租戶使用不同的資料庫，這樣在資料上是完全隔離的。當然，技術實作上也最複雜了。對于業務系統比較重的垂直SaaS應用，建議是按這種方式設計。因為，深入客戶業務的 SaaS 系統一般都是高頻操作，随着客戶量增加，如果不分離資料，會導緻性能瓶頸出現。
當然，實際也可以采用漸進式的資料存儲設計，即客戶少的時候使用共用資料表，客戶稍微多的時候用分表設計，最後再使用分庫設計。這種前期成本低，後期會有資料遷移成本。
總結
本篇梳理了一下 SaaS 系統的多租戶設計的結構，各類設計的特點，相信對 SaaS 産品經理會有不小的幫助。對于 SaaS 系統的設計，如果要調研複雜的 SaaS 系統，推薦大家可以體驗阿裡雲背景和釘釘，相比而言，雲廠商的背景雖然不太像 SaaS，但是基本的設計思想是一樣的，而且雲廠商的設計更為複雜一些，涵蓋了多個業務子系統和多類資源配置設定。