Hello大家好，我是人月聊IT。

今天我準(zhǔn)備跟大家分享一下，在云原生和微服務(wù)架構(gòu)下企業(yè)級低代碼平臺(tái)的選型思考。因?yàn)樵?023年我跟很多客戶和朋友溝通的比較多，大家都在談?wù)撈髽I(yè)怎么樣選擇一個(gè)適合的低代碼開發(fā)平臺(tái)？

一個(gè)企業(yè)的需求如果僅僅是你現(xiàn)在有一個(gè)小的新應(yīng)用要開發(fā)，或者是說你的一個(gè)部門小團(tuán)隊(duì)想去選擇一個(gè)低代碼開發(fā)平臺(tái)，那這個(gè)事情就相對來說比較簡單。但是如果是你企業(yè)整個(gè)it部門，你在做整個(gè)企業(yè)的IT應(yīng)用架構(gòu)規(guī)劃，希望引入一個(gè)平臺(tái)級的低代碼開發(fā)平臺(tái)工具，希望以后企業(yè)新的應(yīng)用和組件模塊都基于這個(gè)平臺(tái)去做開發(fā)，那這個(gè)時(shí)候你要考慮的問題就會(huì)多得多。

所以說我今天想講的重心也仍然是對于企業(yè)級的低代碼開發(fā)平臺(tái)，我們再去選型的時(shí)候，究竟應(yīng)該考慮哪一些關(guān)鍵的因素？

業(yè)界對低代碼開發(fā)廠商有一個(gè)標(biāo)準(zhǔn)的能力評估體系，他把它分為了8個(gè)方面，其中對于開發(fā)工具、數(shù)據(jù)模型、流程模型、業(yè)務(wù)場景適配，更多的是在講它的功能性需求。對于生態(tài)體系和開放性服務(wù)能力，后續(xù)運(yùn)維和安全學(xué)習(xí)成本應(yīng)用性，更多的是在講它的非功能性需求。從這8個(gè)方面的評估體系我們可以看到對于低代碼平臺(tái)整個(gè)技術(shù)架構(gòu)的先進(jìn)性，沒有專門作為一個(gè)評估的維度。

業(yè)界對低代碼產(chǎn)品的選型思考分為兩個(gè)方面：第一個(gè)就是產(chǎn)品選型的關(guān)鍵指標(biāo)，除了剛才講到的基礎(chǔ)功能以外，它也更加強(qiáng)調(diào)產(chǎn)品的易用性、擴(kuò)展性、安全、技術(shù)架構(gòu)的先進(jìn)性、生態(tài)的開放性，同時(shí)他給出了一個(gè)產(chǎn)品選型的矩陣。

上面圖是低代碼開發(fā)平臺(tái)選型2022年的一個(gè)白皮書的數(shù)據(jù)，所以在這個(gè)地方也就明確提出了低代碼開發(fā)平臺(tái)，它包括了低代碼和零代碼兩類，因此我們在選型的時(shí)候一定要考慮你究竟是面向技術(shù)開發(fā)者還是面向沒有任何技術(shù)背景開發(fā)經(jīng)驗(yàn)的業(yè)務(wù)人員。因?yàn)檫@種兩種不同的類型對我們?nèi)ミx擇低代碼開發(fā)平臺(tái)的時(shí)候影響相當(dāng)?shù)拇螅越Y(jié)合業(yè)界低代碼產(chǎn)品的能力評估，選型的思考，我把整個(gè)低代碼開發(fā)平臺(tái)分為4類，就是面向目標(biāo)用戶群體不一樣。

第一類就是完全面向業(yè)務(wù)用戶，沒有任何技術(shù)背景。第二類是有技術(shù)部門的人員，這類人員雖然有技術(shù)背景但是沒有開發(fā)經(jīng)驗(yàn)。第三類就是開發(fā)人員，但是有基礎(chǔ)的編碼經(jīng)驗(yàn)，比如說就是剛畢業(yè)或者是1~2年的經(jīng)驗(yàn)，還有一類就是我已經(jīng)有熟練的開發(fā)經(jīng)驗(yàn)的開發(fā)人員。對于這4類我們再去做低代碼開發(fā)平臺(tái)選型的時(shí)候，相應(yīng)的一些關(guān)鍵能力要求都不一樣。

