當(dāng)業(yè)務(wù)規(guī)模比較小、系統(tǒng)復(fù)雜度不高時(shí)，運(yùn)維、測(cè)試、數(shù)據(jù)分析、管理等支撐功能主要由各系統(tǒng)或者團(tuán)隊(duì)獨(dú)立完成。

低代碼系統(tǒng)建設(shè)的核心是快速構(gòu)建不同的行業(yè)應(yīng)用，如果各個(gè)行業(yè)應(yīng)用都采取各自為政的方式來(lái)實(shí)現(xiàn)這些支撐功能，會(huì)發(fā)現(xiàn)重復(fù)工作非常多。

所以在建立低代碼平臺(tái)的核心能力包括兩方面：

• 平臺(tái)能力（穩(wěn)態(tài)）：抽象可復(fù)用的能力和模型，如用戶體系、協(xié)同能力、知識(shí)庫(kù)能力，各個(gè)應(yīng)用圍繞這個(gè)平臺(tái)能力做好應(yīng)用擴(kuò)展。
• 應(yīng)用擴(kuò)展適應(yīng)能力（敏態(tài)）：基于收斂的平臺(tái)能力，根據(jù)各行業(yè)在數(shù)據(jù)管理模型、業(yè)務(wù)流程多變的特點(diǎn)，搭建一套動(dòng)態(tài)模型擴(kuò)展，動(dòng)態(tài)流程擴(kuò)展的應(yīng)用開(kāi)發(fā)平臺(tái)。

今天我們主要來(lái)講解低代碼如何設(shè)計(jì)平臺(tái)能力。

多產(chǎn)品、多租戶能力

在第一章文章中，我們描述了老板的需求，他希望公司有多個(gè)低代碼產(chǎn)品，“xx文檔”，“xxBI”，“xx協(xié)同”，同時(shí)，這幾個(gè)產(chǎn)品要具備統(tǒng)一的企業(yè)權(quán)限管理能力（收費(fèi)能力）。

我們把需求用例細(xì)化下：

企業(yè)注冊(cè)場(chǎng)景

1. 個(gè)人注冊(cè)
2. 填寫企業(yè)信息，創(chuàng)建企業(yè)
3. 當(dāng)前企業(yè)管理員默認(rèn)為當(dāng)前創(chuàng)建人
4. 員工邀請(qǐng)同事加入企業(yè)（短信、郵件、鏈接）
5. 受邀人根據(jù)鏈接，并驗(yàn)證手機(jī)號(hào)碼并加入企業(yè)（無(wú)賬號(hào)自動(dòng)注冊(cè)）

員工切換企業(yè)場(chǎng)景

1. 員工登錄默認(rèn)使用上次登錄的企業(yè)信息，無(wú)則使用第一個(gè)企業(yè)信息；
2. 獲取當(dāng)前賬號(hào)在當(dāng)前企業(yè)可以使用的產(chǎn)品及功能權(quán)限；
3. 員工通過(guò)個(gè)人信息切換企業(yè)；
4. 功能菜單刷新，重新獲取當(dāng)前賬號(hào)在當(dāng)前企業(yè)可以使用的產(chǎn)品及功能權(quán)限；

基礎(chǔ)實(shí)體關(guān)系

通過(guò)以上用例，我們可以總結(jié)出如上實(shí)體關(guān)系：

• 一個(gè)平臺(tái)有很多個(gè)企業(yè)（租戶）；
• 一個(gè)平臺(tái)也有很多用戶；
• 一個(gè)用戶屬于多個(gè)企業(yè)（租戶），一個(gè)企業(yè)（租戶）也有很多個(gè)用戶。

這個(gè)是基礎(chǔ)的關(guān)系。所以實(shí)際上一般 SaaS 平臺(tái)會(huì)有三個(gè)后臺(tái)：

1. 運(yùn)營(yíng)管理后臺(tái)：即平臺(tái)運(yùn)營(yíng)管理的后臺(tái)系統(tǒng)，通常用于管理租戶，主要是租戶的權(quán)限、資源的分配管理；這個(gè)平臺(tái)我們作為 SaaS 用戶是接觸不到的，但是作為 SaaS 產(chǎn)品設(shè)計(jì)是必不可少的。
2. 租戶管理后臺(tái)：即租戶使用的管理后臺(tái)，主要是用于租戶的管理員管理成員和分配租戶內(nèi)部成員的權(quán)限、資源。
3. 業(yè)務(wù)產(chǎn)品應(yīng)用：也就是實(shí)際租戶的各個(gè)成員使用的業(yè)務(wù)系統(tǒng)，我們以釘釘舉例，比如我們平時(shí)使用的釘釘?shù)淖烂娑恕pp 其實(shí)都算是業(yè)務(wù)應(yīng)用。這個(gè)業(yè)務(wù)應(yīng)用其實(shí)是有多個(gè)的。比如釘釘自帶的 OA 審批、考勤系統(tǒng)、智能填表等等，其實(shí)都是一個(gè)個(gè)業(yè)務(wù)應(yīng)用。有些設(shè)計(jì)為了簡(jiǎn)化，在后臺(tái)系統(tǒng)上，會(huì)將租戶管理后臺(tái)和業(yè)務(wù)應(yīng)用合并為一個(gè)后臺(tái)。

