普元高低开融合平台建设之路

2022年我们公司在应用域这条线，主要聚焦在专业微服务开发和低代码开发的融合，在这里跟大家分享我们的平台定位、重点聚焦以及后续发展的思路。

目 录

01 为什么要做融合平台

02 普元高低开融合方案

03 后续发展计划

01

为什么要做融合平台

软件发展的长河中，IT要解决的问题一直都很聚焦，无论是架构的变迁，还是组织的变革，无非就是为了解决以下三个问题：

1.不要重复造轮子，比如组件复用、资产沉淀、数据共享等

2.不要将应用做成单体或竖井，比如SOA、微服务、能力开放等

3.降低组织或部门的隔阂，比如BizDevOps、企业建模、敏捷等

尤其这些年，随着数字化应用概念的盛行，IT好像已经变成了『人皆可为』的行业，简单拖拖拽拽就可形成一些轻应用，用于解决日常工作信息化的问题。如果这些工作还能结合云原生、服务网格等基础设施，那大家就更喜欢了。

普元这5、6年来，在应用领域也同样在追求这些平台能力，无论是微服务、DevOps，还是低代码、零代码，我们都研发了对应平台，来支撑我们的业务解决方案，或输出技术平台给我们的客户。

我们首先进入的是微服务和DevOps领域，通过提供高代码的开发工具、运行引擎、治理门户，帮助客户解决架构分布式转型的问题。

接着在19年，我们进入低代码领域，提供在线应用低代码门户，快速支撑数字应用的开发。当然，我们也结合了公司的基因，并不是做一个面向所有领域、所有系统的低代码平台，主要聚焦在流程平台、通用管理类系统（OA、PM等）、个性化数字应用（数字工单、数据填报等）。

但是在我们的项目实施中，我们遇到了一些未料到的挑战，主要体现在下面三个方面：

1、架构孤岛

2、技术偏差

3、个性化需求

架构孤岛：在很多客户那边，高代码和低代码是两个独立平台，只能做到远程调用打通和SSO集成，其实这个模式，等于在企业里变成了两个孤岛，不同平台上的应用的开发模型、部署模式等都存在很大的差异，这肯定不是企业想看到的。

技术偏差：大部分低代码平台，其开发的应用是一个单体系统，甚至有些低代码平台，甚至是多个应用在共享一个引擎（物理上不隔离），这和企业现在往微服务架构升级多少是有些相悖的。企业更希望的是无论高低开应用，开发出来最终按下图的左边部分去部署，而不是右边部分。

个性化需求：企业需求不可能是简单的增删改查，各种外部交互、个性化UI会伴随在系统建设过程中，所以对组件的抽象、高低开的职责切分等非常重要，就像下图中的举例，如果总想着初级工程师通过低代码解决所有，最终换来的会是更大的维护代价。

在这样的问题背景下，我们期望做到高低开融合的平台能力，这个融合不仅仅是说分工职责的融合，更多需要技术栈、运行引擎、运营模式的一致化。

02‍

普元高低开融合方案

如下图所示，我们期望应用间首先需要保持隔离性，接着是一个应用的组成，既可以是独立低开或高开的，也可以是物理上融合的形态，前端支持资源的重组、通信，后端支持服务的重新编排、高低开资源本地引用等。

而高代码和低代码的配合，要逐步演化到高开负责组件和复杂业务逻辑的抽象或扩展，低开则快速进行业务配置开发。比如高代码负责表单的组件扩展，低代码则直接拖拽使用，再比如高代码负责流程参与者的业务规则抽象，低代码则直接选择使用。

因为高代码的能力，在以前的一些文章中，我们同事已经有过介绍，所以这次我主要介绍低代码部分的能力。首先我们提供了一套在线低代码的开发门户，这个门户中分以下几个区域：

1、在线资源区：管理实体、页面、流程、服务等资源

2、资源编辑区：通过图形编辑器，开发配置在线资源

3、离线资源区：应用内高开的成果，可以在此处查找和应用

4、问题反馈区：在线开发问题定位相对更复杂，需要更好的配套问题定位能力

