顧偉——現(xiàn)任普元數(shù)智研究院總經(jīng)理，長(zhǎng)期負(fù)責(zé)公司的應(yīng)用和數(shù)據(jù)平臺(tái)發(fā)展，在微服務(wù)、DevOps、低代碼、數(shù)據(jù)治理等領(lǐng)域有豐富的研發(fā)與實(shí)施經(jīng)驗(yàn)，主導(dǎo)了多家大型企業(yè)的云原生與低代碼平臺(tái)建設(shè)。

引言

前兩年市場(chǎng)大談云原生、技術(shù)中臺(tái)、業(yè)務(wù)中臺(tái)等概念，企業(yè)更多的聚焦在業(yè)務(wù)與IT架構(gòu)的升級(jí)。而這兩年，隨著低代碼、生成式AI的盛行，大家則開始挖掘數(shù)字化應(yīng)用的廉價(jià)建設(shè)模式。

我們團(tuán)隊(duì)也緊跟著市場(chǎng)腳步，將分布式應(yīng)用平臺(tái)進(jìn)行不斷迭代，期望獲得低代碼、組裝式應(yīng)用程序等熱點(diǎn)加持。但在最終客戶的平臺(tái)建設(shè)時(shí)，尤其在低代碼應(yīng)用的交付上，遇到了諸多問題，舉幾個(gè)典型的例子：

• 應(yīng)用個(gè)性化要求太多，單靠低代碼模式難以實(shí)現(xiàn)完整功能怎么辦？
• 工程師能力不足（事實(shí)上很多企業(yè)認(rèn)為低代碼是為了讓初級(jí)人員玩），平臺(tái)稍微開點(diǎn)代碼口子，各類腳本片段就滿天飛，應(yīng)用后期如何維護(hù)和優(yōu)化？
• 低代碼平臺(tái)使用了動(dòng)態(tài)渲染或解析執(zhí)行等技術(shù)（比如很多低代碼平臺(tái)的表單或服務(wù)就是這類機(jī)制），性能不足如何提升？

回歸問題本質(zhì)，低代碼應(yīng)用建設(shè)的規(guī)范、低代碼適合場(chǎng)景的圈定、相關(guān)引擎技術(shù)的選擇、與遺留系統(tǒng)高體驗(yàn)的交互，是低代碼平臺(tái)研發(fā)必須要面對(duì)的抉擇。

01

低代碼的應(yīng)用場(chǎng)景建議

低代碼平臺(tái)最怕的是：領(lǐng)導(dǎo)很想用，技術(shù)用不好、業(yè)務(wù)不會(huì)用。說白了就是市場(chǎng)帽子戴的很高，在企業(yè)四處傳道，但是到具體系統(tǒng)建設(shè)時(shí)，技術(shù)團(tuán)隊(duì)發(fā)現(xiàn)只有少量的功能開發(fā)可以用上，一些向往由業(yè)務(wù)團(tuán)隊(duì)來建設(shè)系統(tǒng)的企業(yè)，對(duì)業(yè)務(wù)人員又要求太高，動(dòng)輒就要學(xué)習(xí)腳本編寫額和模型設(shè)計(jì)，而這正是現(xiàn)在低代碼應(yīng)用場(chǎng)景的真實(shí)寫照。

誠(chéng)然，我們看到一些開發(fā)商建立了不錯(cuò)的客戶案例，但基本上是聚焦在下面這幾種應(yīng)用場(chǎng)景：

如果單純的依靠低代碼平臺(tái)建設(shè)應(yīng)用，上面的幾類場(chǎng)景范圍我覺得已經(jīng)足夠大，各開發(fā)商需要逐步將自身的重點(diǎn)方向業(yè)務(wù)化，方能形成更優(yōu)的市場(chǎng)格局，而不是大家都是奔著通用市場(chǎng)的技術(shù)型玩法。而我們團(tuán)隊(duì)在第一階段也是技術(shù)型通用場(chǎng)景的做法，導(dǎo)致不少項(xiàng)目通過低代碼解決了70%-80%的問題，剩下的則很難搞定（往往這部分反而是關(guān)鍵需求），項(xiàng)目交付阻力很大。所以在第二階段，我們一部分團(tuán)隊(duì)聚焦特定的業(yè)務(wù)領(lǐng)域去做積累（如項(xiàng)目管理、中間業(yè)務(wù)等），另一部分則圍繞高低開融合的思路，力求能夠支撐更廣泛的分布式應(yīng)用建設(shè)。

02

高低開融合的職責(zé)切分

