深度|低代码开发平台和微服务架构的优势与挑战

前言

低代码开发平台和微服务架构是当前软件开发领域的两个热门话题。它们都是为了更高效、更灵活地构建和开发应用程序而出现的解决方案。本文将以一款基于微服务架构的 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）支撑服务

1. 开发代码协同管理的 onecode-vfs 虚拟目录服务

2. onecode-org 用户认证

3. onecode-cluster 集群节点管理

（2）应用类服务

1. onecode-bpm 流程服务

2. onecode-iot 物联网应用支持

3. onecode-jmq 消息服务

4. 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 字（可选）