01

覆盖“轻应用、轻业务系统、专业系统”的三类业务场景

针对前面提到的不同的用户和使用场景，我们做了进一步分析，这些场景大致可以总结分为“轻应用”、“轻业务系统”、“专业系统”三类业务场景，我们认为作为企业级的低代码平台，要能够具备支撑这三类场景的建设能力。

·  “轻应用”：通常类似信息收集类、数据处理类、流程审批类小场景，适合业务人员采用零代码方式建设；

·  “轻业务系统”：相比轻应用，流程或业务处理略复杂一些，包含一些页面、服务、数据相关的集成能力，业务人员或分行科技人员经过培训也能容易上手；

·  “专业系统”：对应银行的大型复杂业务系统，通常有专有的数据模型、复杂的计算逻辑以及分布式的架构体系，这种业务系统则需要科技部门的开发人员为主实施，可采用低代码、专业代码融合的形式，以更高的效率和质量，更适合的方案推动复杂业务系统的建设落地。

我们在设计也建设低代码平台过程中，充分考虑了上述三类应用场景建设需要，面向不同的用户和场景，均提供了相应适合的工具和能力方案支撑。让平台的用户均能体会到“零代码、低代码”平台带来的更高效的生产力。

本文接下将围绕着平台面向不同的场景所提供的一些特色能力展开，对普元低代码平台的设计思想、能力以及解决方案进行介绍，期望能够通过本篇文章内容为金融企业客户提供一些建设低代码平台的一些思路参考。

02

支撑“零代码、低代码、高低代码融合”的三种开发模式

上图为普元低代码开发平台的架构示意图，平台的底座是基于微服务云原生的应用开发平台，其为高低代码融合打好了坚实的基础。另一部分是DevOps平台，支持应用全生命周期建设，例如零/低代码开发场景中的应用环境自动化部署均依托DevOps实现。中间部分是平台零/低代码的核心内容，为不同角色的开发者提供了功能视图、数据视图、开发视图。基于这些场景化的开发工具，让开发者能够快速构建多种不同场景的数字化应用。

功能视图、数据视图主要是为业务人员建设轻应用提供的零代码视图和工具，支持快速开发表单、流程、图表、报表等应用。支持从Excel导入开始，通过向导式生成数据模型、表单、视图轻应用，消灭手工报表、跑腿流程。让数字化转型深入一线，实现科技普惠。

开发视图则是面向技术人员进一步提供了服务编排、脚本编写相关工具和能力，方便开发者进行“轻业务系统相关场景”的开发工作。专业代码开发工具则是为程序员提供的专业编码开发工具，应对前后端复杂业务逻辑、页面功能或专业领域算法的开发场景，在专业代码开发的同时支持与低代码开发配置结合完成业务系统建设，进而提升效率。

因此我们的平台设计针对不同的业务场景和用户分别提供更适合的工具和开发模式。示意图如下：

03

建设“复杂业务系统建设”的六个特色能力

‍在金融级“复杂业务系统”建设场景中，低代码开发模式需要具备更完善的支撑能力，包括但不限于：数据模型、质量与集成场景的支撑力；表单、视图、图表、报表、大屏等数据展现能力；服务交易组合编排对应的跨系统集成能力；端到端业务流程场景的灵活管控能力；一站式体系化的应用交付和管控运营能力等等。即便如此，低代码能够覆盖的场景还是有局限的，只能支持系统中相对复杂度较低的功能范围，很多复杂场景中，还是要程序员开发者进行编码实现功能逻辑，采用高低代码融合的方式来实现复杂业务系统高效、可靠落地。

接下来我们针对上述复杂业务系统落地的平台能力建设中总结的六大特色能力分别进行说明。

1.  技术融合的架构模式

近年来，大多数金融企业都在计划建设低代码平台以提升效率。部分先行者已经建设了低代码平台。在与部分银行企业沟通交流下来，我们发现大家建设过程中经常会走入一些误区，很多都是解决局部问题为主，缺少总体规划。常见问题如下：

• 引入的低代码平台不能融入已有架构体系，如：不符合微服务架构，多应用共享进程计算资源，应用间故障不隔离；

• 引入的低代码平台技术栈与银行已有的技术体系差异较大，难以沉淀复用与融合；

• 引入的低代码平台体系封闭，复杂场景无法实现，扩展困难，运维管控方式特异，无法适应银行既有的过程规范。

