今天再寫(xiě)一篇文章，談下最近進(jìn)行低代碼開(kāi)發(fā)平臺(tái)產(chǎn)品架構(gòu)設(shè)計(jì)和研發(fā)實(shí)踐過(guò)程中的一些關(guān)鍵點(diǎn)的思考。在前面寫(xiě)過(guò)的關(guān)于低代碼開(kāi)發(fā)平臺(tái)的文章中，基本已經(jīng)將平臺(tái)本身的核心架構(gòu)和建模思路表達(dá)清楚，在這里不再重復(fù)敘述。

前兩天我準(zhǔn)備華南CIO大會(huì)關(guān)于從數(shù)字化轉(zhuǎn)型到云原生的主題演講材料，里面一篇材料涉及到低代碼開(kāi)發(fā)平臺(tái)。

在這頁(yè)P(yáng)PT里面繼續(xù)強(qiáng)調(diào)我們實(shí)際做的是面向企業(yè)的低代碼開(kāi)發(fā)平臺(tái)而非零代碼開(kāi)發(fā)平臺(tái)，特別是在規(guī)則引擎方面的技術(shù)沒(méi)有得到實(shí)質(zhì)性突破的時(shí)候，軟件研發(fā)沒(méi)有銀彈，復(fù)雜規(guī)則仍然需要自己開(kāi)發(fā)。也就是整個(gè)平臺(tái)更多是參考類(lèi)似Mendix的架構(gòu)設(shè)計(jì)思路進(jìn)行。

在云原生里面有一個(gè)核心技術(shù)實(shí)踐即ServerLess無(wú)服務(wù)器架構(gòu)，該架構(gòu)將應(yīng)用的開(kāi)發(fā)分為了BaaS后端即服務(wù)和FaaS函數(shù)即服務(wù)兩層，并提出一個(gè)核心思路就是在BaaS服務(wù)積累得足夠好的時(shí)候，你開(kāi)發(fā)應(yīng)用更多僅僅是前端函數(shù)或腳本的編寫(xiě)，和對(duì)后端BaaS提供的API服務(wù)接口能力的組裝。

這個(gè)思路本身就是低代碼開(kāi)發(fā)，是云原生實(shí)踐下推薦的一種低代碼開(kāi)發(fā)的思路。

其次任何一個(gè)應(yīng)用系統(tǒng)應(yīng)該考慮解耦，微服務(wù)化，包括和底層技術(shù)平臺(tái)的云化，那么低代碼開(kāi)發(fā)平臺(tái)本身也應(yīng)該是微服務(wù)架構(gòu)，遵從基本的分層架構(gòu)原則。低代碼平臺(tái)本身就應(yīng)該分布式，可彈性擴(kuò)展，這也是開(kāi)發(fā)出高可用高性能的應(yīng)用的基礎(chǔ)。

如果一個(gè)企業(yè)只是想快速開(kāi)發(fā)一個(gè)類(lèi)似周報(bào)填寫(xiě)，考勤記錄的簡(jiǎn)單應(yīng)用，那么當(dāng)前主流的低代碼SaaS服務(wù)平臺(tái)基本都能滿足需求而且可以做到完全的零代碼化。但是如果你是要開(kāi)發(fā)一個(gè)類(lèi)似企業(yè)內(nèi)部的業(yè)務(wù)系統(tǒng)，這個(gè)系統(tǒng)可能上萬(wàn)人使用，上千的秒級(jí)并發(fā)量，即使是一個(gè)簡(jiǎn)單的OA系統(tǒng)也不是一般的低代碼平臺(tái)能搞定的事情。

所以你做一個(gè)低代碼開(kāi)發(fā)平臺(tái)，不要將重心僅僅放在可視化表單設(shè)計(jì)，可視化流程設(shè)計(jì)，拖拽式的配置層面，這些雖然很重要，但是對(duì)于企業(yè)級(jí)的低代碼平臺(tái)來(lái)說(shuō)不是重點(diǎn)，底層技術(shù)架構(gòu)本身的高可靠，可擴(kuò)展才是重點(diǎn)。

再次，企業(yè)本身又遺留IT系統(tǒng)，這個(gè)時(shí)候低代碼開(kāi)發(fā)平臺(tái)如何切入？如何確保低代碼開(kāi)發(fā)平臺(tái)開(kāi)發(fā)完成的應(yīng)用能夠和已有的IT業(yè)務(wù)系統(tǒng)很好地融合和集成？

