作者：京东科技 常姜洲

一、背景

近期参加公司组织的极客中餐厅训练营，我们所在的小组接到的课题是微服务的低代码平台架构设计。目标是：结合京东业务研发实际情况，针对后端研发人员，设计一个微服务低代码平台，助力更高效低交付业务需求。现已结业，将我在本次项目中沉淀设计出的设计文档整理成文，期待与大家有进一步的碰撞沟通

二、低代码平台整体技术架构设计

1、低代码开发三阶段

平台为开发者的三个阶段提供的核心功能：

1. 开发阶段：服务编排能力，提供可组合的方式绑定事件源和事件消费者（函数、API、数据源管理等基础能力）

2. 部署阶段：生成、托管、获取、构建和打包代码。

3. 运维阶段：为 Serverless 应用提供部署和服务支持。提供友好的日志系统，能够帮助平台工具使用者快速定位问题，提供对各种使用中间件状态监控，避免工具平台成为一个黑盒子

整个3阶段如下图所示：

2、低代码平台功能架构设计

角色与主功能说明：

本低代码开发平台的服务对象为开发者，旨在使用低代码开发平台，进行快速的微服务应用开发与部署，相对于传统的开发与部署方式减少研发时间，降低成本

Low Code 开发面板：

提供整个低代码应用开发生命周期的全功能的运营后台面板，可以在此面板完成开发阶段的各项配置、流程编排、脚本编写与调试、部署等功能。

Low Code 控制面板：

提供各种服务治理，告警配置管理，配置管理等服务控制功能模块

基础功能说明：

• 提供触发器、脚本函数、可视化函数的、连接器的开发与管理

• 提供多环境配置文件隔离

• 提供应用维度、函数维度监控相关配置

• 提供应用工程所有源文件、各环境配置数据的的版本管理

部署功能说明：

提供在线构建应用工程，在线调试函数、触发器、连接器等功能，调试完毕后可一键进行发布

特色功能：

为进一步提升业务域功能复用度，进一步减少重复功能开发的成本，同样提供基于模板，函数扩展点等功能的快速复用湖开发

依赖：

• 方便与JSF体系内的服务更好的融合，接入JSF注册中心API,进行JSF注册服务的信息获取

• 与统一配置平台打通进行在线配置变更的存储与变更，平台基础配置的存储与变更

• 存储层，元数据使用关系型数据库存储，流程文件、资源文件使用对象存储，源代码等文件使用git管理或者对象存储

• 监控功能依赖贡献现有的监控平台 UMP 、SGM的 的OPEN API 实现

• 日志平台，公司的日志平台暂无OPEN API 可以共建、或者私有化部署一套实现

3、低代码应用开发流程

应用生命周期4阶段

开发与测试、构建保存、发布、运行

1. 用户在编辑器中完成触发器、连接器、函数等主要低代码构件，可能复用已有模板和业务域能力进一步为开发提速

2. 开发完成后可以根据属性配置、语言环境构建打包函数镜像，同时生成版本号。

3. 发布版本，完成部署。

4. 应用实例在运行时提供服务

广义流程编排

• 可视化创建连接器

• 可视化创建触发器

• 支持可视化创建函数流程，BPMN, 流程节点可以是函数实体或者连接器实体，流程关系支持表达式编辑

• 支持脚本编写创建函数，支持多语言：Groovy,Java

• 支持多环境配置信息配置

• 支持配置通用函数、触发器、连接器等监控，健康度指标收集配置

4、低代码平台技术架构

1. 蓝色部分是我们平台重点建设的应用

2. 流量入口主要分为京东内外部两种流量入口

3. 对于HTTP接口上层可以对接成熟的网关转换为对低代码应用的JSF调用即可，此部分本身已经实现 0代码，无需重复建设

4. 对于JSF接口可以使用低代码应用的JSF接口触发器调用

5. 监控与告警主要还是以复用公司内部组件为主，基于OPEN API 封装

6. 下层主要依赖其他业务部门提供的JSF接口、各大中间件、存储层以及外部的一些HTTP接口、特殊协议的接口，消息等

5、低代码平台应用部署架构

1. 每个低代码平台的应用都有一个代理服务（LC proxy）负责和平台通信，指令下发，数据上报等

2. 低代码应用不改变现有应用的通信方式和现有的JSF接口、数据库、缓存等中间件使用原有方式通信

3. 控制中心：负责给 proxy 发控制指令，配置指令、服务治理指令等

4. 数据收集中心：负责收集低代码运行时配置的健康度指标源数据、流量等其他运行数据收集

6、低代码平台各角色系统工作机制

7、低代码平台单机应用架构