討論高低開融合，我們可以先來看看兩個(gè)常見的融合架構(gòu)設(shè)計(jì)誤區(qū)：

第一張圖是業(yè)界常見高開和低開應(yīng)用融合模式，兩者獨(dú)立建設(shè)，技術(shù)實(shí)現(xiàn)確實(shí)相對(duì)簡(jiǎn)單，但是難道需要高低開融合的數(shù)字化應(yīng)用，以后都是這種建設(shè)模式嗎？顯然是不對(duì)的，這種＂混合＂模式，本質(zhì)上又建立了一個(gè)低代碼孤島，僅僅是通過技術(shù)手段將兩者混合在一起。

第二張圖則是業(yè)界常見的低代碼應(yīng)用最終部署結(jié)構(gòu)，考慮到商業(yè)問題，企業(yè)不太會(huì)采購(gòu)多套低代碼平臺(tái)，如果只是為了承載單應(yīng)用建設(shè)還好，但如果是建設(shè)多應(yīng)用時(shí)，這些低代碼應(yīng)用之間往往沒做物理隔離，而是運(yùn)行在一個(gè)進(jìn)程當(dāng)中（甚至數(shù)據(jù)層可能都沒有完全隔離，統(tǒng)一啟停和升級(jí)），這在大型企業(yè)的是不可想象的。

考慮到我們面向的主要客戶的IT體量都比較大，在高低開融合方案設(shè)計(jì)上，我們確定了三個(gè)不可違背的設(shè)計(jì)原則：

• 應(yīng)用采用高低開融合建設(shè)，但應(yīng)用資源要運(yùn)行在同一個(gè)進(jìn)程中；
• 各個(gè)最終應(yīng)用之間，默認(rèn)是完全隔離的部署模式；
• 低代碼開發(fā)的資源可無縫引用高代碼資源，反之默認(rèn)不允許。

前兩個(gè)原則比較好理解，第三個(gè)可能大家會(huì)有疑問，為何不做雙向引用（在后面的技術(shù)棧里也會(huì)涉及），這里需要澄清的是：引用的意思是指資源之間的強(qiáng)關(guān)聯(lián)應(yīng)用，比如高開的服務(wù)編排里，使用低開的數(shù)據(jù)模型，這個(gè)我們是不允許的，如果是高開的頁(yè)面中，通過微前端模式局部展示低開的表單，這個(gè)是沒有問題的。最終我們對(duì)資源做了詳細(xì)的切分，高開上提供什么類型的資源設(shè)計(jì)開發(fā)，低開上支持哪些，如何本地化使用等，形成了深度融合的開發(fā)與運(yùn)行架構(gòu)。

上面這張圖是高低開融合的全景圖，里面包含了高低開都需要的開發(fā)、運(yùn)行、治理、服務(wù)發(fā)布，以及流程、組織、權(quán)限這類企業(yè)級(jí)應(yīng)用需要共享的服務(wù)等，如果大家關(guān)心具體資源的融合與引用關(guān)系，我們則可以關(guān)注下面這張示意圖，最終高低開的多個(gè)模塊是打成一個(gè)完整包來投產(chǎn)的：

03

低代碼的技術(shù)棧選擇

首先低代碼平臺(tái)本身需要從場(chǎng)景、性能、可維護(hù)等角度考慮，形成技術(shù)棧的抉擇，比如：

• 前端表單頁(yè)面：走代碼生成模式還是動(dòng)態(tài)渲染模式
• 后端服務(wù)編排：走源碼動(dòng)態(tài)編譯模式還是圖形解析執(zhí)行模式

再者想做到高低開融合，在資源的可配置、可管理、UI體驗(yàn)等方面有很多細(xì)節(jié)要打磨，比如：

• 在線表單和離線界面如何融合到某個(gè)復(fù)雜頁(yè)面中
• 權(quán)限配置如何保證支持到最細(xì)粒度（菜單、按鈕、API、數(shù)據(jù)等）

當(dāng)然還有包括內(nèi)外部市場(chǎng)環(huán)境等因素，像數(shù)據(jù)庫(kù)、瀏覽器等考量也是不可獲取的。目前我們支持了如下的融合技術(shù)場(chǎng)景：

