轻舟低代码产品化进阶之路

原创严跃杰管中窥豹非其全

前段时间通过《低代码发展现状调研》向大家简要介绍了低代码产品现状以及近两年牵引低代码快速发展的内外部因素，文章同时提到了低代码不是先有标准再出现的事物，它其实是Forrester和Garnter等市场研究机构对一类具备某些特性的高生产力应用开发平台（HPaPaaS）的归纳。不同类型的低代码厂商虽然目标相近，但是各自出发点和发展路径不尽相同。

今天我们就来聊一聊轻舟低代码想法的萌发和产品发展的情况。以我们产出和认知水平区分，大致可以分为四个阶段。

第一阶段：探索和认知萌芽阶段，从前端物料平台到web前台应用（低代码）开发平台

2020年3月及往前，作为云计算业务支撑技术小组，我们负责了云计算相关的所有web系统的建设，为了有效支撑大量云计算产品上线和运营，我们产出了一整套前端物料体系和一套行之有效的方法论，有效的提升web前端开发效率。（参考文章前端技术体系升级驱动生产力跃升）

在此基础上，为了推广我们的物料体系和方法论应用于更多的产品和团队以产生更大价值，我们搭建了物料平台，期望各团队用该平台托管前端物料并规范协作模式。但在推广时遇到了两个问题：

公司各部门有着各自不同的前端技术栈和组件库，难以统一。
各团队不同的目标、松散的管理机制和开发人员的固有思维（虽然造轮子辛苦，但是有掌控力有成就感）限制了大家技术共建的动力。

由于这两点因素，物料平台的推广并不顺利，当时我们讨论了两个方案：

物料平台作为方法论的承载，支持基于不同技术栈和组件库的物料托管，通过这种方式让其他部门用起来。这是一种横向思维。
基于现有物料体系完善、实现可视化搭建等能力，进一步提升开发效率并降低上手难度，赋能非专业前端工程师开发全栈应用的能力。这是一种做深做透的纵向思维。

考虑到第一种方案各种不确定性，也考虑到第二种方案更有可能成为一个高价值的技术产品，我们尝试往纵深发展。在做19年工作总结的时候我提出了web前台应用（低代码）开发平台的想法。（参考文章企业如何构建高效的利于创新的web前台应用开发体系）

当时我对web前台应用抽象和开发模式理解如下图：

应用开发工程师通过“低代码应用开发平台”高效开发出web前台应用；
后端服务开发工程师开发出各种通用领域服务和应用特有的微服务，并提供接口为前台应用所调用。

这个阶段，我们的主要目标还是提升web前端开发效率，不过关注点从前端物料平台转移到web前台应用（低代码）开发平台，萌发了低代码产品化初步想法。同时也通过文章分享的方式从上到下做了一些布道，开拓了大家对于web应用开发的一些新的思路。

第二阶段：产品立项和原型实现阶段，从web前台应用到完整应用的低代码开发。

1.二阶段目标的变化及原因

在我们思考提升web前端开发效率的同时，轻舟微服务团队正苦恼于微服务产品无法直接满足企业需求：对绝大部分企业客户来说，他们需要的是能直接解决他们业务痛点的应用软件，但微服务产品只是这些应用软件的底座（好比是一个操作系统）。如何解决企业应用开发和交付问题，成为轻舟商业化无法绕开的门槛。（参考文章要为传统企业做好“应用软件”除了“轻舟”还需要什么？）

因此微服务团队正在调研通过MDD的方式快速生成微服务代码的脚手架工具，并最终决定以开源的 jhipster工具为基础来实现自己的高效开发微服务的产品。

在领导撮合之下，两边同学一合计，既然我们可以通过可视化方式搭建出前台应用，也可以通过MDD的方式产出后端微服务，把这两项能力结合就形成了一个完整能力的低代码产品。基于这种直接和朴实的整合思维，当时我们对低代码web应用理解如下图：

这种抽象的特点是，一个完整的应用至少有两个（一个web服务和一个微服务）或两个以上的服务构成。从程序员的角度来理解，这种抽象非常直观及合理。不过也是从这个时候开始，我们开始认真思考应用抽象问题，也开始调研其他低代码产品，由此带来的一些认知改变影响了后续产品化实践阶段的一些决策（后面会有详述）。

这个阶段，我们对低代码应用的抽象和开发模式理解如下图：

由于下述两个原因：

