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

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

在這頁PPT里面繼續(xù)強調我們實際做的是面向企業(yè)的低代碼開發(fā)平臺而非零代碼開發(fā)平臺，特別是在規(guī)則引擎方面的技術沒有得到實質性突破的時候，軟件研發(fā)沒有銀彈，復雜規(guī)則仍然需要自己開發(fā)。也就是整個平臺更多是參考類似Mendix的架構設計思路進行。

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

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

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

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

所以你做一個低代碼開發(fā)平臺，不要將重心僅僅放在可視化表單設計，可視化流程設計，拖拽式的配置層面，這些雖然很重要，但是對于企業(yè)級的低代碼平臺來說不是重點，底層技術架構本身的高可靠，可擴展才是重點。

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

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

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

• 多租戶架構
• 技術服務平臺和集成
• 基于API的規(guī)則定制
• 門戶和應用集成

低代碼平臺的多租戶架構

低代碼平臺里面的多租戶需要從兩個層面來談，第一個是低代碼平臺本身的多租戶架構設計，其次是低代碼平臺開發(fā)完成的應用多租戶問題。

先談第一個問題。

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

不同的子組織，開發(fā)團隊上來，應該只能夠看到自己開發(fā)和設計的應用，而無法看到其它應用。這就類似張三和李四開發(fā)SRM和CRM兩個應用系統(tǒng)一樣。

張三來說開發(fā)SRM，那么李四設計的CRM系統(tǒng)里面的對象，界面，流程模型等應該對張三不可見，張三也無法隨意使用CRM系統(tǒng)的數(shù)據(jù)對象。如果張三需要CRM系統(tǒng)里面的客戶數(shù)據(jù)，那么也需要走開放的API接口調用。

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

再談第二個問題開發(fā)完成的應用隔離。

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

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

那么如何選擇？

簡單來說就是開發(fā)大的應用一定是要獨立部署資源完全隔離，但是如果你是開發(fā)的一個小應用那么完全可以采用多租戶架構思路一個大數(shù)據(jù)庫并進行數(shù)據(jù)邏輯隔離即可。

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

技術平臺和服務集成

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

獨立提供技術服務才可能讓最終低代碼開發(fā)完成的應用具備高擴展性。

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

對于技術平臺和服務分為兩類。

• 公共流程引擎，4A平臺
• 各類技術服務：包括消息，緩存，文件，日志等

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

什么意思呢？

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

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

所以構建企業(yè)級低代碼平臺，你首先要做的是構建企業(yè)內(nèi)部的云原生技術平臺或者內(nèi)部的私有云PaaS服務平臺。這個是構建低代碼平臺的基礎。

否則你最終通過低代碼平臺開發(fā)出來的應用很難是一個企業(yè)級應用。

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

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

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

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

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

所以對于復雜規(guī)則的實現(xiàn)還是需要自己寫代碼來實現(xiàn)。

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

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

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

而低代碼開發(fā)平臺在進行前端界面設計的時候，可以靈活地去調用這些可復用的API接口服務能力來完成復雜邏輯處理。也就是前端界面和API接口服務之間通過簡單的前端腳本代碼來完成集成和協(xié)同。

多個API接口的組合和編排

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

舉個簡單的例子，當你提交一個采購訂單的時候，需要進行預算控制，平臺層本身提供了預算控制API接口服務，但是需要輸入項目編碼。因此首先要根據(jù)采購訂單號查詢到項目編碼，然后再去調用預算控制服務。

而基于采購訂單號查詢項目編碼本身又是另外一個API接口。那么就需要對兩個API接口服務進行組裝和編排。在這種場景下就可以通過前端可視化服務編排工具來完成接口的組裝和編排工作。而非一定要通過自己編寫代碼來完成。

門戶和應用集成

最后談下門戶集成方面的內(nèi)容。還是先從場景和期望的目標出發(fā)來談。

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

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

那么低代碼開發(fā)平臺需要和門戶集成。

簡單來說就是通過低代碼開發(fā)平臺開發(fā)完成的應用，在應用最終發(fā)布完成后并通過相關的應用授權配置后，能夠自動的體現(xiàn)到門戶的應用快捷入口處。

比如CRM系統(tǒng)開發(fā)完成并發(fā)布，同時我又授權給張三可以使用，那么張三登錄到門戶后就應該可以看到CRM系統(tǒng)的連接，在點擊連接后也可以進入到CRM系統(tǒng)。

門戶授權和應用系統(tǒng)功能授權

門戶授權和應用系統(tǒng)里面的功能菜單和數(shù)據(jù)授權是兩個概念。

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

因此當開發(fā)者在低代碼平臺創(chuàng)建了CRM這個應用后。首先要做的一個關鍵步驟就是在門戶里面自動化注冊CRM這應用，并CRM也自動完成和門戶的單點集成。如果是已有應用接入門戶，你會看到是門戶管理員手工在門戶里面進行應用注冊和配置。

開發(fā)者本身可以自動授權可以使用這個應用，但是其它哪些用戶能夠使用CRM應用則需要在門戶里面進行授權處理。

只有授權后的用戶在登錄門戶后的快捷菜單才能夠看到該應用。剩余的具體功能菜單授權則是通過進入到具體的應用系統(tǒng)里面的系統(tǒng)管理功能來完成。

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

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