• 小螞蟻站長吧-互聯網運營、增長黑客學習交流平臺

    您好,歡迎訪問小螞蟻站長吧!

    多租戶場景下的 SaaS 平臺,該怎么設計?

    2022-12-06 00:00分類:產品設計 閱讀:

     

    很多人對 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 的實業瓜葛變成了下邊的樣子,這邊自治區略了資源,求實資源和行銷本版有點類似,只是會有平臺級和應用內資源。點題來說,各類實業的干系如下:

    • 一個平臺會有多個應用;
    • 一個應用會有多個菜單,通過菜單組合成多種銷行本子;
    • 租戶屬于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,但是基本的設計思維是一樣的,而且云廠商的設計更為復雜一些,涵蓋了多個業務子戰線和多類資源分配。

    上一篇: O2O電商支付清結算體系概述

    下一篇: 微信遺憾更新盤點:曾一夜之間引爆朋友圈

    相關推薦
    ?
    返回頂部
    日韩在线精品视频a