租戶權(quán)限管理設(shè)計(jì)

對(duì)于一個(gè)平臺(tái)，租戶是其服務(wù)的主要對(duì)象，也是最終的買單人，即 SaaS 系統(tǒng)的訂閱者。因此，SaaS 的運(yùn)營(yíng)管理后臺(tái)的一個(gè)核心職能就是管理平臺(tái)上的租戶的權(quán)限和資源管理。

平臺(tái)會(huì)有若干個(gè)產(chǎn)品應(yīng)用，租戶首先選擇開(kāi)通平臺(tái)中的某些應(yīng)用。當(dāng)然，應(yīng)用內(nèi)可以再細(xì)分出銷售版本。

應(yīng)用租戶關(guān)系

菜單管理

菜單是產(chǎn)品中最核心的資源，菜單的創(chuàng)建模式包括兩類：

• 產(chǎn)品功能菜單，如BI產(chǎn)品的視圖配置功能，數(shù)據(jù)集管理功能，都屬于產(chǎn)品功能菜單，這些功能是可以納入產(chǎn)品的銷售能力范圍；
• 用戶菜單，如一篇文章，一個(gè)表單，這部分菜單所有權(quán)屬于產(chǎn)品應(yīng)用本身，由菜單所有者分配共享權(quán)限，例如我們?cè)?span id="2jygfj8" class="candidate-entity-word" data-gid="3182073">企業(yè)微信創(chuàng)建的一個(gè)表格，可以共享給哪些同事共享編輯或者企業(yè)的某個(gè)部門同事只讀訪問(wèn)；

講完這里，我們可以看到我們的實(shí)體模型關(guān)系如下：

• 一個(gè)平臺(tái)會(huì)有多個(gè)產(chǎn)品；
• 一個(gè)產(chǎn)品會(huì)有多個(gè)菜單，通過(guò)菜單組合成多種銷售版本；
• 一個(gè)產(chǎn)品下，用戶會(huì)創(chuàng)建多個(gè)用戶菜單（表單、文章），菜單可以打包成多個(gè)權(quán)限組（只讀，維護(hù)，列權(quán)限）
• 用戶菜單權(quán)限組可以分配給多個(gè)用戶；
• 企業(yè)屬于1個(gè)平臺(tái)，企業(yè)可以根據(jù)自身需要訂閱多個(gè)平臺(tái)下的產(chǎn)品的某個(gè)銷售版本。
• 企業(yè)擁有多個(gè)用戶，用戶也可以屬于多個(gè)企業(yè)，但用戶則屬于同一個(gè)平臺(tái)。

平臺(tái)核心資源模型

角色管理

為了方便的管菜單資源的人員分配，我們引入了角色，把多個(gè)用戶納入一個(gè)角色，方便分配菜單權(quán)限。

這里需要注意的是，產(chǎn)品包括了兩類菜單，兩類菜單的管理方式就分成兩個(gè)場(chǎng)景：

1. 在租戶管理后臺(tái)中，企業(yè)管理員需要根據(jù)業(yè)務(wù)管理需要，分配不同的管理角色來(lái)管理不同的產(chǎn)品能力。
2. 在業(yè)務(wù)產(chǎn)品應(yīng)用，內(nèi)容發(fā)布者可以選擇企業(yè)通訊錄中的角色或者員工進(jìn)行內(nèi)容授權(quán)。

針對(duì)以上場(chǎng)景，我們的角色模型如下：

• 一個(gè)企業(yè)的通訊錄下有多個(gè)業(yè)務(wù)角色；
• 一個(gè)業(yè)務(wù)角色包括多個(gè)員工；
• 用戶菜單可以分配個(gè)多個(gè)業(yè)務(wù)角色，業(yè)務(wù)角色可以綁定多個(gè)用戶菜單；
• 一個(gè)企業(yè)可以有多個(gè)產(chǎn)品管理角色；
• 產(chǎn)品管理員角色可以管理當(dāng)前企業(yè)被授權(quán)的產(chǎn)品功能域內(nèi)的產(chǎn)品功能；