通过可视化搭建出来的web服务，需要通过写js代码的方式来完成后端接口调用、数据组合转换映射等处理，而且由于需要了解很多上下文信息，这种代码编写体验非常不友好。
通过MDD生成的微服务，在实现自定义逻辑的接口时，需要打开在线vscode编辑器进行代码编写，同样的除了需要掌握java语言，这种在大量代码文件里面找到准确位置写代码的方式实践起来也很有难度。

因此，这个阶段我们看到“业务专家（产品）”基本上还无法直接通过低代码平台参与到应用开发过程中；应用开发工程师要开发一个完整的应用，不仅要懂两门语言、而且开发难度还不小。-- 这正是后面产品化阶段要解决的关键问题。

2.二阶段产品原型实现的介绍

由于产品立项的需要、同时也希望能赶在云创数字+大会上亮个相，我们在5、6月启动了项目攻关，完成这一阶段低代码平台产品原型的开发，并通过该平台完成了首个demo应用搭建。下面是这个阶段平台的一些关键设计的介绍。

1).应用&服务开发及发布主流程

在这个流程中，首先我们设计和实现了web服务和微服务的可视化设计到产出代码的完整流程；其次提供在线vscode编辑器实现对代码的二次开发以满足各种场景能力；最后，我们对接轻舟cicd和容器云平台为web服务和后微服务提供了一键发布的能力。这种方式实现了应用开发提效的基本目标，但是缺点也很明显：

应用开发过程仍需要写不少代码。
一旦用户经由vscode对代码进行二次开发，无法回到可视化编辑状态，即低代码搭建过程是单向的，无法通过可视化方式进行迭代。--这也是后面产品化阶段要解决的关键问题。

2).低代码平台的实现架构

低代码平台本身是构建在轻舟微服务平台之上的一个应用，主要分为四块内容：

低代码平台。他是springboot+vue（vusion）搭建的单体应用。它承担的职责主要有以下几项：

对接认证与权限中心实现对应用开发工程师的认证和访问控制
实现应用和服务的创建、管理及数据的存取；在服务创建时，负责初始化服务开发需要的环境并拉起相关开发服务
将应用开发工程师在前端的搭建操作转发给web开发服务和微服务开发服务
对接云端代码仓库、cicd、镜像中心等服务，提供代码提交、服务发布等能力

web开发服务。用户通过低代码平台创建web服务时，平台会初始化web服务的一个全栈模版，并且拉起web开发服务，web开发服务中有三个进程，分别完成如下功能

文件操作进程：接收用户可视化操作命令，将用户在页面端操作翻译成代码写入文件
编辑区进程：根据文件变更更新可视化编辑区
应用预览进程：支持用户预览当前开发的web服务

微服务开发服务。其实就是以jhipster工具为基础的MDD脚手架工具，它能根据实体设计产生微服务框架代码。微服务开发服务是所有微服务公用的（整个平台只有一个）；但vscode online server是每个微服务特有的，用户创建微服务时，平台会为该微服务单独拉起一个。
认证与权限中心。这是一个官方提供的通用领域应用，它实现了如下能力
认证与权限应用自身、及低代码平台都通过该应用进行认证与授权管理。它在资产中心发布了登录组件，低代码web服务可以直接引入该登录组件使用其认证能力，同时可以通过应用开发者账户登录认证与权限中心，对所开发的应用进行授权管理。

本身提供了账户名密码认证的能力，同时提供了对接ldap、openid、微信oauth2.0等第三方认证的能力
提供了标准的RBAC角色授权模型
提供了多租户隔离的能力

3).低代码平台的功能架构

低代码平台主要可以划分成如上6个主要的功能域：

应用&服务管理域，主要负责应用及应用下服务的创建、详情查看、设置、删除等功能，后续会提供服务状态监控的能力。
可视化编辑功能域：负责web服务可视化搭建、微服务MDD可视化设计，这是低代码平台的主功能域，应用开发者的大部分工作在这个功能域完成
代码编辑域：用户通过在线vscode实现代码二次开发、调试能力，省去了环境搭建的麻烦
发布管理域：通过对接轻舟cicd平台提供的web服务和微服务的一键发布能力，跟踪发布进度、了解发布历史和实现发布回滚。
资产中心：提供了低代码开发所需要的各种模版、静态或运行时的各种软件资产，并明确了各类资产的管理方式。这块是低代码平台应用生态构建的关键，是成为真正的平台型产品的关键。（了解什么是平台型产品参考文章平台型产品研发的一些思考和总结）
配置中心：这里抽象了平台需要依赖的主要几个外部系统。