第一類：面向業(yè)務(wù)用戶

對于第一類面向業(yè)務(wù)用戶的，我們更多的希望就是拖拖拽拽表單加流程，實(shí)現(xiàn)完全的即開即用零代碼開發(fā)。對于這種一般都是以SaaS類的低代碼輕應(yīng)用為主，所以我們經(jīng)?？吹降念愃朴诖畲钤?，易搭云都是這種類型。

第二類：有技術(shù)背景無開發(fā)經(jīng)驗(yàn)

第二類就是對于技術(shù)部門有技術(shù)背景但是沒有開發(fā)經(jīng)驗(yàn)的人員，對于這種場景它更加強(qiáng)調(diào)了流程引擎和表單的配置能力。當(dāng)然這種場景它不能叫完全的零代碼，它仍然會(huì)有少量的腳本代碼的編寫，包括和外部接口集成的能力。所以這一類的典型廠家，比如我們看到的明道云，得帆，用友，金蝶等就屬于這種類型。

第三類：面向有基礎(chǔ)編程經(jīng)驗(yàn)的開發(fā)人員

對于這類場景基本上能夠解決絕大部分的復(fù)雜業(yè)務(wù)場景和場景的集成。這種場景需要開發(fā)人員有基礎(chǔ)的編碼的經(jīng)驗(yàn)，對于低代碼平臺(tái)，它本身也是需要你提供一個(gè)面向開發(fā)的獨(dú)立開發(fā)環(huán)境，有強(qiáng)大的二次開發(fā)能力和外部集成能力。對于這種對于國外西門子的Mendix，或者是對于國內(nèi)早期的普元的EOS平臺(tái)，基本上就是走的這個(gè)路線。

第四類：面向熟練開發(fā)經(jīng)驗(yàn)的人員

對于第四種就是完全面向有熟練編碼經(jīng)驗(yàn)的開發(fā)人員。對于這種類型我們有時(shí)候他不能嚴(yán)格意義上叫低代碼開發(fā)平臺(tái)，更多的就是叫快速開發(fā)平臺(tái)，或者是提供一個(gè)已經(jīng)成型的開發(fā)框架或者是開發(fā)環(huán)境，對于這種類似于開源的jeecgboot，JNPF，若依等快速開發(fā)平臺(tái)，基本上就是屬于這種類型。

所以綜合以上的分析，我們可以看到企業(yè)級的低代碼平臺(tái)在選型的時(shí)候，它的關(guān)鍵能力的要求究竟應(yīng)該是什么樣的？

企業(yè)級低代碼平臺(tái)關(guān)鍵能力要求

首先說明一下企業(yè)級低代碼開發(fā)平臺(tái)一定不是零代碼開發(fā)平臺(tái)，它是需要一個(gè)有足夠的開放性、擴(kuò)展性，能夠快速的靈活對定制，又能夠滿足復(fù)雜業(yè)務(wù)場景實(shí)現(xiàn)的這么一種低代碼開發(fā)平臺(tái)。所以我把它分成三大能力的要求。

第一類就是基礎(chǔ)能力要求，這一塊就是包括我們通常說的流程引擎的能力、組織權(quán)限的能力、可視化的表單配置、對象建模、數(shù)據(jù)建模、表單類的需求、規(guī)則引擎的能力。

第二類就是云原生架構(gòu)要求。在當(dāng)前云原生架構(gòu)下面，我們更加的強(qiáng)調(diào)第一代碼開發(fā)平臺(tái)相應(yīng)的上云的能力的要求，所以我把它分了幾個(gè)關(guān)鍵的點(diǎn)，第一個(gè)就是低代碼開發(fā)平臺(tái)，它本身應(yīng)該是微服務(wù)架構(gòu)，同時(shí)開發(fā)完的應(yīng)用也要是微服務(wù)架構(gòu)也要符合當(dāng)前主流的前后端分離。第二個(gè)就是他需要支持容器云部署，支持水平擴(kuò)展。第三個(gè)是他最好能夠支持項(xiàng)目源代碼的導(dǎo)出，部署包的導(dǎo)出，方便我們通過低代碼開發(fā)平臺(tái)開發(fā)完成的應(yīng)用，能夠脫離低代碼開發(fā)平臺(tái)運(yùn)行。第四個(gè)就是支持低代碼開發(fā)項(xiàng)目中過程中多項(xiàng)目多應(yīng)用的協(xié)同，包括支持和當(dāng)前主流的DevOps持續(xù)集成過程的協(xié)同。