當(dāng)前很多低代碼開(kāi)發(fā)平臺(tái)都沒(méi)有考慮這個(gè)問(wèn)題點(diǎn)，更多開(kāi)發(fā)的都是一個(gè)個(gè)獨(dú)立的信息孤島，而無(wú)法很好地和其它已有業(yè)務(wù)系統(tǒng)打通，形成集成和協(xié)同。如果按這個(gè)思路去不斷地開(kāi)發(fā)配置應(yīng)用，那么后續(xù)開(kāi)發(fā)完成的應(yīng)用的集成和管控將是大問(wèn)題。

我今天做的關(guān)于低代碼開(kāi)發(fā)平臺(tái)架構(gòu)設(shè)計(jì)和實(shí)踐的思考，也正是基于以上的前提展開(kāi)，在今天的思考里面重點(diǎn)談以下幾個(gè)方面的內(nèi)容。

• 多租戶架構(gòu)
• 技術(shù)服務(wù)平臺(tái)和集成
• 基于API的規(guī)則定制
• 門(mén)戶和應(yīng)用集成

低代碼平臺(tái)的多租戶架構(gòu)

低代碼平臺(tái)里面的多租戶需要從兩個(gè)層面來(lái)談，第一個(gè)是低代碼平臺(tái)本身的多租戶架構(gòu)設(shè)計(jì)，其次是低代碼平臺(tái)開(kāi)發(fā)完成的應(yīng)用多租戶問(wèn)題。

先談第一個(gè)問(wèn)題。

低代碼開(kāi)發(fā)平臺(tái)本身的多租戶問(wèn)題，這個(gè)問(wèn)題實(shí)際比較復(fù)雜，如果是SaaS層面的低代碼需要考慮甲方企業(yè)和企業(yè)內(nèi)部開(kāi)發(fā)團(tuán)隊(duì)兩次的多租戶的數(shù)據(jù)隔離。即使是部署到企業(yè)內(nèi)部的私有云部署，也需要考慮企業(yè)是否存在子公司的情況。

不同的子組織，開(kāi)發(fā)團(tuán)隊(duì)上來(lái)，應(yīng)該只能夠看到自己開(kāi)發(fā)和設(shè)計(jì)的應(yīng)用，而無(wú)法看到其它應(yīng)用。這就類(lèi)似張三和李四開(kāi)發(fā)SRM和CRM兩個(gè)應(yīng)用系統(tǒng)一樣。

張三來(lái)說(shuō)開(kāi)發(fā)SRM，那么李四設(shè)計(jì)的CRM系統(tǒng)里面的對(duì)象，界面，流程模型等應(yīng)該對(duì)張三不可見(jiàn)，張三也無(wú)法隨意使用CRM系統(tǒng)的數(shù)據(jù)對(duì)象。如果張三需要CRM系統(tǒng)里面的客戶數(shù)據(jù)，那么也需要走開(kāi)放的API接口調(diào)用。

也就是SRM和CRM兩個(gè)系統(tǒng)，不僅僅是在開(kāi)發(fā)階段對(duì)應(yīng)開(kāi)發(fā)人員來(lái)說(shuō)數(shù)據(jù)是隔離的，對(duì)于開(kāi)發(fā)完成最終上線的應(yīng)用來(lái)說(shuō)，數(shù)據(jù)也是隔離的。

再談第二個(gè)問(wèn)題開(kāi)發(fā)完成的應(yīng)用隔離。

對(duì)于獨(dú)立開(kāi)發(fā)的CRM和SRM兩個(gè)應(yīng)用，你如何進(jìn)行應(yīng)用部署交付？一種方法就是完全獨(dú)占資源進(jìn)行部署，兩個(gè)應(yīng)用都采用獨(dú)立的數(shù)據(jù)庫(kù)實(shí)例，獨(dú)立的應(yīng)用中間件容器，分別進(jìn)行部署，相互之間也完全獨(dú)立自治和解耦。

還有一種思路就是類(lèi)似SaaS多租戶架構(gòu)設(shè)計(jì)一樣，開(kāi)發(fā)完成的應(yīng)用最終都在一個(gè)大的數(shù)據(jù)庫(kù)里面，只是通過(guò)類(lèi)似Org_ID組織ID或租戶ID進(jìn)行數(shù)據(jù)邏輯隔離?；蛘咴谝粋€(gè)大的數(shù)據(jù)庫(kù)中企業(yè)不同的Schema來(lái)進(jìn)行隔離。

那么如何選擇？

