本文已经过 lowcode-engine 团队 review 并同步到官方社区:www.yuque.com/docs/share/…
1. 写在前面
随着移动互联网的红利消退,各个领域的巨头们都开启了存量竞争时代,针对领域的精细化运营变得越来越重要。传统的开发模式越来越成为业务快速试错的掣肘。低代码/无代码很好的解决了开发资源不足导致的工程迭代缓慢等问题。而自研一款优秀的低代码基础设施门槛较高(比如:协议、拖拽编辑、与现有物料结合等)导致 lowcode 发展缓慢。
终于!!! lowcode-engine 提供了一整套的解决方案与基础设施,屏蔽了底层的大量细节并通过规范标准化协议促进生态互通,为 lowcode 注入了新的活力。相信未来可以变成低代码世界的“水电煤”。本文从宏观(架构)与微观(代码)角度分析了低代码引擎的执行过程。
2. 知识点储备
2.1 内核架构
- 微内核:是计算机科学中的一种内核设计架构,内核只保留最核心的能力(比如寻址空间、线程管理、IPC等)。其他能力交给各类插件以 Service(或Plugin) 的形式供内核调度。微内核最大的好处是可扩展性强、设计简单、单一服务出现 bug 不会影响全局。在一些需要强大生态能力的软件中微内核得到了广泛的应用,比如: VSCode、Chrome、Intelij IDE以及华为的鸿蒙操作系统
- 宏内核:与微内核对应的是“宏内核”,宏内核把寻址等能力集成到内核中,这些能力可以互相直接调用节省了进程通信时间,但这也同样带来了系统耦合严重,稳定性降低等问题
- 混合内核:综合“宏内核”、“微内核”两种架构的优缺点,将部分能力集成到内核中,提高了系统性能的前提下保留了扩展性
lowcode-engine借鉴了微内核的设计思路:将核心架构设计的尽可能简单,其他能力通过 Plugin 的形式进行扩展。
2.2 代码管理策略
- MONOLITH:单体系统。最原始的项目管理方式,整个系统的作为一个 project 放在同一个仓库中
- 优势:简单,在较为简单的应用场景下具备不可替代的优势
- 劣势:随着时间推移及系统复杂度的提升,单体系统的迭代会由于各子模块互相深度耦合而变得可维护性大幅下降
- MULTI-REPO(multiple repository):多体式仓库。系统中的各个子模块分别作为一个 project 存放在不同的仓库中,比如:Rollup
- 优势:关注点分离,各个子 project 团队可以独立的进行软件交付
- 劣势:如果各个 project 之间存在依赖,调试起来相当麻烦。并且由于代码不在同一个仓库中,版本的发布 changelog 也会被丢失
- MONO-REPO(monolithic repository):单体式仓库。系统中的各个子 project 存放在同一个仓库的不同目录下,每个 project 独立发布,比如:React, Angular, Babel, Jest, Umijs, Vue ...
- 优势:既保留了 mutiple-repo 的关注点分离等松耦合架构,也保留了 monolith 系统中的 changelog
lowcode-engine 使用了基于 MONO-REPO 的 learn 进行代码管理。关于 learn 可以参考 vivo 技术团队的 《基于 Lerna 管理 packages 的 Monorepo 项目最佳实践》
2.3 一些协议
所谓“三流企业做产品、二流企业做品牌、一流企业定标准”。lowcode-engine 团队也在低代码领域设计了一套协议标准,基于这套标准各个不同的低代码平台产品理论上可以实现互通。简单理解下几个核心的协议规范:
- 《低代码引擎搭建协议规范》:给渲染引擎用的。搭建(编排)的本质是通过用户的拖动产出这份协议
- 《低代码引擎物料协议规范》:给低代码引擎用的。程序员通过看组件源码获取组件支持的属性,低代码引擎通过看《物料协议规范》获取组件支持的属性
- 《低代码引擎资产包协议规范》:给低代码引擎用的。《低代码引擎物料协议规范》的集合形式,通常会把多个组件打包成资产包的形式给低代码引擎用
3. 架构分析
3.1 整体架构
一句话解释:
- 入料:为现有的组件增加描述后交个低代码引擎
- 编排:把用户的拖拽、新增、删除等行为转化成对《低代码引擎搭建协议规范》的操作
- 出码:把【编排】产生的协议转化成代码,针对特殊场景程序员可以二次开发
- 渲染:把【编排】产生的协议渲染出来
3.2 子模块分析
3.2.1 入料模块
内部使用了 react-docgen 为现有组件生成 《低代码引擎物料协议》供入料到低代码引擎
3.2.2 编排模块(系统的灵魂!)
通过一个使用示例(从组件库拖拽到编辑区),看一下代码的执行过程:
核心代码执行流程:
3.2.3 渲染模块
我们通过官方提供的 lowcode-demo 项目一起看一下渲染原理(注:官方 demo 项目使用的是 React 渲染器):
3.2.4 出码模块
本质上出码模块是一个 CLI,负责将低代码引擎生成的 Schema 转化成可执行的 jsx 代码供开发者二次开发。核心执行路径及源码位置如下:
注:本包下有个
package.json -> demo
的 script,可以通过 VSCode 直接 debug 看逻辑
3.3 设计亮点
3.3.1 项目模型
低代码引擎团队基于编排领域的特点设计了一些领域模型,拖拽的本质是对这些模型的 CRUD。基于这些模型,进可生成 schema 退可做渲染。 详见文档:www.yuque.com/lce/doc/dcr…
3.3.2 多模式渲染
作为一个低代码引擎,有两处涉及到渲染的地方:编辑预览态、生成页面后的渲染。这两种渲染大体相似但又不完全相同,编辑态的预览涉及到跟设计器的交互。低代码引擎为渲染器增加了一层 Simulator 作为衔接层,最大程度节省开发资源的同时保证了预览态与真实渲染的统一
3.3.3 事件机制
作为微内核的实践者,低代码引擎大量插件间的通信同样遵循微内核的最佳实践——事件。内核封装了 EventEmitter 用作事件的发布与订阅。详见文档:www.yuque.com/lce/doc/qro…
4. 参考文献:
- lowcode-engine 官网:www.yuque.com/lce/doc/int…
- lowcode-engine 源码库:
- 引擎库: github.com/alibaba/low…
- 插件库:github.com/alibaba/low…
- 阿里低代码引擎官方提供的setter和setter必须依赖的插件集合:github.com/alibaba/low…
- 《Monorepo vs Multi-Repo: Pros and Cons of Code Repository Strategies》kinsta.com/blog/monore…
- 《基于 Lerna 管理 packages 的 Monorepo 项目最佳实践》:juejin.cn/post/684490…
欢迎大家微信扫下面二维码,关注我的公众号【趣code】,一起成长~