作者：京东科技 常姜洲
一、背景
近期加入公司组织的极客中餐厅训练营，咱们所在的小组接到的课题是微服务的低代码平台架构设计。指标是：联合京东业务研发理论状况，针对后端研发人员，设计一个微服务低代码平台，助力更高效低交付业务需要。现已结业，将我在本次我的项目中积淀设计出的设计文档整顿成文，期待与大家有进一步的碰撞沟通
二、低代码平台整体技术架构设计
1、低代码开发三阶段
平台为开发者的三个阶段提供的外围性能：
- 开发阶段 ：服务编排能力，提供可组合的形式绑定事件源和事件消费者（函数、API、数据源治理等根底能力）
- 部署阶段 ：生成、托管、获取、构建和打包代码。
- 运维阶段： 为 Serverless 利用提供部署和服务反对。提供敌对的日志零碎，可能帮忙平台工具使用者疾速定位问题，提供对各种应用中间件状态监控，防止工具平台成为一个黑盒子
整个 3 阶段如下图所示：
2、低代码平台性能架构设计
角色与主性能阐明：
本低代码开发平台的服务对象为开发者，旨在应用低代码开发平台，进行疾速的微服务利用开发与部署，绝对于传统的开发与部署形式缩小研发工夫，降低成本
Low Code 开发面板：
提供整个低代码利用开发生命周期的全功能的经营后盾面板，能够在此面板实现开发阶段的各项配置、流程编排、脚本编写与调试、部署等性能。
Low Code 控制面板：
提供各种服务治理，告警配置管理，配置管理等服务管制功能模块
根底性能阐明：
• 提供触发器、脚本函数、可视化函数的、连接器的开发与治理
• 提供多环境配置文件隔离
• 提供利用维度、函数维度监控相干配置
• 提供利用工程所有源文件、各环境配置数据的的版本治理
部署性能阐明：
提供在线构建利用工程，在线调试函数、触发器、连接器等性能，调试结束后可一键进行公布
特色性能：
为进一步晋升业务域性能复用度，进一步缩小反复性能开发的老本，同样提供基于模板，函数扩大点等性能的疾速复用湖开发
依赖：
• 不便与 JSF 体系内的服务更好的交融，接入 JSF 注册核心 API, 进行 JSF 注册服务的信息获取
• 与对立配置平台买通进行在线配置变更的存储与变更，平台根底配置的存储与变更
• 存储层，元数据应用关系型数据库存储，流程文件、资源文件应用对象存储，源代码等文件应用 git 治理或者对象存储
• 监控性能依赖奉献现有的监控平台 UMP、SGM 的 的 OPEN API 实现
• 日志平台，公司的日志平台暂无 OPEN API 能够共建、或者私有化部署一套实现
3、低代码利用开发流程
利用生命周期 4 阶段
开发与测试、构建保留、公布、运行
- 用户在编辑器中实现触发器、连接器、函数等次要低代码构件，可能复用已有模板和业务域能力进一步为开发提速
- 开发实现后能够依据属性配置、语言环境构建打包函数镜像，同时生成版本号。
- 公布版本，实现部署。
- 利用实例在运行时提供服务
狭义流程编排
• 可视化创立连接器
• 可视化创立触发器
• 反对可视化创立函数流程，BPMN, 流程节点能够是函数实体或者连接器实体，流程关系反对表达式编辑
• 反对脚本编写创立函数，反对多语言：Groovy,Java
• 反对多环境配置信息配置
• 反对配置通用函数、触发器、连接器等监控，衰弱度指标收集配置
4、低代码平台技术架构
- 蓝色局部是咱们平台重点建设的利用
- 流量入口次要分为京东内外部两种流量入口
- 对于 HTTP 接口下层能够对接成熟的网关转换为对低代码利用的 JSF 调用即可，此局部自身曾经实现 0 代码，无需反复建设
- 对于 JSF 接口能够应用低代码利用的 JSF 接口触发器调用
- 监控与告警次要还是以复用公司外部组件为主，基于 OPEN API 封装
- 上层次要依赖其余业务部门提供的 JSF 接口、各大中间件、存储层以及内部的一些 HTTP 接口、非凡协定的接口，音讯等
5、低代码平台利用部署架构
- 每个低代码平台的利用都有一个代理服务（LC proxy）负责和平台通信，指令下发，数据上报等
- 低代码利用不扭转现有利用的通信形式和现有的 JSF 接口、数据库、缓存等中间件应用原有形式通信
- 控制中心：负责给 proxy 发控制指令，配置指令、服务治理指令等
- 数据收集核心：负责收集低代码运行时配置的衰弱度指标源数据、流量等其余运行数据收集
6、低代码平台各角色零碎工作机制
7、低代码平台单机利用架构
单机运行环境简介
单机利用架构
- 低代码平台单机利用为 1 个 JVM 过程，和监控 agent、日志 agent 等 agent 过程一起部署在容器、或者 KVM、物理机等 OS 环境中
- 平台利用自身外围
- low code proxy , 提供平台 api 接口，承受平台的指令，如：公布指令，承受到公布指令后去相干的存储服务拉取元配置信息和函数脚本、触发器、连接器配置、配置文件等低代码利用的源文件
- 执行引擎，负责对低代码利用连接器的加载、函数加载、触发器配加载，加载实现后对外提供服务，期待各种触发器的流量触发、
- 低代码利用外围构件
- 触发器为利用的流量入口：如接口、MQ 消费者，定时工作回调等等，平台反对自定义触发器开发
- 函数为业务逻辑的编排，能够是特定语言的函数脚本，能够是 bpmn 组合的流程文件，
- 连接器负责和上游 RPC 接口，存储数据源、中间件平台的音讯通信
- 多环境配置信息提供不同环境的参数配置
- 以上几个外围构件的有机组合独特在应用层根底能力至之上提供了
- 低代码利用作为一个运行单元被公布到平台利用中
三、低代码平台具体设计
因为是小组共创设计，我在具体设计中次要负责了连接器与触发器的设计局部，其余如函数、配置局部的设计与此具体设计这里不再赘述。大略思路如下
函数：反对各种语言的表达式函数、反对 BPMN 可视化流程编排
多环境配置：须要反对测试、生产、预发等环境配置文件
日志：反对平台开发者自定义日志是否打印，打印格局，是否有掩码等
1、连接器的设计
连接器定义
- 在一个低代码利用中连接器次要负责和其余业务方提供的 RPC 服务、中间件、存储等实体进行通信的组件
- 能够在脚本函数中间接调用连接器，也能够在流程函数中间接调用连接器
- 连接器反对其余未知新协定的制订
连接器的 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、整体感觉训练营节奏紧凑，干货满满，架构设计方面对平台扩展性的思考充沛失去训练