单机运行环境简介

单机应用架构

1. 低代码平台单机应用为1个JVM 进程，和监控agent 、日志 agent 等agent进程一同部署在容器、或者KVM、物理机等OS 环境中

2. 平台应用本身核心

3. low code proxy ,提供平台api接口，接受平台的指令，如：发布指令，接受到发布指令后去相关的存储服务拉取元配置信息和函数脚本、触发器、连接器配置、配置文件等低代码应用的源文件

4. 执行引擎，负责对低代码应用连接器的加载、函数加载、触发器配加载，加载完成后对外提供服务，等待各种触发器的流量触发、

5. 低代码应用核心构件

6. 触发器为应用的流量入口：如接口、MQ消费者，定时任务回调等等，平台支持自定义触发器开发

7. 函数为业务逻辑的编排，可以是特定语言的函数脚本，可以是bpmn组合的流程文件，

8. 连接器负责和下游RPC接口，存储数据源、中间件平台的消息通信

9. 多环境配置信息提供不同环境的参数配置

10. 以上几个核心构件的有机组合共同在应用层基础能力至之上提供了

11. 低代码应用作为一个运行单元被发布到平台应用中

三、低代码平台详细设计

由于是小组共创设计，我在详细设计中主要负责了连接器与触发器的设计部分，其他如函数、配置部分的设计与此详细设计这里不再赘述。大概思路如下

函数：支持各种语言的表达式函数、支持BPMN可视化流程编排

多环境配置：需要支持测试、生产、预发等环境配置文件

日志： 支持平台开发者自定义日志是否打印，打印格式，是否有掩码等

1、连接器的设计

连接器定义

1. 在一个低代码应用中连接器主要负责和其他业务方提供的RPC服务、中间件、存储等实体进行通信的组件

2. 可以在脚本函数中直接调用连接器，也可以在流程函数中直接调用连接器

3. 连接器支持其他未知新协议的制定

连接器的0代码开发与部署流程

2、自定义连接器

1、为了适应内外部不同的连接器诉求，平台提供自定义触发器的能力

2、预留使用连接器使用的配置信息，为引入的通信中间件预留未来使用该触发器的使用方需要0代码配置的配置信息，如数据库的地址，账号密码等信息

3、连接器需要实现平台提供的API,这样以便函数或者触发器可以直接调用该连接器

4、调试无误后保存触发器，提交平台审核，审核通过后平台可上架该触发器

3、自定义触发器

1、为了适应内外部不同的触发器诉求，平台提供自定义触发器的能力

2、预留使用触发器使用的配置信息，为引入的通信中间件预留未来使用该触发器的使用方需要0代码配置的配置信息，如JSF的接口地址，别名等

3、使用纯代码写出该触发器的源代码，并预留调用低代码函数的入口，以便将来使用该触发器的使用者可以0代码配置触发器所调用的函数

4、调试无误后保存触发器，提交平台审核，审核通过后平台可上架该触发器

四、低代码应用源文件

a、元信息，0代码，包含低代码应用的0代码开发部分的触发器元信息、连接器元信息

1、触发器配置信息：

▪ 通信中间件所需要的各个参数，接口名等等

▪ 调用函数的函数名称

▪ 是否打印日志，日志是否脱敏

2、连接器配置信息

▪ 通信中间件所需要的各个参数，密码，用户名等等

▪ 是否打印日志，日志是否脱敏

b、源文件，0代码，包含：流程文件、脚本文件

◦ 可视化流程编排产生的源文件，如bpmn流程文件

◦ 脚本编码产生的脚本文件，如自定义java函数

c、多环境配置，0代码，包含各个环境的配置文件

◦ 开发环境、生成环境的各个配置信息等，配置信息可以在触发器、函数、连接器中使用引入使用

d、日志组件配置

◦ 日志打印输出格式

◦ 日志输出路径

◦ 全局脱敏字段，脱敏正则

e、监控组件配置

◦ 监控埋点打印路径

◦ 监控埋点打印格式

d、低代码平台应用底座：

执行引擎、LC Proxy、中间件依赖的jar、应用框架springboot的jar等，这部分跟随不同的构建部署方式为可选项

五、低代码应用的构建部署方式

1、源文件热部署

这种方式应对于低代码平台的租户使用低代码平台所有集群的共享资源，选取一部分可用资源以后在控制面板进行选择发布，可以使用指定ip的模式应对相关权限问题，也可以不指定ip使用平台自定义分配。

▪ 受平台资源调度管控，参考上周控制面板的功能

▪ 日志与监控埋点由 LC Proxy 采集到平台提供的日志平台和监控平台

2、构建jar包、war包