拿前端選型為例，為了頁(yè)面間的重新融合組裝，使用了基于webpack5的微前端模式，同時(shí)高開和低開在不同終端上，各自使用了同一套UI庫(kù)。做第一版時(shí)，采用了中間模型動(dòng)態(tài)渲染的模式，在遇到一些特大頁(yè)面時(shí)（150 控件），性能極具下降（當(dāng)然，和第一版開放了太多代碼口子也有關(guān)系，單純的靜態(tài)頁(yè)面也不至于慢太多），于是在第二版直接換成了代碼生成模式（生成的代碼可有限修改），大大提升了性能和靈活性。

再比如用于后端邏輯實(shí)現(xiàn)的服務(wù)編排，則根據(jù)在線編排的流圖，運(yùn)行期生成了具體java代碼，并通過jdt能力編譯成class并加載，比起執(zhí)行時(shí)的單步解析方案要快很多。所以上述的前后端技術(shù)方案，使得其實(shí)無論低代碼還是高代碼，運(yùn)行的實(shí)際資源是技術(shù)一致的，從而避免了多套引擎的開發(fā)和維護(hù)問題。

04

高低開平臺(tái)實(shí)施效果

離線高開工具這里就不在贅述，在線低開則提供了統(tǒng)一的在線應(yīng)用開發(fā)環(huán)境（微應(yīng)用），支持多團(tuán)隊(duì)多人協(xié)作，應(yīng)用開發(fā)入口界面主要包括四大區(qū)域：

• 在線資源區(qū)：提供在線資源的創(chuàng)建、刪除、重構(gòu)等
• 資源設(shè)計(jì)區(qū)：提供各類資源的編輯器，包括表單、流程、服務(wù)、模型、數(shù)據(jù)集、報(bào)表、大屏等
• 離線資源區(qū)：提供應(yīng)用本身的高開資源以及依賴資源，供低開資源引用
• 問題反饋區(qū)：在線工具同樣需要支持快速調(diào)試以及問題定位，此區(qū)域會(huì)將設(shè)計(jì)開發(fā)問題統(tǒng)一記錄并做資源關(guān)聯(lián)

具體的各類資源設(shè)計(jì)器，使用的技術(shù)不盡相同，具體會(huì)在后續(xù)大會(huì)上詳細(xì)分享，最終設(shè)計(jì)出來的資源，則需要與低開進(jìn)行統(tǒng)一的發(fā)布，然后與組織機(jī)構(gòu)權(quán)限結(jié)合，支撐業(yè)務(wù)場(chǎng)景，平臺(tái)目前默認(rèn)支持多應(yīng)用、多租戶的模式，可定義頁(yè)面、功能、數(shù)據(jù)、流程等不同類型的資源，資源有二級(jí)分類，比如頁(yè)面中會(huì)包含高開的微前端頁(yè)面、或者低代的報(bào)表、表單頁(yè)面，支持將各類資源統(tǒng)一進(jìn)行授權(quán)，最終形成完整的業(yè)務(wù)門戶。

在公司內(nèi)部，我們已經(jīng)將多個(gè)數(shù)據(jù)類的產(chǎn)品、多個(gè)行業(yè)重點(diǎn)解決方案使用高低開融合平臺(tái)進(jìn)行研發(fā)；對(duì)公司外部，結(jié)合業(yè)務(wù)解決方案，已實(shí)施了包括多家銀行的特色業(yè)務(wù)，以及工單、科技管理、指標(biāo)管理、運(yùn)營(yíng)管理等領(lǐng)域，力求形成普惠應(yīng)用的IT基礎(chǔ)，支撐更廣泛的融合業(yè)務(wù)甚至中臺(tái)業(yè)務(wù)的持續(xù)建設(shè)。

說在最后：

低代碼值得大家更多的關(guān)注，但應(yīng)用的低成本建設(shè)，不是找低端的人來建設(shè)應(yīng)用，而是在敏捷體系下，進(jìn)行合理的分工和架構(gòu)拆分，解放重復(fù)勞動(dòng)，提升交付質(zhì)量。

當(dāng)下，我們更應(yīng)該正視低代碼模式的應(yīng)用開發(fā)中遭遇的問題，探尋其癥結(jié)所在，并給出解決方案，促進(jìn)低代碼的普惠推廣和成功應(yīng)用。經(jīng)過近三年的實(shí)踐，我們多次推翻了建設(shè)成果，走到了高低開深度融合的平臺(tái)這條路，期望通過技術(shù)、業(yè)務(wù)、團(tuán)隊(duì)、線上線下的有效協(xié)同，有力促進(jìn)企業(yè)數(shù)字化轉(zhuǎn)型進(jìn)入快車道。

關(guān)于EAWorld

全棧賦能信創(chuàng)，共創(chuàng)數(shù)智未來！