第三類是非功能性需求要求。在這個(gè)里面最最重要的它就必須要支持多租戶、多組織多項(xiàng)目的模式，能夠去做好租戶資源權(quán)限數(shù)據(jù)的隔離。第二個(gè)叫擴(kuò)展性，它需要支持自定義開發(fā)代碼擴(kuò)展和二次開發(fā)，定制開發(fā)組件。第三個(gè)是開放性，他支持API接口的暴露和外部的集成，同時(shí)也支持調(diào)用外部已有的API接口服務(wù)的能力。最后一個(gè)就是后續(xù)的運(yùn)維性，低代碼開發(fā)平臺(tái)開發(fā)完的應(yīng)用，也能夠納入企業(yè)已有的統(tǒng)一的it運(yùn)維監(jiān)控體系中去。

所以低代碼開發(fā)平臺(tái)它的整個(gè)的參考架構(gòu)是怎么樣呢？就拿遠(yuǎn)行我們自己的低代碼開發(fā)平臺(tái)來說，該平臺(tái)是基于主流的微服務(wù)架構(gòu)打造基于對象驅(qū)動(dòng)的核心思想，實(shí)現(xiàn)對象建模、數(shù)據(jù)建模、權(quán)限建模、流程建模、規(guī)則建模，表單建模核心的建模能力，同時(shí)可以快速發(fā)布到云原生的微服務(wù)運(yùn)行環(huán)境。

所以從我這個(gè)架構(gòu)圖大家也可以看得比較清楚，我把它分為了除了你需要提供一個(gè)云原生的技術(shù)平臺(tái)的這個(gè)底座以外，你第一代碼整個(gè)開發(fā)它分為了低代碼的開發(fā)環(huán)境和低代碼的運(yùn)行環(huán)境。

低代碼開發(fā)平臺(tái)開發(fā)完以后，通過DevOps持續(xù)集成和發(fā)布到運(yùn)行環(huán)境，發(fā)布到運(yùn)行環(huán)境的就是一個(gè)個(gè)低代碼開發(fā)出來的微服務(wù)應(yīng)用，它本身可以支持容器云部署，它本身也是前后端分離的，它本身也會(huì)納入到整個(gè)微服務(wù)治理和it運(yùn)維監(jiān)控體系里面去。

低代碼平臺(tái)基于微服務(wù)技術(shù)架構(gòu)體系的一個(gè)參考，這一個(gè)內(nèi)容大家都比較熟悉了，就是說你我低代碼開發(fā)平臺(tái)開發(fā)的應(yīng)用，你怎么樣跟當(dāng)前主流的微服務(wù)開發(fā)框架，微服務(wù)的治理框架進(jìn)行相應(yīng)的融合。

對于低代碼開發(fā)平臺(tái)開發(fā)技術(shù)棧的一些思考，類似于它的配置中心的選擇、服務(wù)的管理、服務(wù)的通信、基礎(chǔ)的消息緩存認(rèn)證、校驗(yàn)權(quán)限服務(wù)的能力，包括一些我們說的豐富的組件庫組件服務(wù)的能力，比如說報(bào)表服務(wù)、文件服務(wù)、搜索服務(wù)，下面一個(gè)就是我們的一個(gè)數(shù)據(jù)中心，它是不是支持結(jié)構(gòu)化的數(shù)據(jù)，非結(jié)構(gòu)化的數(shù)據(jù)，包括多數(shù)據(jù)庫的支撐能力。

低代碼平臺(tái)支持多組織和多租戶