3.阶段性的一些成果

1). 这个阶段，我们通过两个月时间集中攻关开发出了低代码平台产品原型，并以此创建了第一个低代码DEMO应用；7月16日的云创数字+大会上，低代码平台以轻舟产品体系一员成功亮相。

2). 基本上让部门领导认可了低代码产品的价值和发展前景，产品在部门成功立项。并争取到部分资源投入产品化开发工作中。

除了产品原型的开发之外，这个阶段我们做了另一项很重要的事情，是开始认真思考应用的抽象设计，调研其他低代码产品（outsystem、ivx、轻流等等），这使得我们对低代码应用的理解逐步完善，为后续产品化实践指明了方向。

第三阶段：认知跨越和产品化阶段，从面向开发者提效到赋能业务专家

低代码产品在数字+大会的亮相之后，陆续有用户上门咨询，一方面坚定了我们做低代码产品的想法，另一方面也给了我们产品化的压力。

产品方面，一方面我们要解决二阶段遗留的一系列问题（应用开发工程师要掌握不同语言技术栈、仍要写很多代码、编辑代码后无法回到可视化编辑状态等等）；另一方面，伴随着相关低代码产品深入调研（产品调研情况后续单独介绍，这里暂不展开）、跟客户的沟通以及思考的逐步深入，我们对应用抽象有了更加清晰的认知，看待问题的角度也能够逐渐从程序员固有思维中跳脱出来。如果说阶段一、阶段二是研发提效的目标驱动和程序员本能的行为，那么从阶段三开始，我们真正走上了产品化之路。

1.抽象出描述低代码应用的DSL

低代码可以认为是4GL的一种产品实践，在4GL中用户定义“做什么”，而不是“怎么做”，并通过更高级抽象的（低代码）工具生成应用程序。如何让用户准确的描述“做什么”，就涉及到DSL的设计。DSL的作用和价值主要有以下几项：

完整的表达低代码应用及组成应用的、用户可操作的各种设计元素。这个阶段，我们将低代码应用的设计元素定义为“应用、服务、页面、接口、逻辑、数据、权限配置、流程配置，资产中心的各种模版、静态物料和运行时资产”（参考下一小节），这些设计元素都被表达为DSL对象。低代码应用搭建的过程就变成了用户通过对各种DSL对象的配置、组合形成一个DSL应用对象的过程。
保证各种设计元素具有灵活的可复用性。通过DSL表达的各种设计元素，可经由规范的机制上传到资产中心，比如应用可以被抽象上传成为应用模版、服务被抽象上传成为服务模版、页面被抽象上传成页面模版等等。资产中心所有资产（设计元素）都会被表述成DSL对象，这些DSL对象可以被应用到不同应用的搭建中实现复用。
保证应用表达有足够的可扩展性。可扩展性体现在两个方面，第一点是在平台已有的设计元素分类上，专业开发者可以贡献出各种丰富的专业的DSL对象，这些对象可以被引入到应用中满足各种需求场景；第二点是以DSL代表的应用抽象本着“由简至繁、可逐步演进”的设计思想，我们可以在保证兼容性基础上对设计元素进行调整或者新增，以保证应用有更加合理的表达方式。
保证低代码平台本身架构稳定性。有了这层DSL之后，低代码平台本身架构就能稳定下来，这种稳定性体现在三个方面：

第一层，低代码平台、DSL跟应用程序之间，好比是工厂、模具和产品的关系。好比工厂可以应用不同模具来生产不同的产品，低代码平台也需要允许DSL的变化以满足用户需求（而且我们还在产品试错迭代阶段，变化会更加频繁）。这时候把变化收敛到DSL（模具）就很重要，他能约束这些调整不会蔓延到低代码平台（工厂）架构上去。
第二个方面是形成了“应用设计”和“应用实现”这样两个稳定的分层。分层的价值主要在于关注点分离：应用设计人员关注点在于用DSL对象设计应用；应用实现可以通过提供不同的解释器来提供各种不同形式、不同版本、不同语言的实现，通过cicd提供不同的打包部署的策略和实现；
第三方面是，通过DSL，明确了低代码平台和资产中心的关系，DSL成为应用开发者（资产使用方）和资产贡献者的统一语言。这对资产中心的发展有重要的意义。