针对上述问题，我们认为建设低代码平台，架构上应该采用主流的微服务架构体系，能融入已有的技术架构最佳；技术上应采用前后端分离的主流技术栈，类似VUE、Spring Cloud等，同时信创也是目前一定要考虑的关键点；基于低代码平台开发应用过程中，应支持低代码配置开发与专业代码开发方式融合，低代码开发过程中要能复用高代码编写的组件与服务；基于低代码平台开发的应用，应该是各自独立的，不应互相影响，不论高代码、低代码或着是高低代码融合，不应带来应用的部署运维的变化，要能够融入已有的运维管理规范体系。

概括来说就是要做到架构一致、技术一致、运维管理一致的三个一致基础上的高低代码真融合模式。

2.  数据驱动的开发模式

市面上很多零/低代码产品为了降低开发复杂度，采用了页面驱动的开发模式。这种模式的优点是非技术人员更容易上手，开发体验更好。缺点是其数据存储会采用私有的格式保存，存下来的数据脱离其平台不可读。这种缺点会形成数据孤岛，在金融企业中是不可接受的。

根据金融企业的业务特点，我们认为数据驱动模式是复杂业务场景建设的更优方案。银行的各大业务领域，均有各自的专业领域的业务模型，这些模型通常是经过积累沉淀的复杂业务模型，具备行业知识门槛，几乎不会从零开始构建。另一方面，基于数据模型，我们可以与银行以后的数据标准做对接，这样一来数据表字段、类型、接口报文、数据校验、页面控件等等都可以标准化，能够实现高质量的数据落地，为后续的数据入湖、分析统计打好坚实的基础。当然建模的过程业务人员有一定的学习成本，这种情况下，低代码平台可以通过技术手段简化或自动化建模过程，由平台自动生成模型与数据表，从而降低学习使用难度，让业务人员更容易上手。

数据是金融企业的核心资产，高质量的数据落地是必要条件，因此数据模型和建模能力是必不可少的，我们可以通过标准化、自动化、智能化建模能力，在提升开发体验的同时保障数据高质量落地。

3.  组件化低代码页面引擎

低代码拖拉拽所见即所得的表单、视图页面设计工具已经是所有低代码平台产品的标配，在低代码平台的页面开发能力方面，应该重点关注如下几个方面：

页面引擎要支持丰富多样化的展现形式，如表单、视图、图表、报表、看板、大屏等等；

• 页面引擎要支持PC端、移动端页面设计与渲染；

• 页面引擎要提供丰富的前端组件，如基础技术组件、布局容器类组件、高级功能组件等等；

• 页面引擎要具备灵活的扩展模式，支持自定义扩展页面组件，支持封装复用已有的前端组件；

• 页面引擎要具备代码生成能力，生成的代码符合规范和安全要求，支持可控的编码调整能力。

在低代码页面引擎表面能力趋同的情况下，除了页面的美观和丰富展现形式外，灵活的组件扩展能力、源码生成可控调整能力、基于安全源码实时编译渲染的能力等，更应是平台建设或选择的关键特性。

4.  企业级低代码流程引擎

在流程引擎方面，在复杂企业级的流程场景中，通常会有两大类流程。其一是跨系统端到端的业务流程；其二是系统内部流程审批相关的操作流程。这两类流程的侧重点有所不同。端到端的业务流程，重点是跨系统的集成能力，如数据传递、服务调用、消息发送接收、外部系统的子流程调用与回调等场景；系统内的审批流程则更注重流程与表单的联动配合、审批处理人的权限范围规则、流程的分支流转规则、任务处理的复杂规则等场景。除了低代码产品化的配置能力之外，流程引擎的高性能与高可靠性集群模式运行支持，业务流程的运行期调整配置支持以及基于流程视角的统计分析能力都是必不可少的关键功能。

此外在流程银行的场景中，流程作为银行业务处理合规性的保障，面向整个银行都应该有一致的规范和标准。那么统一流程平台的支撑能力也是大型金融企业应多复杂业务场景的一个关键抓手，建设统一流程平台，面向各领域的多个业务系统提供流程支持，基于多租户技术手段，让各业务系统在共享的云流程服务中各自对业务流程进行一站式的设计、开发、运行和管理，让标准规范的业务、审批流程落实具备了明确可行的路径和可管控、可分析优化的依据，最终形成业务流程持续优化的闭环。

5.  高性能高可靠交易引擎