角色模型

多租戶數(shù)據(jù)隔離

目前SAAS的租戶數(shù)據(jù)隔離方案包括以下三種方案：

1. 獨(dú)立數(shù)據(jù)庫(kù)系統(tǒng)：成本高，支持租戶數(shù)量少，隔離級(jí)別最高，安全性最好，能夠滿足不同租戶的獨(dú)特需求，出現(xiàn)故障時(shí)恢復(fù)數(shù)據(jù)比較容易恢復(fù)；
2. 共享數(shù)據(jù)庫(kù)，獨(dú)立表空間：成本中，支持租戶數(shù)量較多，提供了一定程度的邏輯數(shù)據(jù)隔離，一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)可支持多個(gè)租戶，出現(xiàn)故障的情況下，數(shù)據(jù)恢復(fù)相對(duì)而言比較復(fù)雜；
3. 按租戶id字段區(qū)分：成本低，支持租戶數(shù)量較多，維護(hù)和購(gòu)置成本最低，每個(gè)數(shù)據(jù)庫(kù)能夠支持的租戶數(shù)量最多，隔離級(jí)別最低，安全性也最低，數(shù)據(jù)備份和恢復(fù)非常復(fù)雜，需要逐表逐條備份和還原；

在低代碼平臺(tái)中，相對(duì)以上模型，我們對(duì)產(chǎn)品做了衍生：

• 產(chǎn)品：由平臺(tái)或供應(yīng)商提供能力；
• 應(yīng)用：由企業(yè)通過(guò)產(chǎn)品提供的能力自主創(chuàng)建，例如企業(yè)根據(jù)我們的BI平臺(tái)創(chuàng)建了兩個(gè)應(yīng)用，“財(cái)務(wù)運(yùn)營(yíng)分析”和“項(xiàng)目管理分析”，員工可以分別進(jìn)入不同的應(yīng)用進(jìn)行自己的菜單構(gòu)建設(shè)計(jì)。

由于產(chǎn)品的生命周期由平臺(tái)或供應(yīng)商管理，所以我們每個(gè)產(chǎn)品的數(shù)據(jù)源都采用獨(dú)立數(shù)據(jù)庫(kù)系統(tǒng)建立，原則上不同產(chǎn)品在數(shù)據(jù)共享上無(wú)數(shù)據(jù)庫(kù)級(jí)別依賴需求，應(yīng)用依賴通過(guò)接口調(diào)用實(shí)現(xiàn)；

應(yīng)用屬于企業(yè)通過(guò)零代碼構(gòu)建，所以應(yīng)用的數(shù)據(jù)源我們默認(rèn)會(huì)共享平臺(tái)數(shù)據(jù)庫(kù)，按應(yīng)用ID建立不同的表空間，當(dāng)然也提供高級(jí)配置，可以多個(gè)應(yīng)用共享一個(gè)表空間。

在我們的部分非低代碼SAAS產(chǎn)品中，一般采用方案三較多，當(dāng)然會(huì)根據(jù)客戶等級(jí)進(jìn)行調(diào)整。

產(chǎn)品應(yīng)用分庫(kù)方案

平臺(tái)能力

前面我們講了平臺(tái)的模型及平臺(tái)管理能力，即平臺(tái)運(yùn)營(yíng)管理的后臺(tái)系統(tǒng)，通常用于管理租戶，主要是租戶的權(quán)限、資源的分配管理，這部分屬于核心運(yùn)營(yíng)支撐能力；

核心運(yùn)營(yíng)支撐能力

企業(yè)通訊錄管理

同時(shí)，我們?yōu)榱烁玫倪\(yùn)營(yíng)低代碼平臺(tái)，需要提供一部分輔助支撐能力，如：統(tǒng)一認(rèn)證、消息系統(tǒng)、幫助中心、素材庫(kù)、API能力管理。

統(tǒng)一認(rèn)證登錄

文檔中心

素材庫(kù)

API&測(cè)試用例

從技術(shù)架構(gòu)設(shè)計(jì)上，為了規(guī)范各產(chǎn)品之間的協(xié)同和統(tǒng)一，降低集成復(fù)雜度，提升用戶體驗(yàn)，在企業(yè)、產(chǎn)品、資源、用戶模型上，我們可以擴(kuò)展消息模型、工單模型、SNS模型，需要根據(jù)產(chǎn)品的演進(jìn)路線逐步進(jìn)行歸納統(tǒng)一。沒(méi)有完美的架構(gòu)，只有不斷演進(jìn)的架構(gòu)。