好了，再回到低代碼開發(fā)平臺(tái)，我剛才談到的里面有一個(gè)很重要的叫非功能性需求就是低代碼開發(fā)平臺(tái)必須要支持多租戶和多組織。當(dāng)你想把某一個(gè)低代碼開發(fā)平臺(tái)發(fā)展為企業(yè)級的低代碼開發(fā)平臺(tái)的時(shí)候，你會(huì)看到我們可能有內(nèi)部的開發(fā)者，外圍的開發(fā)商、合作伙伴都可能需要用我這個(gè)平臺(tái)進(jìn)行相應(yīng)的應(yīng)用組件模塊的開發(fā)，所以說每一個(gè)開發(fā)者，每一個(gè)合作伙伴，他就是一個(gè)大的租戶，但是某一個(gè)開發(fā)廠商可能還需要開發(fā)多應(yīng)用，所以說租戶下面又有應(yīng)用，應(yīng)用下面還劃分了進(jìn)一步的微服務(wù)模塊。所以說從這個(gè)多租戶多應(yīng)用應(yīng)用下面的微服務(wù)模塊，你怎么樣去管理這種相應(yīng)的多租戶的組織架構(gòu)，包括資源數(shù)據(jù)的隔離，你必須要考慮清楚。

那么低代碼開發(fā)完的應(yīng)用，它有可能還需要支持多組織架構(gòu)，就是說你要去考慮多組織架構(gòu)下面的組織的分級的授權(quán)，組織和組織之間的數(shù)據(jù)權(quán)限的隔離，這些東西你必須都要考慮到。

低代碼平臺(tái)對象建模和數(shù)據(jù)建模能力

對象建模和數(shù)據(jù)建模是低代碼開發(fā)平臺(tái)的一個(gè)核心基礎(chǔ)能力。從上邊這個(gè)圖我們可以看得到，對象建模式往往是整個(gè)低代碼開發(fā)平臺(tái)最核心的內(nèi)容，它向下支持?jǐn)?shù)據(jù)庫建模和數(shù)據(jù)表的生成能力，向上支撐表單和報(bào)表的配置能力。向外支持核心的API接口對外服務(wù)能力的暴露。

但是我們現(xiàn)在看到當(dāng)前大部分的低代碼開發(fā)平臺(tái)，其實(shí)它沒有對象建模的能力，更多的是表單驅(qū)動(dòng)或者是非對象驅(qū)動(dòng)，在這種場景下就容易導(dǎo)致底層數(shù)據(jù)庫表形成大量的數(shù)據(jù)孤島，而且數(shù)據(jù)沒有辦法橫向關(guān)聯(lián)集成，所以你會(huì)發(fā)現(xiàn)你雖然用了低代碼開發(fā)平臺(tái)，但是又是建了一個(gè)個(gè)煙囪式的小低代碼應(yīng)用出來，這個(gè)不是我們期望看到的。

所以我一直強(qiáng)調(diào)對象建模是低代碼面向復(fù)雜業(yè)務(wù)實(shí)現(xiàn)的一個(gè)關(guān)鍵的能力。

低代碼平臺(tái)的表單建模

表單建模其實(shí)在這一塊各種低代碼開發(fā)平臺(tái)相對來說能力都相當(dāng)強(qiáng)，包括可視化的表單設(shè)計(jì)，報(bào)表的配置，可擴(kuò)展性，其他的需求。所以在這個(gè)地方我只想強(qiáng)調(diào)一個(gè)關(guān)鍵點(diǎn)，就是在整個(gè)表單建模里面，我們更加強(qiáng)調(diào)面向企業(yè)級面向行業(yè)應(yīng)用的時(shí)候，它的一些行業(yè)的基礎(chǔ)組件庫，具備行業(yè)屬性的這一些公共的組件庫的這么一個(gè)積累。

低代碼平臺(tái)的流程建模

對于工作流流程權(quán)限，這個(gè)也是低代碼開發(fā)平臺(tái)應(yīng)該具備的一些基礎(chǔ)能力，涉及到流程的設(shè)計(jì)、流程的監(jiān)控、權(quán)限的建模，其他的一些需求。