在银行的“中间业务”、“场景金融”这类业务场景中，显著的业务特点是相关业务会涉及与用户、三方企业、其他金融机构的密切连接，比如投资理财、生活服务、财富管理等等场景，业务多样性和复杂性较高，更注重个性化服务和合作协同。在这类场景下，不同企业、不同机构的对接需要具备很强大的集成和服务交易编排能力。通过一个高性能高可靠的交易引擎，能够以低代码的模式快速的让相关业务交易实施上线，银行才能在这些领域取得竞争优势，为客户提供更好的金融服务体验。

服务交易编排是低代码平台集成能力的核心体现，在通用场景中，有了服务编排的能力，可以让低代码平台的业务场景覆盖率大幅提升至80%-90%。针对金融行业的复杂集成场景，具备更强大集成能力的交易引擎就更为重要。我们认为，面向金融企业尤其是银行，服务交易编排的能力需要支持多种协议的集成能力；多种报文格式解析转换能力；高性能高可靠性的异步、并行运算能力；以及对于异常场景的交易错误处理、补偿冲正能力，以保障数据的正确和一致性。

另外，从低代码交易开发工具的角度，低代码流程式的交易编排工具必不可少，同时还需要支持开发过程中的在线调试以提升总体的开发效率；要支持运行期的源代码生成确保代码安全；尽可能采用编译运行模式，保障运行期的性能和稳定性。

6.  一站式交付与监控运营能力

对于“复杂业务系统”来说，通常会采用分布式的架构，具有实施交付周期长，运维管理复杂等特点。针对这种情况，作为低代码平台除了提供开发和运行支撑之外，对于应用的实施、交付、监控运营等场景也需要通盘考虑，提供全面的支撑能力和工具。

• 在应用实施过程管理方面，需要提供对于项目管理的支持能力，如需求、任务、测试、质量、文档等工具和管理能力。

• 在应用交付方面，需要提供对于应用的自动化部署，应对金融企业的多环境交付管理过程规范要求，需要支持开发、测试、UAT、准生产、生产等多类型多套环境的资源管理和自动化部署交付工作。屏蔽繁杂的手工重复劳动。

• 在应用监控方面，基于低代码平台上建设和运行的所有应用，应提供一站式的统一应用监控治理平台，对应用的配置集中管理，对运行健康状态、资源使用情况监控，以及对应用的日志、性能做集中的分析与统计。

• 在应用的持续运营方面，应用基于低代码平台从建设到运行过程中持续收集运营数据，逐步实现对应用研发效能、运行效能、业务效能以及企业效能的全链路运营分析。

04

低代码与AI

AI大模型在2023年可谓是火遍全球，带来了越来越多的新模式新机遇。我们说很快AI就可以帮我们编写软件了。目前已经能够通过提示词描述，AI大模型帮我们生成一些写的还算工整的代码片段，确实可谓惊艳。然而个人认为离编写生产可用软件还是有很大的差距。以目前的AI大模型的能力，采用生成软件源码的方案即使生成了一个软件系统，其可用性、可靠性并不能得到保障，想要基于其生成的软件源码去优化调整，非常困难。所以基于AI直接生成源代码的软件构建方案可行性目前比较低。更何况基于信息安全方面考虑，金融类企业也不允许开放自身的数据给大模型，应用场景也会有很多限制。

换个思路，我们发现低代码平台的模式本质上就是抽象了很多的开发、管理等专用模型。让AI与低代码的专用模型相结合，确是更具可行性的方案。基于专用模型来训练AI更容易，生成的“基于模型的软件”也具备规范性、可调优、可维护的特点。目前我们也已经在验证低代码结合AI助手的模式，如：数据模型推荐与生成、应用模块与功能的生成、专有低代码模型的辅助配置、专有API的代码生成等等场景。接下来我们还会在AI与低代码结合实践应用方面进行持续研究，陆续会有相应的迭代成果产出，敬请期待。

04

结尾

如果说有这样的一款低代码平台，其能解决业务问题，能提升开发效率，能融合主流的架构，能复用既有的沉淀，从简单到复杂的场景均能从容应对…… 这样的低代码平台相信您也会感兴趣。

关于作者：郝炎峰，普元首席方案专家，十余年产品研发与架构设计经验，持续关注和研究分布式、微服务、DevOps等领域。曾负责普元低代码开发平台、流程平台产品的核心架构、产品设计以及发展规划。先后参与了国家电网BPM、BAM平台、浦发银行新一代流程平台、兴业银行综合应用开发平台等大型平台项目建设与实施。现专注于金融科技建设相关解决方案研究与落地。

‍

– END –

 报告下载 

大佬观点