低代碼設計教程（三）-管理平臺（低代碼平臺的設計與實現(xiàn)）
當業(yè)務規(guī)模比較小、系統(tǒng)復雜度不高時，運維、測試、數(shù)據(jù)分析、管理等支撐功能主要由各系統(tǒng)或者團隊獨立完成。
低代碼系統(tǒng)建設的核心是快速構建不同的行業(yè)應用，如果各個行業(yè)應用都采取各自為政的方式來實現(xiàn)這些支撐功能，會發(fā)現(xiàn)重復工作非常多。
所以在建立低代碼平臺的核心能力包括兩方面：
- 平臺能力（穩(wěn)態(tài)）：抽象可復用的能力和模型，如用戶體系、協(xié)同能力、知識庫能力，各個應用圍繞這個平臺能力做好應用擴展。
- 應用擴展適應能力（敏態(tài)）：基于收斂的平臺能力，根據(jù)各行業(yè)在數(shù)據(jù)管理模型、業(yè)務流程多變的特點，搭建一套動態(tài)模型擴展，動態(tài)流程擴展的應用開發(fā)平臺。
今天我們主要來講解低代碼如何設計平臺能力。
多產(chǎn)品、多租戶能力
在第一章文章中，我們描述了老板的需求，他希望公司有多個低代碼產(chǎn)品，“xx文檔”，“xxBI”，“xx協(xié)同”，同時，這幾個產(chǎn)品要具備統(tǒng)一的企業(yè)權限管理能力（收費能力）。
我們把需求用例細化下：
企業(yè)注冊場景
- 個人注冊
- 填寫企業(yè)信息，創(chuàng)建企業(yè)
- 當前企業(yè)管理員默認為當前創(chuàng)建人
- 員工邀請同事加入企業(yè)（短信、郵件、鏈接）
- 受邀人根據(jù)鏈接，并驗證手機號碼并加入企業(yè)（無賬號自動注冊）
員工切換企業(yè)場景
- 員工登錄默認使用上次登錄的企業(yè)信息，無則使用第一個企業(yè)信息；
- 獲取當前賬號在當前企業(yè)可以使用的產(chǎn)品及功能權限；
- 員工通過個人信息切換企業(yè)；
- 功能菜單刷新，重新獲取當前賬號在當前企業(yè)可以使用的產(chǎn)品及功能權限；
基礎實體關系
通過以上用例，我們可以總結出如上實體關系：
- 一個平臺有很多個企業(yè)（租戶）；
- 一個平臺也有很多用戶；
- 一個用戶屬于多個企業(yè)（租戶），一個企業(yè)（租戶）也有很多個用戶。
這個是基礎的關系。所以實際上一般 SaaS 平臺會有三個后臺：
- 運營管理后臺：即平臺運營管理的后臺系統(tǒng)，通常用于管理租戶，主要是租戶的權限、資源的分配管理；這個平臺我們作為 SaaS 用戶是接觸不到的，但是作為 SaaS 產(chǎn)品設計是必不可少的。
- 租戶管理后臺：即租戶使用的管理后臺，主要是用于租戶的管理員管理成員和分配租戶內部成員的權限、資源。
- 業(yè)務產(chǎn)品應用：也就是實際租戶的各個成員使用的業(yè)務系統(tǒng)，我們以釘釘舉例，比如我們平時使用的釘釘?shù)淖烂娑?、App 其實都算是業(yè)務應用。這個業(yè)務應用其實是有多個的。比如釘釘自帶的 OA 審批、考勤系統(tǒng)、智能填表等等，其實都是一個個業(yè)務應用。有些設計為了簡化，在后臺系統(tǒng)上，會將租戶管理后臺和業(yè)務應用合并為一個后臺。
租戶權限管理設計
對于一個平臺，租戶是其服務的主要對象，也是最終的買單人，即 SaaS 系統(tǒng)的訂閱者。因此，SaaS 的運營管理后臺的一個核心職能就是管理平臺上的租戶的權限和資源管理。
平臺會有若干個產(chǎn)品應用，租戶首先選擇開通平臺中的某些應用。當然，應用內可以再細分出銷售版本。
應用租戶關系
菜單管理
菜單是產(chǎn)品中最核心的資源，菜單的創(chuàng)建模式包括兩類：
- 產(chǎn)品功能菜單，如BI產(chǎn)品的視圖配置功能，數(shù)據(jù)集管理功能，都屬于產(chǎn)品功能菜單，這些功能是可以納入產(chǎn)品的銷售能力范圍；
- 用戶菜單，如一篇文章，一個表單，這部分菜單所有權屬于產(chǎn)品應用本身，由菜單所有者分配共享權限，例如我們在企業(yè)微信創(chuàng)建的一個表格，可以共享給哪些同事共享編輯或者企業(yè)的某個部門同事只讀訪問；
講完這里，我們可以看到我們的實體模型關系如下：
- 一個平臺會有多個產(chǎn)品；
- 一個產(chǎn)品會有多個菜單，通過菜單組合成多種銷售版本；
- 一個產(chǎn)品下，用戶會創(chuàng)建多個用戶菜單（表單、文章），菜單可以打包成多個權限組（只讀，維護，列權限）
- 用戶菜單權限組可以分配給多個用戶；
- 企業(yè)屬于1個平臺，企業(yè)可以根據(jù)自身需要訂閱多個平臺下的產(chǎn)品的某個銷售版本。
- 企業(yè)擁有多個用戶，用戶也可以屬于多個企業(yè)，但用戶則屬于同一個平臺。
平臺核心資源模型
角色管理
為了方便的管菜單資源的人員分配，我們引入了角色，把多個用戶納入一個角色，方便分配菜單權限。
這里需要注意的是，產(chǎn)品包括了兩類菜單，兩類菜單的管理方式就分成兩個場景：
- 在租戶管理后臺中，企業(yè)管理員需要根據(jù)業(yè)務管理需要，分配不同的管理角色來管理不同的產(chǎn)品能力。
- 在業(yè)務產(chǎn)品應用，內容發(fā)布者可以選擇企業(yè)通訊錄中的角色或者員工進行內容授權。
針對以上場景，我們的角色模型如下：
- 一個企業(yè)的通訊錄下有多個業(yè)務角色；
- 一個業(yè)務角色包括多個員工；
- 用戶菜單可以分配個多個業(yè)務角色，業(yè)務角色可以綁定多個用戶菜單；
- 一個企業(yè)可以有多個產(chǎn)品管理角色；
- 產(chǎn)品管理員角色可以管理當前企業(yè)被授權的產(chǎn)品功能域內的產(chǎn)品功能；
角色模型
多租戶數(shù)據(jù)隔離
目前SAAS的租戶數(shù)據(jù)隔離方案包括以下三種方案：
- 獨立數(shù)據(jù)庫系統(tǒng)：成本高，支持租戶數(shù)量少，隔離級別最高，安全性最好，能夠滿足不同租戶的獨特需求，出現(xiàn)故障時恢復數(shù)據(jù)比較容易恢復；
- 共享數(shù)據(jù)庫，獨立表空間：成本中，支持租戶數(shù)量較多，提供了一定程度的邏輯數(shù)據(jù)隔離，一個數(shù)據(jù)庫系統(tǒng)可支持多個租戶，出現(xiàn)故障的情況下，數(shù)據(jù)恢復相對而言比較復雜；
- 按租戶id字段區(qū)分：成本低，支持租戶數(shù)量較多，維護和購置成本最低，每個數(shù)據(jù)庫能夠支持的租戶數(shù)量最多，隔離級別最低，安全性也最低，數(shù)據(jù)備份和恢復非常復雜，需要逐表逐條備份和還原；
在低代碼平臺中，相對以上模型，我們對產(chǎn)品做了衍生：
- 產(chǎn)品：由平臺或供應商提供能力；
- 應用：由企業(yè)通過產(chǎn)品提供的能力自主創(chuàng)建，例如企業(yè)根據(jù)我們的BI平臺創(chuàng)建了兩個應用，“財務運營分析”和“項目管理分析”，員工可以分別進入不同的應用進行自己的菜單構建設計。
由于產(chǎn)品的生命周期由平臺或供應商管理，所以我們每個產(chǎn)品的數(shù)據(jù)源都采用獨立數(shù)據(jù)庫系統(tǒng)建立，原則上不同產(chǎn)品在數(shù)據(jù)共享上無數(shù)據(jù)庫級別依賴需求，應用依賴通過接口調用實現(xiàn)；
應用屬于企業(yè)通過零代碼構建，所以應用的數(shù)據(jù)源我們默認會共享平臺數(shù)據(jù)庫，按應用ID建立不同的表空間，當然也提供高級配置，可以多個應用共享一個表空間。
在我們的部分非低代碼SAAS產(chǎn)品中，一般采用方案三較多，當然會根據(jù)客戶等級進行調整。
產(chǎn)品應用分庫方案
平臺能力
前面我們講了平臺的模型及平臺管理能力，即平臺運營管理的后臺系統(tǒng)，通常用于管理租戶，主要是租戶的權限、資源的分配管理，這部分屬于核心運營支撐能力；
核心運營支撐能力
企業(yè)通訊錄管理
同時，我們?yōu)榱烁玫倪\營低代碼平臺，需要提供一部分輔助支撐能力，如：統(tǒng)一認證、消息系統(tǒng)、幫助中心、素材庫、API能力管理。
統(tǒng)一認證登錄
文檔中心
素材庫
API&測試用例
從技術架構設計上，為了規(guī)范各產(chǎn)品之間的協(xié)同和統(tǒng)一，降低集成復雜度，提升用戶體驗，在企業(yè)、產(chǎn)品、資源、用戶模型上，我們可以擴展消息模型、工單模型、SNS模型，需要根據(jù)產(chǎn)品的演進路線逐步進行歸納統(tǒng)一。沒有完美的架構，只有不斷演進的架構。