簡(jiǎn)單來(lái)說(shuō)就是開(kāi)發(fā)大的應(yīng)用一定是要獨(dú)立部署資源完全隔離，但是如果你是開(kāi)發(fā)的一個(gè)小應(yīng)用那么完全可以采用多租戶架構(gòu)思路一個(gè)大數(shù)據(jù)庫(kù)并進(jìn)行數(shù)據(jù)邏輯隔離即可。

最后，低代碼平臺(tái)本身還會(huì)用到流程引擎，類(lèi)似消息，緩存各種技術(shù)服務(wù)能力。那么這些技術(shù)服務(wù)能力本身也需要是多租戶架構(gòu)，做到數(shù)據(jù)隔離。這個(gè)租戶不是在組織或開(kāi)發(fā)團(tuán)隊(duì)層面，而是需要到具體的一個(gè)個(gè)業(yè)務(wù)系統(tǒng)層面。每個(gè)業(yè)務(wù)系統(tǒng)才是最底層最細(xì)化的租戶。

技術(shù)平臺(tái)和服務(wù)集成

技術(shù)平臺(tái)和技術(shù)服務(wù)能力提供，技術(shù)服務(wù)的集成是企業(yè)級(jí)低代碼開(kāi)發(fā)平臺(tái)的另外一個(gè)關(guān)鍵點(diǎn)。這點(diǎn)可以再參考下云原生ServerLess的思路，即技術(shù)能力提供不應(yīng)該是在應(yīng)用系統(tǒng)內(nèi)部，而是應(yīng)該單獨(dú)剝離和下沉到云平臺(tái)BaaS層能力，做為獨(dú)立的服務(wù)提供。

獨(dú)立提供技術(shù)服務(wù)才可能讓最終低代碼開(kāi)發(fā)完成的應(yīng)用具備高擴(kuò)展性。

低代碼開(kāi)發(fā)的應(yīng)用更多只關(guān)于業(yè)務(wù)場(chǎng)景，業(yè)務(wù)規(guī)則和邏輯的實(shí)現(xiàn)，而不用去關(guān)心底層技術(shù)平臺(tái)細(xì)節(jié)，比如低代碼平臺(tái)本身也需要用到緩存能力。那么這個(gè)緩存就應(yīng)該使用云平臺(tái)提供的緩存服務(wù)，即使緩存服務(wù)出現(xiàn)性能瓶頸，也是云平臺(tái)來(lái)考慮如何擴(kuò)展而不是低代碼平臺(tái)本身去考慮。

對(duì)于技術(shù)平臺(tái)和服務(wù)分為兩類(lèi)。

• 公共流程引擎，4A平臺(tái)
• 各類(lèi)技術(shù)服務(wù)：包括消息，緩存，文件，日志等

以上列的平臺(tái)和技術(shù)服務(wù)，如果你是做一個(gè)企業(yè)級(jí)的低代碼開(kāi)發(fā)平臺(tái)，那么這些平臺(tái)服務(wù)能力也必須獨(dú)立出來(lái)，下沉到企業(yè)內(nèi)部私有云PaaS平臺(tái)以服務(wù)化方式提供，同時(shí)還需要滿足前面提到的多租戶架構(gòu)要求。

什么意思呢？

一個(gè)低代碼開(kāi)發(fā)平臺(tái)的運(yùn)行，即使是在測(cè)試環(huán)境也離不開(kāi)上面這些平臺(tái)或技術(shù)服務(wù)能力先運(yùn)行起來(lái)。即低代碼開(kāi)發(fā)平臺(tái)開(kāi)發(fā)完成的功能，最終發(fā)布出來(lái)后需要調(diào)用上面這些平臺(tái)提供的API接口服務(wù)才能夠成功運(yùn)行。

而低代碼開(kāi)發(fā)平臺(tái)最終從測(cè)試環(huán)境交付和遷移到生產(chǎn)環(huán)境，同樣這些服務(wù)能力接口也需要切換到調(diào)用生產(chǎn)環(huán)境BaaS層服務(wù)能力。

所以構(gòu)建企業(yè)級(jí)低代碼平臺(tái)，你首先要做的是構(gòu)建企業(yè)內(nèi)部的云原生技術(shù)平臺(tái)或者內(nèi)部的私有云PaaS服務(wù)平臺(tái)。這個(gè)是構(gòu)建低代碼平臺(tái)的基礎(chǔ)。

否則你最終通過(guò)低代碼平臺(tái)開(kāi)發(fā)出來(lái)的應(yīng)用很難是一個(gè)企業(yè)級(jí)應(yīng)用。