在這個(gè)地方我只想強(qiáng)調(diào)一個(gè)關(guān)鍵點(diǎn)，就是整個(gè)流程建模里面，我們一定要去注意流程表單的設(shè)計(jì)，表單和流程引擎的全聯(lián)動(dòng)，包括在流程處理中任何一個(gè)活動(dòng)節(jié)點(diǎn)的時(shí)候，我基于流程的動(dòng)態(tài)權(quán)限的配置和設(shè)計(jì)。這個(gè)我看了很多低代碼開發(fā)平臺(tái)，對于這一塊的能力相對來說是比較弱的。

低代碼平臺(tái)的規(guī)則建模

對于規(guī)則建模來講，其實(shí)當(dāng)前大部分的低代碼開發(fā)平臺(tái)沒有完善的規(guī)則引擎能力，因?yàn)槲以?0多年前就在使用相應(yīng)的一些規(guī)則引擎，所以類似于原來主流的jRule，Drools這一些開源的規(guī)則引擎，它其實(shí)仍然也是偏重，有技術(shù)復(fù)雜度和使用難度。這些規(guī)則引擎也不是說有引入到一個(gè)完整的低代碼開發(fā)平臺(tái)的一個(gè)必要性，所以我的理解較好的規(guī)則實(shí)現(xiàn)。主要的參考方式主要有以下三類。

第一類就是對于界面事件處理的JS腳本，我一直認(rèn)為這一塊就是沒必要去做特別的規(guī)則引擎化，更多的你可以在自定義的JS腳本里面實(shí)現(xiàn)擴(kuò)展規(guī)則，這一些擴(kuò)展規(guī)則就包括了數(shù)據(jù)的校驗(yàn)、接口的調(diào)用，簡單業(yè)務(wù)邏輯的處理。

第二個(gè)就是API接口服務(wù)的編排，也就是說將對象建模的能力發(fā)布為API以后，我還提供一個(gè)API的接口編排工具來實(shí)現(xiàn)組合規(guī)則，這個(gè)地方是有相應(yīng)的可視化的工具來實(shí)現(xiàn)的。第三個(gè)就是叫我把它叫做自開發(fā)規(guī)則。就是當(dāng)前的低代碼開發(fā)平臺(tái)，它是不適合實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)規(guī)則，那么我就可以通過自己編寫代碼去實(shí)現(xiàn)這些規(guī)則，最終再將這些規(guī)則暴露為API接口，注冊和接入到低代碼開發(fā)平臺(tái)。

低代碼平臺(tái)的外部集成能力

接下來就是外部的集成的能力，我們講的外部集成主要有三類，第一個(gè)就是單點(diǎn)登錄和頁面集成，他需要支持單店登錄統(tǒng)一認(rèn)證。第二個(gè)就是接口集成，他需要支持接口集成的能力，一個(gè)是低代碼平臺(tái)通過暴露API接口給外部使用，第二個(gè)是調(diào)用外部的API接口集成。第三個(gè)是數(shù)據(jù)集成，底層它需要支持常見的基于ETL的數(shù)據(jù)集成能力，能夠?qū)崿F(xiàn)數(shù)據(jù)的采集、數(shù)據(jù)的轉(zhuǎn)化、數(shù)據(jù)的清洗、數(shù)據(jù)的裝載等基礎(chǔ)功能。

當(dāng)然對于企業(yè)級低代碼開發(fā)平臺(tái)，你必須要去考慮的二次開發(fā)和自定義代碼的擴(kuò)展能力，他需要支持平臺(tái)表單對象、數(shù)據(jù)、流程、組件層級的代碼擴(kuò)展能力，應(yīng)該覆蓋應(yīng)用的組件布局頁面功能邏輯的代碼擴(kuò)展，使用戶可以通過代碼擴(kuò)展和定制相關(guān)的組件。

