深度-低代碼開發(fā)平臺和微服務架構的優(yōu)勢與挑戰(zhàn)（低代碼開發(fā)平臺 架構）
前言
低代碼開發(fā)平臺和微服務架構是當前軟件開發(fā)領域的兩個熱門話題。它們都是為了更高效、更靈活地構建和開發(fā)應用程序而出現(xiàn)的解決方案。本文將以一款基于微服務架構的OneCode引擎為案例來探討低代碼開發(fā)平臺和微服務架構的優(yōu)勢和挑戰(zhàn)。
一，微服務架構在低代碼平臺中的優(yōu)勢
(1) 微服務設計優(yōu)勢
微服務架構是一種面向服務的架構風格，將應用程序拆分為一組小型、自治的服務。以下是微服務架構的一些主要優(yōu)勢：
1. 高度可擴展：微服務架構將應用程序拆分成多個服務，每個服務負責不同的業(yè)務功能。這種拆分使得應用程序的各個模塊之間相互獨立，可以獨立部署和擴展。當某個服務需要擴容時，只需增加該服務的實例即可，不會影響其他服務的性能。
2. 靈活性和可維護性：由于微服務架構將應用程序拆分成多個服務，每個服務負責特定的功能，因此開發(fā)人員和團隊可以更專注于某個特定領域的開發(fā)和維護。這提高了問題追蹤和修復的效率，同時也增加了應用程序的靈活性，可以更快地適應業(yè)務變化。
（2）低代碼平臺為什么要采用微服務設計
1，企業(yè)內部整合開放式API需要微服務架構
在企業(yè)應用中，數(shù)據(jù)和業(yè)務通常會分散在不同的業(yè)務系統(tǒng)中，按照業(yè)務部門可以分為人事行政、項目、銷售、研發(fā)、生產(chǎn)等等；按照當前的軟件類別又可以分為ERP、SCM、CRM、OA、PLM、MES等等，但在企業(yè)的數(shù)字化應用場景中，按照業(yè)務類型通常包括數(shù)據(jù)信息管理、業(yè)務審批、各類報表分析以及其他業(yè)務。在低代碼應用初期主要場景還在于基于各業(yè)務開放API之上的快速應用擴展，但發(fā)展到一定階段后，這些擴展則會形成一些新的資源池。而這個資源池的最佳的管理方式則是采用微服務架構的 apaas 平臺。在低代碼平臺設計中易用以及便捷性是首選但作為企業(yè)級應用而言，對于基于 開放API的管理也是其必選的一個基礎性功能，而微服務則是這一管理應用的最合適選擇。
2，低代碼平臺引擎化設計最佳實踐
我們在解釋什么是低代碼平臺時，最常用的關鍵字是：圖形化、拖拉拽方式快速實現(xiàn)。但這些簡單特性的背后，則是低代碼平臺的高復雜度設計，高度抽象概括，直至衍生出來一些專為低代碼應用而生的“專職”低代碼引擎如：可視拖動引擎、流程驅動引擎、模型驅動設計（DDD）引擎、存儲引擎、以及專為各垂直行業(yè)而匹配的“IOT低代引擎”，“電商低代引擎”等等。這些引擎的設計為低代碼平臺賦予了更廣闊的應用空間，但同時也為低代碼平臺帶來更多的復雜性。這在低代碼平臺自身的“內部生態(tài)”中微服務設計則是不二的技術首選。
3，應用服務持續(xù)集成devops最佳方式
在企業(yè)級應用中，低代碼作為新生的事務。必然會先從一些邊緣業(yè)務開始，逐步向核心業(yè)務靠攏。而有實力嘗試低代碼引擎這種新技術的企業(yè)，多數(shù)都具備了相對完善的發(fā)布和管理的流程。對每一個應用的上線運行都有比較嚴格的流程安全規(guī)范。低代碼應用如果仍然采用傳統(tǒng)部署方式上線則需要根據(jù)企業(yè)的自身的應用發(fā)布測試流程進行整合，完成代碼入庫、版本管理，發(fā)布腳本，測試腳本等等眾多技術性的要求。這顯然與低代碼本身的設計理念相悖，同時這些定制化也會大幅增加平臺服務方與用戶方工作量。解決這一問題最簡單的方式便是提供獨立的DevOps支持，特事特辦，針對輕應用的特點，提供獨立的運行、測試、發(fā)布部署環(huán)境支持。在企業(yè)原有服務中作為一個獨立的服務中間件。而這些獨立的應用服務則是微服務架構的最佳實踐。
二，OneCode微服務私有云整體設計
onecode私有云結構
OneCode私有云是OneCode低代碼引擎的開發(fā)依賴環(huán)境 ，OneCode低代引擎運行需要依賴一些集成環(huán)境來支持，這些支持可以根據(jù)具體的用戶場景來配置同時，OneCode也為這些提供了一些默認的微服務實現(xiàn)。包括：
（1）支撐服務
- 開發(fā)代碼協(xié)同管理的 onecode-vfs 虛擬目錄服務
- onecode-org用戶認證
- onecode-cluster集群節(jié)點管理
（2）應用類服務
- onecode-bpm流程服務
- onecode-iot物聯(lián)網(wǎng)應用支持
- onecode-jmq 消息服務
- onecode-index檢索服務
每一組服務，onecode也都提供了獨立的SDK支持方便集成調用。
三，OneCode低代碼微服務私有云技術特點
（1）基于微服務結構提供完備的集群分發(fā)及服務注冊發(fā)現(xiàn)服務
（2）獨立云存儲結構實現(xiàn)高安全高彈性擴展支持hdfs塊存儲便于超大規(guī)模部署
（3）基于事件響應設計，采用實時架構設計，支持mqtt協(xié)議便于高效便捷的接入設計
（4）提供采用微服務結構的流程云引擎，支持標準XPDL2.0,BPMN協(xié)議流程導入
（5）獨特的多開發(fā)者、多應用（租戶）支持，實現(xiàn)模板、主鍵、場景模型等多種資源共享公用
四，OneCode 私有云微服務配置
OneCode 在第四季度開放了，私有云的部署。并且在gitee碼云上上傳了，可以終身免費使用的低代碼開發(fā)云。
OneCode私有云部署包，本身是一個可以伸縮的部署程序包。可以通過調整本地的配置文件來完成各引擎是以微服務方式部署還是嵌入式部署：配置修改方式為修改配置包中 ： /useresbbean_config.xml 文件。
（1）嵌入式啟動
如果是嵌入式部署則在pom文件中引入引擎jar
<dependency> <groupId>cn.raddev</groupId> <artifactId>onecode-vfs</artifactId> <version>1.1.1</version></dependency>
同時在useresbbean_config.xml 增加本地服務檢索。
//本地服務裝載AR<configid>esb</configid><esb> <cnname>本地服務</cnname> <path>/../lib/:^onecode.*.jar;./lib/:^onecode.*.jar;</path></esb>//檢索本地Class裝載服務<configid>local</configid>2<local> <templetname>檢索本地Class</templetname> <path>*com.ds</path></local>
（2）微服務配置
在pom中添加對應的遠程訪問SDK接口jar
<dependency> <groupId>cn.raddev</groupId> <artifactId>onecode-vfs-web</artifactId> <version>1.1.1</version></dependency>修改用戶服務配置文件 useresbbean_config.xml<configid>bpmservice</configid><bpmservice> <cnname>工作流服務</cnname> <path>bpm_tempbean_config.xml</path><tokenType>user</tokenType> <serverUrl>http://bpm.raddev.cn:9080</serverUrl> </bpmservice>
（3）通過云控制臺修改配置
五，OneCode應用服務微服務支持
低代碼平臺引擎的微服務支持是低代應用的核心特性。但如何管理好應用服務并且能有機的融合到微服務體系中，成為微服務的關鍵組成部分則是更為關鍵的一個設計。
（1）應用微服務開發(fā)組織方式
onecode在應用服務開發(fā)方面采用了，多租戶的開發(fā)者模型設計。允許開發(fā)者使用開源的OneCode Studio使用開發(fā)者賬號登錄微服務開發(fā)云。并采用企業(yè)客戶，微服務工程管理，允許用戶自定義工程并將工程作為一個獨立部署的微服務節(jié)點發(fā)布。
（2）OneCode“工程”容器微服務技術設計
應用服務發(fā)布需要三方面的資源做支撐，分別是用戶通過設計完成的頁面及功能交互，通過特定的特定的出碼模板完成相應的技術棧前端轉換形成的前端頁面目錄。而后端應用則根據(jù)則是用戶通過基礎數(shù)據(jù)建模形成的領域模型文件，這些領域模型文件通常會按照，資源庫、支撐域工程域等模型方式來獨立打包方便后期版本管理及個體更新。另外第三塊則是方便工程啟動運行以及訪問控制，對外暴露監(jiān)控等相關的工程配置信息。
（1）后端打包結構總覽
低代碼應用中如果要具備完整的建模以及對外應用管理功能，就必然會涉及到后端數(shù)據(jù)建模以及基礎的邏輯編排功能，不同的平臺面向的開發(fā)者群體也會有所不同，有以解決簡單數(shù)據(jù)的增刪改查為目的初級數(shù)據(jù)庫建模應用也有面向專業(yè)開發(fā)者的領域建模應用。但不管哪一類的平臺，在打包編譯輸出的時候。通常會采用一下模型來完成。
（2）服務模型微服務描述
服務模型接口描述，通常采用的是Rest的web服務模式，每個工程會設定相應的命名控件，然后根據(jù)具體頁面的服務地址進行重新的編排以樹形的的結構來管理和展示webapi結構。
在接口描述中通常會包含：
URL地址：標識可通過WEB訪問的地址。
頁面綁定服務對象：當通過數(shù)據(jù)接口獲取數(shù)據(jù)后將數(shù)據(jù)和前端的容器、列表、表格、樹形等具體的組件進行綁定。
后端接收綁定：當前端數(shù)據(jù)發(fā)生變化時通過ajax或者表單提交等方式將數(shù)據(jù)同步到后端數(shù)據(jù)模型。
服務模型接口描述，在打包應用中是一個必備的選項，在完成打包后需要通知應用服務器完成相關的服務注冊同時也為應用服務權限等提供策略服務支撐。
資源（物料）目錄樹
用戶工程目錄樹：
用戶目錄樹是由用戶自行建立，同時也是工程編輯的入口，用戶通過目錄配置頁面路由。串聯(lián)相關功能。同時一些個性化的定義也有此導入。
前端支撐庫
主要跟開發(fā)者出碼時選擇的技術棧有關，通常也是作為導出模板配置的基本屬性。在基礎基礎棧中會配合相應的調試以及運行集成頁面，達到開箱即用的匹配能力。
后端服務
通用域打包