再次強(qiáng)調(diào)，低代碼平臺(tái)只是將我們傳統(tǒng)開(kāi)發(fā)業(yè)務(wù)系統(tǒng)的過(guò)程盡量的自動(dòng)化和可配置化掉了，但是整個(gè)自動(dòng)化過(guò)程仍然需要遵循當(dāng)前的微服務(wù)架構(gòu)，分層，平臺(tái) 應(yīng)用的構(gòu)建思路。

基于API的規(guī)則定制和集成

前面已經(jīng)談到，我們做的是低代碼而非零代碼，是類(lèi)似國(guó)外Mendix低代碼開(kāi)發(fā)平臺(tái)的思路，特別是在規(guī)則引擎技術(shù)沒(méi)有重大突破前，必須要結(jié)合自定義代碼開(kāi)發(fā)。

否則就會(huì)出現(xiàn)你寫(xiě)大量的腳本代碼，而這些腳本在后期更加難以維護(hù)。

在10多年前，個(gè)人就主持做過(guò)類(lèi)似的CS架構(gòu)的快速開(kāi)發(fā)平臺(tái)產(chǎn)品，當(dāng)時(shí)基本對(duì)象，流程，界面設(shè)計(jì)全部都可以靈活配置。復(fù)雜的規(guī)則邏輯還提供一個(gè)腳本編輯器來(lái)完成。但是最終發(fā)現(xiàn)的問(wèn)題就是腳本編輯器里面寫(xiě)的腳本越來(lái)越多，后期難以維護(hù)。

所以對(duì)于復(fù)雜規(guī)則的實(shí)現(xiàn)還是需要自己寫(xiě)代碼來(lái)實(shí)現(xiàn)。

開(kāi)發(fā)人員自己開(kāi)發(fā)API并暴露

在低代碼平臺(tái)進(jìn)行對(duì)象建模后，對(duì)象最終會(huì)生成后臺(tái)的數(shù)據(jù)庫(kù)對(duì)象和數(shù)據(jù)表，這些要對(duì)開(kāi)發(fā)人員可見(jiàn)。那么開(kāi)發(fā)人員基于這些數(shù)據(jù)庫(kù)對(duì)象可以開(kāi)發(fā)自己的接口API服務(wù)。

對(duì)于接口的開(kāi)發(fā)，接口服務(wù)最終的部署和運(yùn)行應(yīng)該獨(dú)立管理，也就是還需要提供一個(gè)類(lèi)似API全生命周期管理的一個(gè)平臺(tái)。這個(gè)平臺(tái)可以進(jìn)行API接口的設(shè)計(jì)，開(kāi)發(fā)，部署和運(yùn)行管理。開(kāi)發(fā)人員最終開(kāi)發(fā)完成的API接口部署到這個(gè)平臺(tái)，同時(shí)通過(guò)一個(gè)API網(wǎng)關(guān)或能力開(kāi)放平臺(tái)統(tǒng)一對(duì)外開(kāi)放能力接口。

而低代碼開(kāi)發(fā)平臺(tái)在進(jìn)行前端界面設(shè)計(jì)的時(shí)候，可以靈活地去調(diào)用這些可復(fù)用的API接口服務(wù)能力來(lái)完成復(fù)雜邏輯處理。也就是前端界面和API接口服務(wù)之間通過(guò)簡(jiǎn)單的前端腳本代碼來(lái)完成集成和協(xié)同。

多個(gè)API接口的組合和編排

在前面文章我已經(jīng)談到過(guò)，一個(gè)好的低代碼開(kāi)發(fā)平臺(tái)應(yīng)該提供一個(gè)可視化的微服務(wù)API接口編排的工具，進(jìn)行服務(wù)的組裝和編排工作。

舉個(gè)簡(jiǎn)單的例子，當(dāng)你提交一個(gè)采購(gòu)訂單的時(shí)候，需要進(jìn)行預(yù)算控制，平臺(tái)層本身提供了預(yù)算控制API接口服務(wù)，但是需要輸入項(xiàng)目編碼。因此首先要根據(jù)采購(gòu)訂單號(hào)查詢到項(xiàng)目編碼，然后再去調(diào)用預(yù)算控制服務(wù)。

而基于采購(gòu)訂單號(hào)查詢項(xiàng)目編碼本身又是另外一個(gè)API接口。那么就需要對(duì)兩個(gè)API接口服務(wù)進(jìn)行組裝和編排。在這種場(chǎng)景下就可以通過(guò)前端可視化服務(wù)編排工具來(lái)完成接口的組裝和編排工作。而非一定要通過(guò)自己編寫(xiě)代碼來(lái)完成。

門(mén)戶和應(yīng)用集成