所以說低代碼開發(fā)平臺(tái)不應(yīng)該是一個(gè)封閉的平臺(tái)。當(dāng)?shù)痛a開發(fā)平臺(tái)提供的組件庫不夠的時(shí)候，我們在前端二次開發(fā)的時(shí)候，我還可以自己很方便的去擴(kuò)展自己的前端UI的組件庫。而對于后端一樣的，我們要去支持后端的二次開發(fā)和擴(kuò)展，包括我可以自己編寫代碼，自己發(fā)布為API并接入到低代碼開發(fā)平臺(tái)，包括對于接口二次開發(fā)的擴(kuò)展，集成能力的二次開發(fā)的擴(kuò)展，都是你去做一個(gè)企業(yè)級低代碼開發(fā)平臺(tái)必須要考慮的內(nèi)容。

云原生技術(shù)架構(gòu)滿足度

最后一個(gè)就是對于我們整個(gè)低代碼開發(fā)平臺(tái)的技術(shù)架構(gòu)的先進(jìn)性和云原生架構(gòu)的滿足度方面的內(nèi)容，我把它分成了幾方面的。

第一個(gè)就是對于開發(fā)態(tài)的它的技術(shù)架構(gòu)的要求，這里面的關(guān)鍵能力就包括了，你必須要去采用主流的微服務(wù)開發(fā)框架，你使用的各種微服務(wù)技術(shù)組件應(yīng)該符合當(dāng)前主流的選型的要求。類似于服務(wù)的注冊發(fā)現(xiàn)，微服務(wù)網(wǎng)關(guān)、服務(wù)的限流熔斷，服務(wù)鏈路監(jiān)控等。同時(shí)整個(gè)低代碼應(yīng)用應(yīng)該是一個(gè)前后端分離的一個(gè)架構(gòu)，你應(yīng)該采用主流的前端框架。

同時(shí)低代碼平臺(tái)需要獨(dú)立可擴(kuò)展的技術(shù)組件能力，類似于消息安全緩存等。

第五個(gè)就是對于API接口的設(shè)計(jì)開發(fā)，應(yīng)該采用主流的Http RestAPI接口來實(shí)現(xiàn)，同時(shí)這一些接口還能夠納入到API網(wǎng)關(guān)進(jìn)行統(tǒng)一的接口管控和治理。

第六個(gè)就是低代碼開發(fā)平臺(tái)開發(fā)完成的應(yīng)用，支持源代碼導(dǎo)出獨(dú)立部署，最終的低代碼開發(fā)完成應(yīng)用能夠脫離低代碼開發(fā)平臺(tái)運(yùn)行。

對于運(yùn)行態(tài)，我們又把它分為了幾個(gè)關(guān)鍵的能力。第一個(gè)就是他應(yīng)該支持容器化部署，也支持虛擬化部署，同時(shí)對于部署架構(gòu)需要可以擴(kuò)展。對于部署架構(gòu)的可擴(kuò)展一方面是低代碼平臺(tái)自身組件能力可擴(kuò)展，一個(gè)就是低代碼開發(fā)平臺(tái)開發(fā)完成的應(yīng)用可以做分布式集群化的擴(kuò)展。同時(shí)低代碼平臺(tái)開發(fā)完的應(yīng)用應(yīng)該能夠納入企業(yè)整體的云原生運(yùn)維監(jiān)控體系，從資源到應(yīng)用到接口服務(wù)都應(yīng)該能夠納入整體的監(jiān)控體系。

對于過程態(tài)主要又有幾個(gè)方面。第一個(gè)就是低代碼開發(fā)平臺(tái)開發(fā)需要支持和企業(yè)已有的DevOps過程實(shí)踐，同時(shí)低代碼平臺(tái)的輸入需要和前端的需求管理系統(tǒng)，敏捷研發(fā)管理平臺(tái)進(jìn)行協(xié)同。其次就是低代碼平臺(tái)開發(fā)完成的應(yīng)用，能夠持續(xù)集成和敏捷交付到我們的生產(chǎn)環(huán)境。而對于其他需求就包括了外部集成的支持，二次開發(fā)的一些支持，多租戶架構(gòu)的一些相應(yīng)的支持能力，這一些都是在當(dāng)前云原生架構(gòu)下面，你如果需要去搭建一個(gè)企業(yè)級的低代碼開發(fā)平臺(tái)必須要支撐的一些關(guān)鍵能力。

好了，今天的簡單的分享就到這個(gè)地方，希望對大家有所啟發(fā)。