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

今天我準備跟大家分享一下，在云原生和微服務架構下企業(yè)級低代碼平臺的選型思考。因為在2023年我跟很多客戶和朋友溝通的比較多，大家都在談論企業(yè)怎么樣選擇一個適合的低代碼開發(fā)平臺？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

企業(yè)級低代碼平臺關鍵能力要求

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

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

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

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

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

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

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

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

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

低代碼平臺支持多組織和多租戶

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

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

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

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

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

所以我一直強調(diào)對象建模是低代碼面向復雜業(yè)務實現(xiàn)的一個關鍵的能力。

低代碼平臺的表單建模

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

低代碼平臺的流程建模

對于工作流流程權限，這個也是低代碼開發(fā)平臺應該具備的一些基礎能力，涉及到流程的設計、流程的監(jiān)控、權限的建模，其他的一些需求。

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

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

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

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

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

低代碼平臺的外部集成能力

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

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

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

云原生技術架構滿足度

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

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

同時低代碼平臺需要獨立可擴展的技術組件能力，類似于消息安全緩存等。

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

第六個就是低代碼開發(fā)平臺開發(fā)完成的應用，支持源代碼導出獨立部署，最終的低代碼開發(fā)完成應用能夠脫離低代碼開發(fā)平臺運行。

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

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

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