最后談下門(mén)戶集成方面的內(nèi)容。還是先從場(chǎng)景和期望的目標(biāo)出發(fā)來(lái)談。

對(duì)于一個(gè)企業(yè)往往建設(shè)了多個(gè)IT系統(tǒng)，在多個(gè)系統(tǒng)建設(shè)完成后一般會(huì)建設(shè)一個(gè)EIP統(tǒng)一門(mén)戶來(lái)實(shí)現(xiàn)統(tǒng)一認(rèn)證和單點(diǎn)等。用戶登錄門(mén)戶后除了看到場(chǎng)景的通知，公告，待辦信息外。門(mén)戶還提供了一個(gè)重要功能，即：

所有接入的IT系統(tǒng)的快捷入口連接。通過(guò)這個(gè)快捷連接可以快速地單點(diǎn)登錄到具體的業(yè)務(wù)系統(tǒng)里面，比如CRM系統(tǒng)，SRM系統(tǒng)等。

那么低代碼開(kāi)發(fā)平臺(tái)需要和門(mén)戶集成。

簡(jiǎn)單來(lái)說(shuō)就是通過(guò)低代碼開(kāi)發(fā)平臺(tái)開(kāi)發(fā)完成的應(yīng)用，在應(yīng)用最終發(fā)布完成后并通過(guò)相關(guān)的應(yīng)用授權(quán)配置后，能夠自動(dòng)的體現(xiàn)到門(mén)戶的應(yīng)用快捷入口處。

比如CRM系統(tǒng)開(kāi)發(fā)完成并發(fā)布，同時(shí)我又授權(quán)給張三可以使用，那么張三登錄到門(mén)戶后就應(yīng)該可以看到CRM系統(tǒng)的連接，在點(diǎn)擊連接后也可以進(jìn)入到CRM系統(tǒng)。

門(mén)戶授權(quán)和應(yīng)用系統(tǒng)功能授權(quán)

門(mén)戶授權(quán)和應(yīng)用系統(tǒng)里面的功能菜單和數(shù)據(jù)授權(quán)是兩個(gè)概念。

門(mén)戶授權(quán)要解決的問(wèn)題是某一個(gè)用戶是否能夠使用某個(gè)系統(tǒng)，比如張三能否使用CRM系統(tǒng)，而CRM系統(tǒng)里面的授權(quán)要解決的問(wèn)題是張三能夠使用CRM系統(tǒng)里面的哪些功能菜單。

因此當(dāng)開(kāi)發(fā)者在低代碼平臺(tái)創(chuàng)建了CRM這個(gè)應(yīng)用后。首先要做的一個(gè)關(guān)鍵步驟就是在門(mén)戶里面自動(dòng)化注冊(cè)CRM這應(yīng)用，并CRM也自動(dòng)完成和門(mén)戶的單點(diǎn)集成。如果是已有應(yīng)用接入門(mén)戶，你會(huì)看到是門(mén)戶管理員手工在門(mén)戶里面進(jìn)行應(yīng)用注冊(cè)和配置。

開(kāi)發(fā)者本身可以自動(dòng)授權(quán)可以使用這個(gè)應(yīng)用，但是其它哪些用戶能夠使用CRM應(yīng)用則需要在門(mén)戶里面進(jìn)行授權(quán)處理。

只有授權(quán)后的用戶在登錄門(mén)戶后的快捷菜單才能夠看到該應(yīng)用。剩余的具體功能菜單授權(quán)則是通過(guò)進(jìn)入到具體的應(yīng)用系統(tǒng)里面的系統(tǒng)管理功能來(lái)完成。

對(duì)于應(yīng)用里面的系統(tǒng)管理功能也是4A的一個(gè)關(guān)鍵內(nèi)容。那么這個(gè)系統(tǒng)管理也需要考慮多種租戶架構(gòu)，各個(gè)應(yīng)用系統(tǒng)里面的系統(tǒng)管理基礎(chǔ)數(shù)據(jù)和配置要做到完全隔離。

低代碼開(kāi)發(fā)平臺(tái)關(guān)注的是具體業(yè)務(wù)功能，對(duì)于常用的組織，人員，用戶這些信息統(tǒng)一都應(yīng)該作為門(mén)戶的底層基礎(chǔ)數(shù)據(jù)能力提供給低代碼開(kāi)發(fā)完成的應(yīng)用。而不是在低代碼開(kāi)發(fā)平臺(tái)完成的應(yīng)用中還單獨(dú)搞一套基礎(chǔ)系統(tǒng)管理功能。