这种方式应对于有自己的主机用户，拿到成品后即可部署无状态应用，打的包中不包含LC Proxy部分，执行引擎在应用启动的时候自动加载包中特定路径的流程文件、脚本文件等。

▪ 日志打印到特定目录，供用户自己的日志采集器采集

▪ 埋点文件按照特定格式打印到特定目录，供自己的日志采集器采集

3、构建镜像

这种方式应对于有自己的容器用户，拿到成品后即可部署无状态应用，打的包中不包含LC Proxy部分，执行引擎在应用启动的时候自动加载包中特定路径的流程文件、脚本文件等。

▪ 日志打印到特定目录，供用户自己的日志采集器采集

▪ 埋点文件按照特定格式打印到特定目录，供自己的日志采集器采集

4、低代码平台和部署平台的关系

◦ 内部

▪ 内部部署的低代码平台为了方便各业务方灵活使用，平台提供两种能力

▪ 1、共享资源模式：平台租户共享平台资源池，适用于消耗资源不大并发量不高的应用， 使用低代码平台本身提供的日志平台、监控平台结合做到各个维度的立体监控

▪ 2、自定义资源模式：平台对接体系内的JDOS平台，可以将低代码应用与JDOS应用进行关联，使用在JDOS平台申请的应用进行部署。这种方式提供单独的镜像文件进行部署，可结合体系内的日志中间件、监控平台， 与低代码平台本身提供的日志平台、监控平台结合做到各个维度的立体监控

◦ 外部

▪ 外部需求为成品包的时候，只需要构建出 如上所述的 jar、war供其下载即可

▪ 外部需求为低代码平台私有化部署的时候，需要将方案设计中的几大应用为用户做私有化部署

六、一些问题的思考与收获

1、扩展性不仅仅是在某一项功能上的扩展，站在全局视角看在架构设计中所有产品功能理论上都要尽可能考虑模块化，可插拔，进而搭积木成平台化，真正做到全场景和全链路可扩展

2、团队小伙伴对HTTP 触发器的设计输出，让我联想到 JSF注册中心等通用类注册中心都要解决的高可用问题，举一反三，同场景的同类解决方案的核心问题是相通的

3、对于未来业务发展生命周期没那么长，数据要求没有强隔离诉求的场景，能否基于数据模型做一层数据层的0代码开发？

4、流程驱动的低代码可以和数据驱动的低代码很好地结合起来

5、低代码平台产出物的多样化，为之后交付项目的产出物打开了思路，很多时候要站在客户角度考虑，客户的应用场景是什么，需要什么，那么我们就提供什么，张宇轩单元可跑，也可圈定某一部分功能集合，打包输出

低代码平台适合的场景的一些思考

1、可以应用在上层营销系统的开发中

2、可以用在流程较为通用的场景如：消息转化、数据统计、接口转发

3、可以应用在已有成熟的业务线进行外围的业务开发，如支付、结算等稳定系统上层要做一些简单业务编排的场景用

4、 面对同样一个业务需求是使用低代码开发还是使用纯代码开发，没有明确的可量化的分水岭，但是建议尝试，从中获到提效之后下一次面临需求的时候就会有较为明确的答案

案例1：我们曾在一个上层营销活动系统重尝试基于表达式引擎做了一个半配置化的活动配置系统（那个时候还没听过低代码这个词），现在想来算是比较原始的支持低代码系统，上新一个活动原本需要3个人日的开发量，基于对以往流程的复用，使用脚本语言，使用表达式进行编排和发布，0.5人日就搞定了，且系统无需重新发布。不得不说在合适的场景，低代码还是非常有空的。

案例2：大促的时的业务数据大屏的制作相信很多人都经历过，我们最近两次大促采取的方案都是使用星链对已有的数据接口和新的数据指标进行简单编排加工，提供JSF服务，再结合我们内部的网关系统将接口协议转化为HTTP, 直接在展示平台（如莫奈大屏）上直接使用，大促过后资源也可随之释放，非常方便与高效，同时也降低了研发成本

七、结语

参加训练营后还是有一些感触想分享给大家

1、感谢马老师的指导和各位评委老师的指点，感恩大家的信任，感谢同组的大佬们，从大家身上学习到不同的思路。每个人来此不同团队，通过和大家的讨论，发掘了很多新的看待产品与架构的视角

2、流程驱动的低代码平台可以和数据驱动的低代码以及部分0代码开发组件可以很好地有机整合成统一的低代码平台，进一步提升研发效率

3、整体感觉训练营节奏紧凑，干货满满，架构设计方面对平台扩展性的思考充分得到训练

• 还没有人评论，欢迎说说您的想法！