所有低代码平台都有描述自身应用的DSL，DSL设计体现了平台面向用户提供的所有能力（包括其本身的开放性和可扩展性）、也约束用户通过平台能完成的工作边界，同时一定程度也体现了用户使用体验。换句话可以说，DSL就是低代码平台提供给用户的应用设计语言。关于轻舟低代码DSL详细设计，以及跟其他低代码产品的相似点、差异性后续会有同学单独介绍，这里暂不做展开。

2.从程序员视角到用户视角的转变导致的对应用和服务抽象认知的变化

这个阶段我们对低代码应用抽象的理解发生了变化，二阶段时一个完整的应用至少包含两个服务（一个web服务和一个微服务）；但是现在我们允许一个完整应用只通过一个服务来实现，即一个服务就能完成前端交互、接口暴露、后端业务逻辑实现、数据存取等应用所有功能的设计和实现。每个服务可能存在四类程序对象和两类配置对象，都通过DSL进行描述。四类程序对象最终会被用于生成程序代码，两类配置对象可以被两个系统应用执行。

有人质疑那不是退回到单体应用的情况了吗？其实单体跟微服务之间并不是对立的关系，关键是你如何理解这两个概念。我的理解，所谓将单体应用进行微服务化拆分，主要进行的是领域角度的拆分，并不是前后端等技术实现的角度。换句话来说，只要限定在一个合理的领域范围，一个有着前后端完整能力的所谓的“单体应用”也可以被认为是一个微服务。

另外一点我们需要了解的是，通过低代码平台设计生产应用的用户，他们并不是在追求应用实现层面的灵活性（可以非常自由的写代码实现逻辑），他们追求的是应用设计层面的灵活性（满足需求场景的能力）。说白一点，低代码用户跟程序员的差别就是牺牲掉一些表达自由来换取生产的效率。

了解到以上两点，我们作为低代码平台的设计者，就要懂得应用抽象（其实就是DSL设计）最重要的两点：“该对用户开放的地方要开放，该对用户封闭的地方就要封闭”：

比如实体设计、逻辑编写、UI（包括接口）设计要开放，通过这些对象的设计，用户就能设计出来他们所需要的应用；
要封闭的地方，目前我考虑主要两个地方：一是应用抽象的架构（DSL）要封闭，这个封闭性是说它应该是一个稳固的开放性的架构。体现在用户设计层面，就是他要设计应用的一项功能，他很清晰的知道只有一条合理的设计路径，而不是有众多选择；二是领域模型比较成熟的领域，比如认证授权、比如业务流程，这些其实代表了被标准化的、被广泛教育和接受的领域，这些领域不需要去做过多的开放和创新，尽量让用户以他们习惯的用法直接用就行了；

“开放”和“封闭”之间，不同低代码厂商体现出很大的差异。比如软件厂商做低代码产品，他们路径是把原先只能满足特定场景的软件产品通过开放配置、开放逻辑编写等能力来覆盖更多的场景，赋予原产品“低代码”能力，所以他们更加关注“开放”；而我们从程序员提效角度出发做的低代码产品，我们需要约束“通过代码编写实现的自由表达”的欲望，要把自己想象成用户、关注在解决用户需求场景上，因此我们更加关注“封闭”。

此时，我们对低代码应用抽象和开发模式理解如下图

这个阶段，我们希望“业务专家（产品）”开始能够通过低代码平台来实践自己的应用开发的想法了。

3.集成业务流程管理（BPM）工具

企业数字化领域，业务流程管理BPM（Business Process Management）跟BI（Business Intelligence）类似，已经成为企业数字化建设的一种常用工具。它描述的是一种人与人之间（或人与应用、应用与应用、应用内各模块或服务之间）的数据流转、相互协作的一种机制。

业务流程自动化是什么？简单来说，业务流程自动化是在原有数据化的基础上，对数据和业务环节依据事先设定好的规则和权限进行处理，无需每一个环节都必须由人工介入，以系统自动流转实现智能触发计划好的业务步骤，最终实现系统全流程的自动化运行。以项目为例就是从填写项目立项申请单，到最终完成所有款项的支付以及项目结项的全流程自动化管理。-- 轻流对BPM的描述

目前开源社区已经提供了很多成熟的基于BPMN2.0实现的流程引擎，我们选择了flowable进行产品化的开发和集成。下面是轻舟低代码平台集成流程引擎后实现的流程应用的形态。