高低開走向融合，是低成本應(yīng)用建設(shè)的最終解決之道（高低開什么意思）

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

引言

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

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

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

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

01

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

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

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

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

02

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

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

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

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

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

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

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

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

03

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

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

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

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

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

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

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

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

04

高低開平臺實施效果

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

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

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

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

說在最后：

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

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

關(guān)于EAWorld

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