前言
低代码开发平台和微服务架构是当前软件开发领域的两个热门话题。它们都是为了更高效、更灵活地构建和开发应用程序而出现的解决方案。本文将以一款基于微服务架构的OneCode引擎为案例来探讨低代码开发平台和微服务架构的优势和挑战。
一，微服务架构在低代码平台中的优势
(1) 微服务设计优势
微服务架构是一种面向服务的架构风格，将应用程序拆分为一组小型、自治的服务。以下是微服务架构的一些主要优势：
1. 高度可扩展：微服务架构将应用程序拆分成多个服务，每个服务负责不同的业务功能。这种拆分使得应用程序的各个模块之间相互独立，可以独立部署和扩展。当某个服务需要扩容时，只需增加该服务的实例即可，不会影响其他服务的性能。
2. 灵活性和可维护性：由于微服务架构将应用程序拆分成多个服务，每个服务负责特定的功能，因此开发人员和团队可以更专注于某个特定领域的开发和维护。这提高了问题追踪和修复的效率，同时也增加了应用程序的灵活性，可以更快地适应业务变化。
（2）低代码平台为什么要采用微服务设计
1，企业内部整合开放式API需要微服务架构
在企业应用中，数据和业务通常会分散在不同的业务系统中，按照业务部门可以分为人事行政、项目、销售、研发、生产等等；按照当前的软件类别又可以分为ERP、SCM、CRM、OA、PLM、MES等等，但在企业的数字化应用场景中，按照业务类型通常包括数据信息管理、业务审批、各类报表分析以及其他业务。在低代码应用初期主要场景还在于基于各业务开放API之上的快速应用扩展，但发展到一定阶段后，这些扩展则会形成一些新的资源池。而这个资源池的最佳的管理方式则是采用微服务架构的 apaas 平台。在低代码平台设计中易用以及便捷性是首选但作为企业级应用而言，对于基于 开放API的管理也是其必选的一个基础性功能，而微服务则是这一管理应用的最合适选择。
添加图片注释，不超过 140 字（可选）
2，低代码平台引擎化设计最佳实践
添加图片注释，不超过 140 字（可选）
我们在解释什么是低代码平台时，最常用的关键字是：图形化、拖拉拽方式快速实现。但这些简单特性的背后，则是低代码平台的高复杂度设计，高度抽象概括，直至衍生出来一些专为低代码应用而生的“专职”低代码引擎如：可视拖动引擎、流程驱动引擎、模型驱动设计（DDD）引擎、存储引擎、以及专为各垂直行业而匹配的“IOT低代引擎”，“电商低代引擎”等等。这些引擎的设计为低代码平台赋予了更广阔的应用空间，但同时也为低代码平台带来更多的复杂性。这在低代码平台自身的“内部生态”中微服务设计则是不二的技术首选。
3，应用服务持续集成devops最佳方式
添加图片注释，不超过 140 字（可选）
在企业级应用中，低代码作为新生的事务。必然会先从一些边缘业务开始，逐步向核心业务靠拢。而有实力尝试低代码引擎这种新技术的企业，多数都具备了相对完善的发布和管理的流程。对每一个应用的上线运行都有比较严格的流程安全规范。低代码应用如果仍然采用传统部署方式上线则需要根据企业的自身的应用发布测试流程进行整合，完成代码入库、版本管理，发布脚本，测试脚本等等众多技术性的要求。这显然与低代码本身的设计理念相悖，同时这些定制化也会大幅增加平台服务方与用户方工作量。解决这一问题最简单的方式便是提供独立的DevOps支持，特事特办，针对轻应用的特点，提供独立的运行、测试、发布部署环境支持。在企业原有服务中作为一个独立的服务中间件。而这些独立的应用服务则是微服务架构的最佳实践。
二，OneCode微服务私有云整体设计
onecode私有云结构
OneCode私有云是OneCode低代码引擎的开发依赖环境 ，OneCode低代引擎运行需要依赖一些集成环境来支持，这些支持可以根据具体的用户场景来配置同时，OneCode也为这些提供了一些默认的微服务实现。包括：
（1）支撑服务
- 开发代码协同管理的 onecode-vfs 虚拟目录服务
- onecode-org用户认证
- onecode-cluster集群节点管理
（2）应用类服务
- onecode-bpm流程服务
- onecode-iot物联网应用支持
- onecode-jmq 消息服务
- onecode-index检索服务
每一组服务，onecode也都提供了独立的SDK支持方便集成调用。
三，OneCode低代码微服务私有云技术特点
（1）基于微服务结构提供完备的集群分发及服务注册发现服务
（2）独立云存储结构实现高安全高弹性扩展支持hdfs块存储便于超大规模部署
（3）基于事件响应设计，采用实时架构设计，支持mqtt协议便于高效便捷的接入设计
（4）提供采用微服务结构的流程云引擎，支持标准XPDL2.0,BPMN协议流程导入
（5）独特的多开发者、多应用（租户）支持，实现模板、主键、场景模型等多种资源共享公用
四，OneCode 私有云微服务配置
OneCode 在第四季度开放了，私有云的部署。并且在gitee码云上上传了，可以终身免费使用的低代码开发云。
添加图片注释，不超过 140 字（可选）
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）通过云控制台修改配置
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
五，OneCode应用服务微服务支持
低代码平台引擎的微服务支持是低代应用的核心特性。但如何管理好应用服务并且能有机的融合到微服务体系中，成为微服务的关键组成部分则是更为关键的一个设计。
（1）应用微服务开发组织方式
onecode在应用服务开发方面采用了，多租户的开发者模型设计。允许开发者使用开源的OneCode Studio使用开发者账号登录微服务开发云。并采用企业客户，微服务工程管理，允许用户自定义工程并将工程作为一个独立部署的微服务节点发布。
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
（2）OneCode“工程”容器微服务技术设计
应用服务发布需要三方面的资源做支撑，分别是用户通过设计完成的页面及功能交互，通过特定的特定的出码模板完成相应的技术栈前端转换形成的前端页面目录。而后端应用则根据则是用户通过基础数据建模形成的领域模型文件，这些领域模型文件通常会按照，资源库、支撑域工程域等模型方式来独立打包方便后期版本管理及个体更新。另外第三块则是方便工程启动运行以及访问控制，对外暴露监控等相关的工程配置信息。
添加图片注释，不超过 140 字（可选）
（1）后端打包结构总览
低代码应用中如果要具备完整的建模以及对外应用管理功能，就必然会涉及到后端数据建模以及基础的逻辑编排功能，不同的平台面向的开发者群体也会有所不同，有以解决简单数据的增删改查为目的初级数据库建模应用也有面向专业开发者的领域建模应用。但不管哪一类的平台，在打包编译输出的时候。通常会采用一下模型来完成。
添加图片注释，不超过 140 字（可选）
（2）服务模型微服务描述
服务模型接口描述，通常采用的是Rest的web服务模式，每个工程会设定相应的命名控件，然后根据具体页面的服务地址进行重新的编排以树形的的结构来管理和展示webapi结构。
OneCodeAPI模型
在接口描述中通常会包含：
URL地址：标识可通过WEB访问的地址。
页面绑定服务对象：当通过数据接口获取数据后将数据和前端的容器、列表、表格、树形等具体的组件进行绑定。
后端接收绑定：当前端数据发生变化时通过ajax或者表单提交等方式将数据同步到后端数据模型。
服务模型接口描述，在打包应用中是一个必备的选项，在完成打包后需要通知应用服务器完成相关的服务注册同时也为应用服务权限等提供策略服务支撑。
资源（物料）目录树
前端资源目录总览
用户工程目录树：
添加图片注释，不超过 140 字（可选）
用户目录树是由用户自行建立，同时也是工程编辑的入口，用户通过目录配置页面路由。串联相关功能。同时一些个性化的定义也有此导入。
前端支撑库
主要跟开发者出码时选择的技术栈有关，通常也是作为导出模板配置的基本属性。在基础基础栈中会配合相应的调试以及运行集成页面，达到开箱即用的匹配能力。
后端服务
添加图片注释，不超过 140 字（可选）
通用域打包
添加图片注释，不超过 140 字（可选）
