多租戶 SaaS 產品的數據邊界如何劃分
對于 SaaS 產品多租戶設計,某些和平臺相關的業務數據到底該放在平臺側還是租戶側才是最合適最穩妥的呢?這篇文章,我們來看看:
前天在 SaaS 架構設計交流群有群友提出來一個問題,他們的 SaaS 平臺有一個對所有商戶開放的門戶,門戶中有一個商品中心模塊,這個模塊允許所有商戶發布商品,并且發布的商品允許其他商戶查看。同時允許商戶自己在商品中心訂購商品,他糾結的是這里涉及兩部分數據,一部分數據是商戶私有的訂購數據,一部分是平臺所有商戶共享的商品數據,這兩部分數據要不要做租戶間的隔離?
對于 SaaS 產品多租戶設計,確實會經常遇到如何界定數據邊界的問題,典型的案例是做數據庫隔離設計的方案中(即每個租戶獨享一個數據庫,參考:講講 SaaS 平臺的多租戶設計),某些和平臺相關的業務數據到底該放在平臺側還是租戶側。本篇分享一下個人對這種多租戶設計的數據邊界的個人理解。
一、基本原則
先說一個基本原則,這個也應該是 SaaS 產品劃分數據邊界的首要原則,那就是“以不影響租戶業務運行為首要原則”。聽起來比較難理解,我們來看一般 SaaS 產品的數據和應用支撐形式。
如上圖所示,通常 SaaS 產品會分為租戶應用和平臺側應用,其中租戶應用也就是租戶日常使用的各類業務應用,平臺側應用主要是給 SaaS 企業自己運營使用。平臺側應用通常只會使用平臺數據,如果需要租戶數據(比如對租戶的日常使用進行埋點分析)也應該是將這些數據放到平臺側來存儲。租戶應用則主要是使用租戶自有的數據庫,但是也有可能會使用部分平臺數據,比如一些整個平臺通用的數據(例如字典數據)。
這里平臺數據通常會是單獨的數據庫服務器存儲,這就會產生一個問題,如果平臺數據庫服務器出現故障,就有可能導致租戶的業務受影響。因此,我們應當盡可能降低這種風險,而降低這種風險最有效的手段就是盡量讓租戶應用少依賴平臺數據,甚至是不依賴。
二、實際案例
我們來看一個具體的案例,在涉及在線支付的業務中(例如電商 SaaS,商戶可以在線銷售商品給 C 端用戶),每個租戶都會有自己支付參數(如支付渠道、商戶號、密鑰等等)。系統自然會對接多家支付渠道,因此會有一個支付中心(技術上叫支付網關,參考:接一個第三方支付,開發說要2個月?)。在租戶支付的時候,從簡化支付中心設計來說,可以將每個租戶的支付參數存儲在平臺數據中,這樣就不需要分租戶從不同的數據庫讀取支付參數。然而,這里有個問題,就是如果平臺數據庫出現問題,意味著整個 SaaS 平臺的所有租戶的在線支付業務都會受影響。這種事情出現的概率雖然低,但是只要出現一次都會造成無法挽回的損失 —— 大家可以想象一下,假設支付寶出現故障,會給淘寶的交易額帶來多大的損失。
所以說,雖然我們說要追求簡潔的設計、降低成本,但是也要考慮風險,尤其是那種可能導致所有租戶業務受阻的重大風險。這也是我之前在一篇文章中說過的,SaaS 產品要追求穩定性。
那么像上面這種情況怎么處理呢?我們說“不要將所有雞蛋放到1個籃子里”,這個原則對于 SaaS 產品同樣適用。我們可以將這些支付參數分別放到租戶數據中,雖然支付中心的設計開發變得復雜了,但是單個租戶數據庫出現問題只會影響該租戶自身,而不會影響其他租戶。這樣的話,實際上就是將大的風險給分化了,可以降低整個 SaaS 平臺的風險,提高穩定性。
三、如何劃分數據邊界
通過前面講的原則和例子,我們在具體設計 SaaS產品數據層的時候,就可以判斷該如何劃分數據邊界了。當數據可放在租戶側也可放在平臺側的時候,我們要考慮是響應數據庫出現故障的風險,選擇風險低、出故障后影響面小的方案。
再回到開篇講的問題,實際上這個問題和數據隔離并沒有太大關系,因為商品中心和商戶訂購數據(即訂單)本質上其實是平臺為租戶提供的撮合交易服務。這種情況下,平臺其實就類似閑魚,而商戶就是閑魚的用戶。閑魚的用戶發布的商品數據自然是統一放到平臺側的,這樣平臺才方便對所有其他用戶展示和篩選。對于用戶自己購買的商品訂單,平臺開放訂單管理功能供用戶查看即可。
這個問題里,實際上要搞清楚的是兩個問題:平臺商戶能查看哪些數據?能管理哪些數據?比如商品中心的數據允許所有商戶查看,比如商家自己發布的商品允許管理(編輯、上下架、刪除等),比如可以管理自己的訂單(取消、支付、評價等)。
四、總結
SaaS 產品因為是服務于企業客戶,也就意味著我們平臺上面的企業的日常業務運轉依賴于我們的產品。一旦我們的產品出現了問題,有可能大面積地影響到客戶的業務運轉。因此,追求產品穩定運行是 SaaS 產品應該優先追求的目標。對于數據邊界的劃分,同樣也應該遵循追求穩定、降低風險的原則。
專欄作家
產品海豚灣,公眾號:產品海豚灣(ID:pm-dophin-bay),人人都是產品經理專欄作家。技術出身的產品經理,從事過 C 端產品和 B 端產品設計,擅長 SaaS 產品設計、產品架構設計和需求分析。負責的B 端產品完成了完整的從0到1,從1到 N 的過程,成功簽約行業百強客戶。
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!