Hello大傢好，我是人月聊IT。
今天我準備跟大傢分享一下，在雲原生和微服務架構下企業級低代碼平臺的選型思考。因為在2023年我跟很多客戶和朋友溝通的比較多，大傢都在談論企業怎麼樣選擇一個適合的低代碼開發平臺？
一個企業的需求如果僅僅是你現在有一個小的新應用要開發，或者是說你的一個部門小團隊想去選擇一個低代碼開發平臺，那這個事情就相對來說比較簡單。但是如果是你企業整個it部門，你在做整個企業的IT應用架構規劃，希望引入一個平臺級的低代碼開發平臺工具，希望以後企業新的應用和組件模塊都基於這個平臺去做開發，那這個時候你要考慮的問題就會多得多。
所以說我今天想講的重心也仍然是對於企業級的低代碼開發平臺，我們再去選型的時候，究竟應該考慮哪一些關鍵的因素？
業界對低代碼開發廠商有一個標準的能力評估體系，他把它分為了8個方面，其中對於開發工具、數據模型、流程模型、業務場景適配，更多的是在講它的功能性需求。對於生態體系和開放性服務能力，後續運維和安全學習成本應用性，更多的是在講它的非功能性需求。從這8個方面的評估體系我們可以看到對於低代碼平臺整個技術架構的先進性，沒有專門作為一個評估的維度。
業界對低代碼產品的選型思考分為兩個方面：第一個就是產品選型的關鍵指標，除了剛才講到的基礎功能以外，它也更加強調產品的易用性、擴展性、安全、技術架構的先進性、生態的開放性，同時他給出了一個產品選型的矩陣。
上面圖是低代碼開發平臺選型2022年的一個白皮書的數據，所以在這個地方也就明確提出了低代碼開發平臺，它包括了低代碼和零代碼兩類，因此我們在選型的時候一定要考慮你究竟是面向技術開發者還是面向沒有任何技術背景開發經驗的業務人員。因為這種兩種不同的類型對我們去選擇低代碼開發平臺的時候影響相當的大，所以結合業界低代碼產品的能力評估，選型的思考，我把整個低代碼開發平臺分為4類，就是面向目標用戶群體不一樣。
第一類就是完全面向業務用戶，沒有任何技術背景。第二類是有技術部門的人員，這類人員雖然有技術背景但是沒有開發經驗。第三類就是開發人員，但是有基礎的編碼經驗，比如說就是剛畢業或者是1~2年的經驗，還有一類就是我已經有熟練的開發經驗的開發人員。對於這4類我們再去做低代碼開發平臺選型的時候，相應的一些關鍵能力要求都不一樣。
第一類：面向業務用戶
對於第一類面向業務用戶的，我們更多的希望就是拖拖拽拽表單加流程，實現完全的即開即用零代碼開發。對於這種一般都是以SaaS類的低代碼輕應用為主，所以我們經常看到的類似於搭搭雲，易搭雲都是這種類型。
第二類：有技術背景無開發經驗
第二類就是對於技術部門有技術背景但是沒有開發經驗的人員，對於這種場景它更加強調了流程引擎和表單的配置能力。當然這種場景它不能叫完全的零代碼，它仍然會有少量的腳本代碼的編寫，包括和外部接口集成的能力。所以這一類的典型廠傢，比如我們看到的明道雲，得帆，用友，金蝶等就屬於這種類型。
第三類：面向有基礎編程經驗的開發人員
對於這類場景基本上能夠解決絕大部分的復雜業務場景和場景的集成。這種場景需要開發人員有基礎的編碼的經驗，對於低代碼平臺，它本身也是需要你提供一個面向開發的獨立開發環境，有強大的二次開發能力和外部集成能力。對於這種對於國外西門子的Mendix，或者是對於國內早期的普元的EOS平臺，基本上就是走的這個路線。
第四類：面向熟練開發經驗的人員
對於第四種就是完全面向有熟練編碼經驗的開發人員。對於這種類型我們有時候他不能嚴格意義上叫低代碼開發平臺，更多的就是叫快速開發平臺，或者是提供一個已經成型的開發框架或者是開發環境，對於這種類似於開源的jeecgboot，JNPF，若依等快速開發平臺，基本上就是屬於這種類型。
所以綜合以上的分析，我們可以看到企業級的低代碼平臺在選型的時候，它的關鍵能力的要求究竟應該是什麼樣的？
企業級低代碼平臺關鍵能力要求
首先說明一下企業級低代碼開發平臺一定不是零代碼開發平臺，它是需要一個有足夠的開放性、擴展性，能夠快速的靈活對定制，又能夠滿足復雜業務場景實現的這麼一種低代碼開發平臺。所以我把它分成三大能力的要求。
第一類就是基礎能力要求，這一塊就是包括我們通常說的流程引擎的能力、組織權限的能力、可視化的表單配置、對象建模、數據建模、表單類的需求、規則引擎的能力。
第二類就是雲原生架構要求。在當前雲原生架構下面，我們更加的強調第一代碼開發平臺相應的上雲的能力的要求，所以我把它分了幾個關鍵的點，第一個就是低代碼開發平臺，它本身應該是微服務架構，同時開發完的應用也要是微服務架構也要符合當前主流的前後端分離。第二個就是他需要支持容器雲部署，支持水平擴展。第三個是他最好能夠支持項目源代碼的導出，部署包的導出，方便我們通過低代碼開發平臺開發完成的應用，能夠脫離低代碼開發平臺運行。第四個就是支持低代碼開發項目中過程中多項目多應用的協同，包括支持和當前主流的DevOps持續集成過程的協同。
第三類是非功能性需求要求。在這個裡面最最重要的它就必須要支持多租戶、多組織多項目的模式，能夠去做好租戶資源權限數據的隔離。第二個叫擴展性，它需要支持自定義開發代碼擴展和二次開發，定制開發組件。第三個是開放性，他支持API接口的暴露和外部的集成，同時也支持調用外部已有的API接口服務的能力。最後一個就是後續的運維性，低代碼開發平臺開發完的應用，也能夠納入企業已有的統一的it運維監控體系中去。
所以低代碼開發平臺它的整個的參考架構是怎麼樣呢？就拿遠行我們自己的低代碼開發平臺來說，該平臺是基於主流的微服務架構打造基於對象驅動的核心思想，實現對象建模、數據建模、權限建模、流程建模、規則建模，表單建模核心的建模能力，同時可以快速發佈到雲原生的微服務運行環境。
所以從我這個架構圖大傢也可以看得比較清楚，我把它分為了除了你需要提供一個雲原生的技術平臺的這個底座以外，你第一代碼整個開發它分為了低代碼的開發環境和低代碼的運行環境。
低代碼開發平臺開發完以後，通過DevOps持續集成和發佈到運行環境，發佈到運行環境的就是一個個低代碼開發出來的微服務應用，它本身可以支持容器雲部署，它本身也是前後端分離的，它本身也會納入到整個微服務治理和it運維監控體系裡面去。
低代碼平臺基於微服務技術架構體系的一個參考，這一個內容大傢都比較熟悉了，就是說你我低代碼開發平臺開發的應用，你怎麼樣跟當前主流的微服務開發框架，微服務的治理框架進行相應的融合。
對於低代碼開發平臺開發技術棧的一些思考，類似於它的配置中心的選擇、服務的管理、服務的通信、基礎的消息緩存認證、校驗權限服務的能力，包括一些我們說的豐富的組件庫組件服務的能力，比如說報表服務、文件服務、搜索服務，下面一個就是我們的一個數據中心，它是不是支持結構化的數據，非結構化的數據，包括多數據庫的支撐能力。
低代碼平臺支持多組織和多租戶
好了，再回到低代碼開發平臺，我剛才談到的裡面有一個很重要的叫非功能性需求就是低代碼開發平臺必須要支持多租戶和多組織。當你想把某一個低代碼開發平臺發展為企業級的低代碼開發平臺的時候，你會看到我們可能有內部的開發者，外圍的開發商、合作夥伴都可能需要用我這個平臺進行相應的應用組件模塊的開發，所以說每一個開發者，每一個合作夥伴，他就是一個大的租戶，但是某一個開發廠商可能還需要開發多應用，所以說租戶下面又有應用，應用下面還劃分了進一步的微服務模塊。所以說從這個多租戶多應用應用下面的微服務模塊，你怎麼樣去管理這種相應的多租戶的組織架構，包括資源數據的隔離，你必須要考慮清楚。
那麼低代碼開發完的應用，它有可能還需要支持多組織架構，就是說你要去考慮多組織架構下面的組織的分級的授權，組織和組織之間的數據權限的隔離，這些東西你必須都要考慮到。
低代碼平臺對象建模和數據建模能力
對象建模和數據建模是低代碼開發平臺的一個核心基礎能力。從上邊這個圖我們可以看得到，對象建模式往往是整個低代碼開發平臺最核心的內容，它向下支持數據庫建模和數據表的生成能力，向上支撐表單和報表的配置能力。向外支持核心的API接口對外服務能力的暴露。
但是我們現在看到當前大部分的低代碼開發平臺，其實它沒有對象建模的能力，更多的是表單驅動或者是非對象驅動，在這種場景下就容易導致底層數據庫表形成大量的數據孤島，而且數據沒有辦法橫向關聯集成，所以你會發現你雖然用了低代碼開發平臺，但是又是建了一個個煙囪式的小低代碼應用出來，這個不是我們期望看到的。
所以我一直強調對象建模是低代碼面向復雜業務實現的一個關鍵的能力。
低代碼平臺的表單建模
表單建模其實在這一塊各種低代碼開發平臺相對來說能力都相當強，包括可視化的表單設計，報表的配置，可擴展性，其他的需求。所以在這個地方我隻想強調一個關鍵點，就是在整個表單建模裡面，我們更加強調面向企業級面向行業應用的時候，它的一些行業的基礎組件庫，具備行業屬性的這一些公共的組件庫的這麼一個積累。
低代碼平臺的流程建模
對於工作流流程權限，這個也是低代碼開發平臺應該具備的一些基礎能力，涉及到流程的設計、流程的監控、權限的建模，其他的一些需求。
在這個地方我隻想強調一個關鍵點，就是整個流程建模裡面，我們一定要去註意流程表單的設計，表單和流程引擎的全聯動，包括在流程處理中任何一個活動節點的時候，我基於流程的動態權限的配置和設計。這個我看了很多低代碼開發平臺，對於這一塊的能力相對來說是比較弱的。
低代碼平臺的規則建模
對於規則建模來講，其實當前大部分的低代碼開發平臺沒有完善的規則引擎能力，因為我在10多年前就在使用相應的一些規則引擎，所以類似於原來主流的jRule，Drools這一些開源的規則引擎，它其實仍然也是偏重，有技術復雜度和使用難度。這些規則引擎也不是說有引入到一個完整的低代碼開發平臺的一個必要性，所以我的理解較好的規則實現。主要的參考方式主要有以下三類。
第一類就是對於界面事件處理的JS腳本，我一直認為這一塊就是沒必要去做特別的規則引擎化，更多的你可以在自定義的JS腳本裡面實現擴展規則，這一些擴展規則就包括了數據的校驗、接口的調用，簡單業務邏輯的處理。
第二個就是API接口服務的編排，也就是說將對象建模的能力發佈為API以後，我還提供一個API的接口編排工具來實現組合規則，這個地方是有相應的可視化的工具來實現的。第三個就是叫我把它叫做自開發規則。就是當前的低代碼開發平臺，它是不適合實現復雜的業務規則，那麼我就可以通過自己編寫代碼去實現這些規則，最終再將這些規則暴露為API接口，註冊和接入到低代碼開發平臺。
低代碼平臺的外部集成能力
接下來就是外部的集成的能力，我們講的外部集成主要有三類，第一個就是單點登錄和頁面集成，他需要支持單店登錄統一認證。第二個就是接口集成，他需要支持接口集成的能力，一個是低代碼平臺通過暴露API接口給外部使用，第二個是調用外部的API接口集成。第三個是數據集成，底層它需要支持常見的基於ETL的數據集成能力，能夠實現數據的采集、數據的轉化、數據的清洗、數據的裝載等基礎功能。
當然對於企業級低代碼開發平臺，你必須要去考慮的二次開發和自定義代碼的擴展能力，他需要支持平臺表單對象、數據、流程、組件層級的代碼擴展能力，應該覆蓋應用的組件佈局頁面功能邏輯的代碼擴展，使用戶可以通過代碼擴展和定制相關的組件。
所以說低代碼開發平臺不應該是一個封閉的平臺。當低代碼開發平臺提供的組件庫不夠的時候，我們在前端二次開發的時候，我還可以自己很方便的去擴展自己的前端UI的組件庫。而對於後端一樣的，我們要去支持後端的二次開發和擴展，包括我可以自己編寫代碼，自己發佈為API並接入到低代碼開發平臺，包括對於接口二次開發的擴展，集成能力的二次開發的擴展，都是你去做一個企業級低代碼開發平臺必須要考慮的內容。
雲原生技術架構滿足度
最後一個就是對於我們整個低代碼開發平臺的技術架構的先進性和雲原生架構的滿足度方面的內容，我把它分成了幾方面的。
第一個就是對於開發態的它的技術架構的要求，這裡面的關鍵能力就包括了，你必須要去采用主流的微服務開發框架，你使用的各種微服務技術組件應該符合當前主流的選型的要求。類似於服務的註冊發現，微服務網關、服務的限流熔斷，服務鏈路監控等。同時整個低代碼應用應該是一個前後端分離的一個架構，你應該采用主流的前端框架。
同時低代碼平臺需要獨立可擴展的技術組件能力，類似於消息安全緩存等。
第五個就是對於API接口的設計開發，應該采用主流的Http RestAPI接口來實現，同時這一些接口還能夠納入到API網關進行統一的接口管控和治理。
第六個就是低代碼開發平臺開發完成的應用，支持源代碼導出獨立部署，最終的低代碼開發完成應用能夠脫離低代碼開發平臺運行。
對於運行態，我們又把它分為了幾個關鍵的能力。第一個就是他應該支持容器化部署，也支持虛擬化部署，同時對於部署架構需要可以擴展。對於部署架構的可擴展一方面是低代碼平臺自身組件能力可擴展，一個就是低代碼開發平臺開發完成的應用可以做分佈式集群化的擴展。同時低代碼平臺開發完的應用應該能夠納入企業整體的雲原生運維監控體系，從資源到應用到接口服務都應該能夠納入整體的監控體系。
對於過程態主要又有幾個方面。第一個就是低代碼開發平臺開發需要支持和企業已有的DevOps過程實踐，同時低代碼平臺的輸入需要和前端的需求管理系統，敏捷研發管理平臺進行協同。其次就是低代碼平臺開發完成的應用，能夠持續集成和敏捷交付到我們的生產環境。而對於其他需求就包括了外部集成的支持，二次開發的一些支持，多租戶架構的一些相應的支持能力，這一些都是在當前雲原生架構下面，你如果需要去搭建一個企業級的低代碼開發平臺必須要支撐的一些關鍵能力。
好了，今天的簡單的分享就到這個地方，希望對大傢有所啟發。