高低开走向融合，是低成本应用建设的最终解决之道

最新推荐文章于 2024-10-16 09:19:27 发布

普元EAWorld

最新推荐文章于 2024-10-16 09:19:27 发布

阅读量764

点赞数

文章标签：大数据编程语言人工智能 java python

原文链接：https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=2660424765&idx=1&sn=7572580be1b5bd628396f59730bd52c0&chksm=f742fedbc03577cdc2c52b247c599b080693563d7b899732d70bc83fd8112cbd83199687404a&scene=126&&sessionid=0

版权

顾伟——现任普元数智研究院总经理，长期负责公司的应用和数据平台发展，在微服务、DevOps、低代码、数据治理等领域有丰富的研发与实施经验，主导了多家大型企业的云原生与低代码平台建设。

引言

前两年市场大谈云原生、技术中台、业务中台等概念，企业更多的聚焦在业务与IT架构的升级。而这两年，随着低代码、生成式AI的盛行，大家则开始挖掘数字化应用的廉价建设模式。

我们团队也紧跟着市场脚步，将分布式应用平台进行不断迭代，期望获得低代码、组装式应用程序等热点加持。但在最终客户的平台建设时，尤其在低代码应用的交付上，遇到了诸多问题，举几个典型的例子：

应用个性化要求太多，单靠低代码模式难以实现完整功能怎么办？
工程师能力不足（事实上很多企业认为低代码是为了让初级人员玩），平台稍微开点代码口子，各类脚本片段就满天飞，应用后期如何维护和优化？
低代码平台使用了动态渲染或解析执行等技术（比如很多低代码平台的表单或服务就是这类机制），性能不足如何提升？

回归问题本质，低代码应用建设的规范、低代码适合场景的圈定、相关引擎技术的选择、与遗留系统高体验的交互，是低代码平台研发必须要面对的抉择。

低代码的应用场景建议

低代码平台最怕的是：领导很想用，技术用不好、业务不会用。说白了就是市场帽子戴的很高，在企业四处传道，但是到具体系统建设时，技术团队发现只有少量的功能开发可以用上，一些向往由业务团队来建设系统的企业，对业务人员又要求太高，动辄就要学习脚本编写额和模型设计，而这正是现在低代码应用场景的真实写照。‍

诚然，我们看到一些开发商建立了不错的客户案例，但基本上是聚焦在下面这几种应用场景：

如果单纯的依靠低代码平台建设应用，上面的几类场景范围我觉得已经足够大，各开发商需要逐步将自身的重点方向业务化，方能形成更优的市场格局，而不是大家都是奔着通用市场的技术型玩法。而我们团队在第一阶段也是技术型通用场景的做法，导致不少项目通过低代码解决了70%-80%的问题，剩下的则很难搞定（往往这部分反而是关键需求），项目交付阻力很大。所以在第二阶段，我们一部分团队聚焦特定的业务领域去做积累（如项目管理、中间业务等），另一部分则围绕高低开融合的思路，力求能够支撑更广泛的分布式应用建设。

高低开融合的职责切分

讨论高低开融合，我们可以先来看看两个常见的融合架构设计误区：

第一张图是业界常见高开和低开应用融合模式，两者独立建设，技术实现确实相对简单，但是难道需要高低开融合的数字化应用，以后都是这种建设模式吗？显然是不对的，这种＂混合＂模式，本质上又建立了一个低代码孤岛，仅仅是通过技术手段将两者混合在一起。

第二张图则是业界常见的低代码应用最终部署结构，考虑到商业问题，企业不太会采购多套低代码平台，如果只是为了承载单应用建设还好，但如果是建设多应用时，这些低代码应用之间往往没做物理隔离，而是运行在一个进程当中（甚至数据层可能都没有完全隔离，统一启停和升级），这在大型企业的是不可想象的。

考虑到我们面向的主要客户的IT体量都比较大，在高低开融合方案设计上，我们确定了三个不可违背的设计原则：

应用采用高低开融合建设，但应用资源要运行在同一个进程中；
各个最终应用之间，默认是完全隔离的部署模式；
低代码开发的资源可无缝引用高代码资源，反之默认不允许。

前两个原则比较好理解，第三个可能大家会有疑问，为何不做双向引用（在后面的技术栈里也会涉及），这里需要澄清的是：引用的意思是指资源之间的强关联应用，比如高开的服务编排里，使用低开的数据模型，这个我们是不允许的，如果是高开的页面中，通过微前端模式局部展示低开的表单，这个是没有问题的。最终我们对资源做了详细的切分，高开上提供什么类型的资源设计开发，低开上支持哪些，如何本地化使用等，形成了深度融合的开发与运行架构。

上面这张图是高低开融合的全景图，里面包含了高低开都需要的开发、运行、治理、服务发布，以及流程、组织、权限这类企业级应用需要共享的服务等，如果大家关心具体资源的融合与引用关系，我们则可以关注下面这张示意图，最终高低开的多个模块是打成一个完整包来投产的：

低代码的技术栈选择

首先低代码平台本身需要从场景、性能、可维护等角度考虑，形成技术栈的抉择，比如：

前端表单页面：走代码生成模式还是动态渲染模式
后端服务编排：走源码动态编译模式还是图形解析执行模式

再者想做到高低开融合，在资源的可配置、可管理、UI体验等方面有很多细节要打磨，比如：

在线表单和离线界面如何融合到某个复杂页面中
权限配置如何保证支持到最细粒度（菜单、按钮、API、数据等）

当然还有包括内外部市场环境等因素，像数据库、浏览器等考量也是不可获取的。目前我们支持了如下的融合技术场景：

拿前端选型为例，为了页面间的重新融合组装，使用了基于webpack5的微前端模式，同时高开和低开在不同终端上，各自使用了同一套UI库。做第一版时，采用了中间模型动态渲染的模式，在遇到一些特大页面时（150+控件），性能极具下降（当然，和第一版开放了太多代码口子也有关系，单纯的静态页面也不至于慢太多），于是在第二版直接换成了代码生成模式（生成的代码可有限修改），大大提升了性能和灵活性。

再比如用于后端逻辑实现的服务编排，则根据在线编排的流图，运行期生成了具体java代码，并通过jdt能力编译成class并加载，比起执行时的单步解析方案要快很多。所以上述的前后端技术方案，使得其实无论低代码还是高代码，运行的实际资源是技术一致的，从而避免了多套引擎的开发和维护问题。

高低开平台实施效果

离线高开工具这里就不在赘述，在线低开则提供了统一的在线应用开发环境（微应用），支持多团队多人协作，应用开发入口界面主要包括四大区域：

在线资源区：提供在线资源的创建、删除、重构等
资源设计区：提供各类资源的编辑器，包括表单、流程、服务、模型、数据集、报表、大屏等
离线资源区：提供应用本身的高开资源以及依赖资源，供低开资源引用
问题反馈区：在线工具同样需要支持快速调试以及问题定位，此区域会将设计开发问题统一记录并做资源关联

具体的各类资源设计器，使用的技术不尽相同，具体会在后续大会上详细分享，最终设计出来的资源，则需要与低开进行统一的发布，然后与组织机构权限结合，支撑业务场景，平台目前默认支持多应用、多租户的模式，可定义页面、功能、数据、流程等不同类型的资源，资源有二级分类，比如页面中会包含高开的微前端页面、或者低代的报表、表单页面，支持将各类资源统一进行授权，最终形成完整的业务门户。