先说说模型开发，普元低代码还是定位在相对中大型系统的开发，所以我们更期望是数据模型来驱动的设计开发，而不是表单模型驱动。平台提供了三类实体（后续可能还会补充独立查询实体），这些实体之间可建立引用关系，最终作用到数据管理的通用逻辑。

1、持久化实体：主要针对关系库的实体建模

2、服务实体：外部服务交互的参数类型、返回值类型的建模

3、引用实体：对高代码中，或其他模块里的已有实体的引用

通过实体模型，可以生成默认的表单和视图，页面这块我们采用的是拖拽设计，可生成源代码的模式，这样即使遇到一些个性化页面，我们也可以让用户基于源代码做一定的个性化调整，甚至直接下载到高代码工具中进行编码维护。

表单这块我们支持多态管理，形成表单级复用（业界很多低代码是在流程环节上去调整控件多态的，个人感觉必要性不大，毕竟这个是页面状态的设计，完全可以跟着页面来做）

流程开发一直是普元的强项，在低代码中提供了包括操作按钮设置、业务规则设置、参与者设置等一系列的能力，同时还集成了普元流程的事务分割、异步调用、异常处理、自由流等高级能力，并且提供了PC和移动端的业务流程审批框架。

服务是对于针对服务编排场景，提供了在线开发配置能力。随着业务场景的积累，服务需要提供各类开箱即用的模板，如流程事件、实体增删改查等。服务中可以使用高代码开发出来的各类运算逻辑，也支持在线完成groovy脚本编写，应对循环、赋值、常用工具类等需求。

BI则通过在线数据集的建立，支持用户配置图表、交叉报表、看板、大屏等，对于交叉报表，支持同比, 环比, 占比, 汇总，支持交互式自由钻取，任意维度钻取操作，平台提供类Excel单元格设计，支撑依赖计算等复杂报表。

最终无论是高代码还是低代码开发出来的资源，通过应用联邦中心可以统一注册、授权。这里的应用联邦中心是一个多应用综合管理门户，支持通过微前端技术，将不同应用进行统一展示，同时可对页面、功能、数据进行细粒度授权，做到千人千面。

结合普元微服务、DevOps等能力，最终高低开融合平台的全景如下：

1、适配信创环境，包括常用服务器、操作系统、数据库等

2、提供统一流程中心，多租户、多应用共享使用

3、提供应用联邦中心，解决应用共性问题，如组织机构、授权、认证、三员、字典等

4、提供BI引擎，提供OLAP能力以及展示资源管理

5、提供高代码和低代码的开发环境，配合使用，有效结合

6、提供统一应用治理门户，对域、系统、应用、服务等统一配置和监控

7、提供能力开放中心，将多应用能力统一对外开放，支撑企业互联

8、提供默认的业务门户，提供可配置的业务门户，支持多应用前端打散重组

03‍

后续发展计划

最后谈一谈平台后续的计划，除了日常功能优化和体验提升外，我们会重点考虑下面四个方面：

1、根据行业特征、系统特征，持续积累业务组件，驱动更多场景的零代码开发

2、增强连接器能力，现在已经解决了系统互联问题，后续要优化链接能力，同时还需要考虑更多生态互联的事情

3、数据低开结合，应用、流程等产生数据后，现在具备的是BI能力，其实更长远来看，还需要一定的ETL开发和调度能力等，正好后续和普元在做的另一块数据低开可有效融合

4、应用商店+能力开放，通过大颗粒应用模板能力，支持更大粒度的复用，标准化复用，个性化调整

关于作者：顾伟，普元数智研究院总经理，首席架构师，中国人工智能协会机器学习专业委员会委员，全球容器技术大会、全球软件研发行业创新峰会特约讲师。主导和推动普元微服务、研发运营一体化、主数据、企业服务总线等产品系列的版本演化和升级，精通基于SpringCloud的Netflix生态和Alibaba生态分布式解决方案，在需求结构化的描述方法、可重用体系架构的设计方法、业务可变性设计方法领域有深入的研究与实践，长期为广东农信、北京银行、九江银行等企业提供架构资产管控模型咨询与服务，参与工商银行、兴业银行、中国邮政集团等企业的数字化软件研发架构体系设计与规划。