淘宝css模板-阿里巴巴低代码引擎及生态建设实践与思考

也想出现在这里？点击联系我~

立即下单

进入商城

进不了网站？换个网络试试！

大家好，很高兴明天有机会跟大家分享阿里巴巴近年来在低代码领域的思考和实践。

我叫李浩。 我在后端和前端岗位上工作了十多年。 过去三年我一直专注于低代码领域。 我是阿里低代码引擎项目的负责人。

我所在的部门是企业智能部。 我们部门有大量的中后端场景，所以我们6年前就开始探索低代码领域，但目前仍在持续投入。 我们花了近3年的时间主导建设了一套整个集团通用的低代码基础设施，目前集团70%的低代码平台都依赖。

分享内容主要分为3个部分：首先介绍一下在阿里业务背景复杂、用户角色复杂、技术栈不同的情况下我们如何思考低代码技术系统架构； 之后，我会介绍低代码技术体系框架的实际结构，重点介绍过程中沉淀的两个技术产品； 最后给大家分享一下阿里的几个具体的低代码场景和平台搭建。

最后，有一个小复活节彩蛋。

在我们开始之前，让我问你一个胆怯的问题：PHP 现在仍然是最好的语言吗？ 是的？ 不？ 其实不是，DnD是！ DnD 是拖放。 相信用过高码平台的朋友都会明白我的意思。

第 1 部分 - 低代码系统的架构设计注意事项

好吧，我先和大家聊聊“低代码系统的架构设计思维”。

我们先回顾一下什么叫低代码？ 看维基百科的定义，低代码开发平台为开发者提供了一种通过可视化+配置的方式来创建应用程序的方式，而不是通过手写代码。 我们再看一下 Forrester 的定义。 平台提供了快速交付业务应用的能力，不需要我们手工编写太多的代码，也不需要我们了解常规开发中的后期工作，比如了解编程语言、搭建开发环境等。 。

词儿很多，尽量提炼几个关键词，可视化、配置、低门槛、快速交付（GUI、Configuration、MinimalUpfrontInvestment 和 RapidDelivery）。 我们先不考虑这句话的意思，看几个反例。

办公室管理员小A，校长让他收集办公室100人的行程信息。 他使用表单低代码平台快速构建了行程记录表单应用。 学生填写完毕后，可以在后台通过图表实时查看数据。

业务员B，经理让他做一个小的营销方案。 他使用小程序低代码平台，拖拽完成小程序的构建，然后一键发布，完成了不可能的任务。

小C是一名开发人员，每天都在为编写标准化表单和表单页面而苦苦挣扎。 他认为这是重复性的工作，但他必须要做，直到有一天他发现使用模型驱动的低代码平台，定义数据模型后，可以手动生成页面CRUD，又快又好。

好了，相信通过这些反例，你会对低代码有一个更生动、更深入的理解。

综上所述，我们可以通过可视化界面配置并完成传统的应用开发交付流程，而无需了解太多的开发技能淘宝css模板，让办公室管理员、营销人员等非技术人员轻松完成“研发”工作，让发展 人们发展得更快。

所以我理解的低代码的核心价值就是“降本增效”和“角色赋能”。

正因为这两个核心价值观，阿里的一些部门很早就在低代码领域进行了探索并形成了一些平台。 各平台相互独立，属于典型的水塔结构。 从公司整体来看，水塔结构存在一些问题，比如一些通用能力无法复用，导致平台建设成本高、质量参差不齐。 而这样的问题，正是我们阿里巴巴后台委员会中后台团队想要解决的。

为防止低层重复建设，从而增加各业务场景低代码平台的建设成本，提高低代码系统内素材、插件、解决方案、产品等的流通，后端委员会牵头决定低代码技术系统共建，制定统一的底层合约，共同建设统一的低代码基础设施。

我们有各种技术栈，还有react/vue/applet。 我们有各种用户角色，包括产品总监、设计师、业务人员、前后端开发等。 其实我们也有各种业务场景，比如网店toC业务包括企业智能toB业务、数据业务、集成设计开发业务。

如何找到平台之间的共同点？ 以及支持平台的区别？ 这是架构成功的关键！ 经过思考，我们确定了十二字设计原则：合约至上、最小核心、最强生态。

最终我们设计了这样一套分层架构，从下到上分别是合约-引擎-生态-平台。 底层合约堆栈定义了标准。 标准的统一使得下层产品的互操作成为可能。 **引擎是合约的执行。 同时，通过能力的输出，向下支撑生态开放系统，提供各种生态扩展能力。 ** 生态系统很容易理解。 它基于引擎的核心能力进行扩展，如材质、setter、插件等，以及支持开发系统的工具链。 最后，每个平台都是基于引擎核心以及生态系统中的产品组合和连接。 满足他们需求的低代码平台。

各层定位明确，各司其职。 合约没有考虑引擎是如何实现的，引擎也没有实现具体的底层平台功能。 底层平台的多样化是通过插件来实现的。 这个概念将贯穿我们系统的设计和实现过程。

第二部分 - 求同存异：阿里的低代码引擎&UIPaaS

我们先来说一下合约栈。 目前我们有两个：一个叫《阿里巴巴中后端建设合同规范》，另一个叫《阿里巴巴中后端后端材料规范》。 这两份合约是阿里低代码领域最资深的朋友编写的，花了半年时间。 由于合约是整个系统的基石，我认为这是值得的。

内容很多，这里简单总结一下。 两份合同定义了三个方面的内容，即术语、结构和行为。

正是多个合约的存在，才使得底层之间的互通、概念、材料、生态的互通成为可能。 另外，合约也是实现多技术栈的关键，这一点我前面会进一步阐述。

低代码引擎分为4大模块，送料、排列、渲染、编码。

我们再展开说一下安排。 首先我们要有一个工作台，我们称之为编辑器骨架，它分为几个默认的可见区域，以及一些可以展开、可以显示弹窗的区域。 中心区域是用于排列和渲染的画布。

如上所述，编排的本质是不断生成符合“构建契约”的页面描述，然后通过渲染器将页面描述渲染成真实视图的过程。

合约是文本合约，json结构，理论上可以通过手写完成。 考虑到可编程性，我们设计了一套节点和属性模型，类似于DOM，这样操作节点+配置属性就相当于操作Page描述，也就是操作json结构。

除了节点模型和属性模型之外，下层还有文档&项目模型。 对于素材管理，有素材注册机制和素材模型。 此外，我们还提供通用面板管理、拖放引擎、调整大小引擎和设计器辅助层。 、就地编辑、快捷键等20多个模块，这里不再赘述。

所有这些模块的能力，即API，都是通过插件来调用的，因此插件成为了编辑器扩展的唯一载体。 您可以自定义面板、操作节点树、自定义节点扩展操作、操作材质模型、绑定快捷键、设置画布大小、自定义拖放行为等等。

我们再来说一下输出代码。 对于一些常见的场景，可以直接由渲染模块进行渲染。 并且考虑到一些特殊的情况，比如一些不支持动态化的场景，小程序，或者为了更好的性能，转码成ProCode打包部署，或者需要二次开发，因此，我们设计了一个编码框架。 编码框架提供了一套精简的处理流程，类似于babel机制。 您可以通过编码插件/预设来定制您的编码产品。 市面上的react框架、vue框架、小程序框架都可以支持。 。

再来说说引擎生态的设计。 前面说过，最小的核心、最强的生态是我们的设计原则。 因此，如何定义哪些核心能力、哪些生态以及如何支撑生态，是我们整个系统设计的重中之重。 。

通过我们支持多个平台的经验，我们发现平台之间的差异突出在这三点，材质、setter和插件。 插件是扩展的入口，材质和setter也可以通过插件注册到引擎中。 我们定义了引擎的约束，这是唯一不可变的部分，以及引擎API的能力，包括面板、画布、材质管理、拖放等，所有这些都可以通过插件来使用。 同时，我们将插件设计得具有高内聚性、显式配置、可流通性。 这就支持了插件生态的出现，甚至在更高的层面上，定制设计器也可以通过可视化配置来实现。

还有一件事，因为生态系统如此重要，所以我们在生态元素的调试能力上也下了很大的功夫。 目前我们采用工具链+调试插件的方式实现所有生态元素的调试，相互结合调试，在线调试。

我们抽象的看一下引擎生态，就是一个标准的中后端设计器页面。 红色部分是插件，那些是可以看到的插件。 既然调用了面板API，还有一些看不到的，比如快捷键API、拖拽API、事件API等。绿色部分是setter，可以自定义我们如何给一个节点赋予属性范围。 红色部分是材质。 虽然材质本质上是一个模型，不可见，但是通过材质面板调用材质API来显式地显示材质，然后通过拖放API和节点API进行拖放和插入。 进入画布。

丰富的生态使得快速、低成本构建低代码平台成为可能。 我们有物质生态、setter生态、插件生态。 为此，我们推导出一个简单的公式。 构建一个低代码设计器相当于引擎+材质选择+setter选择+插件选择。

我们来谈谈我们如何通过合约来支持多种技术栈。 无论是《阿里巴巴中后台后台施工合同规范》还是《阿里巴巴中后台后台物料规范》，都与语言无关。 你定义一组材质描述，具体实现可以是react/vue或者任何技术栈。 对于构建页面淘宝css模板，可以在设计状态下使用React组件，也可以在渲染时使用React组件。 不过要注意的是，由于设计和渲染的差异，中间的产品页面描述也是语言无关的，所以渲染的时候可以是任何语言，可以是react，可以是vue，也可以是一个小的程序。

其实混搭的场景并不是我猜的那样。 阿里对于mashup的实践有很多。

下面说一下布局和渲染的单层架构设计。 通过这个架构，我们实现了绝对纯粹的编辑状态渲染，即模拟器实现。

相信大家对这张图都很熟悉。 编辑器中嵌入了所见即所得的渲染模块，但是会存在一个问题，CSS污染的问题，因为编辑器中的每个模块、材质、setter和插件都来自不同的来源。 团队，很容易形成css污染。 编辑器中元素之间相互污染的问题不算太大，污染渲染视图就很严重了。 你可以想想为什么？

我们的解决方案是，将模拟器加载到一个新的iframe中并运行，通过编辑器将相关资源注入到模拟器中，构建数据通道，并使用facade模式，即编辑器和模拟器中都有一个facade对象。 负责对外暴露和调用，避免深度耦合。

低代码引擎采用合约优先、最小核心、最强生态的理念，形成四大模块和生态可扩展性的整体设计，足够灵活地支持各类低代码平台。

不过，此时您可能会有一些疑问。 这种引擎+生态的组合其实还处于底层，距离真正的生产可用的低代码平台还很远。 例如：

创建的页面描述保存在哪里？ 建设完成后，哪种产品包装系统更好？ 如何解决页面多人编辑冲突？ 开发流程是如何定义的？ 版本管理，多分支怎么办？ 如何构建页面块/低代码组件？ 如何使用？

这里有数百个问题，因为这些都是我们遇到并解决的问题。

因此，我们在引擎之上添加一个层来生成低代码平台或孵化器的基础。 我们把这个低代码平台的孵化器称为UIPaaS。 在阿里巴巴内部，我们开始构建更多基于UIPaaS的低代码平台，这使得它变得更容易。

为什么要做UIPaaS？ 两个原因：

解决产品能力问题，实现应用管理、研发流程、打包流程、发布流程等一系列能力，快速找到满足需求的生态元素组合

让我们看看它包含哪些功能以及支持哪些种类：

第三篇——保留差异：百花齐放的低代码平台

最后，我们来看看正在蓬勃发展的低代码平台。 我们有各种各样的业务场景、各种各样的用户角色、各种各样的技术栈，所以形成各种各样的低代码平台几乎是必然的结果。 唯一的问题是如何低成本、快速地支持各种平台的开发。 在阿里，我们通过UIPaaS孵化器来支持。

总结目前我们搭建的垂直平台，包括大家熟悉的中后端、运营场景、数据报表场景，还有以设计类为代表的角色协作、产品互通平台，还有联通应用、物联网、云计算等。 aPaaS。 等类型。

平台有很多，由于种种原因我们无法一一展示。 下面我们看一下几个典型的平台：

这是一个中后端平台，功能包括页面大纲树、组件面板、源码面板、国际化、模型编排等核心能力，以及封装系统、研发管理等模块。

这是一个数据报表平台，将对图表库、数据模块、账户权限体系、setter等进行深度定制。

这是一个小程序编排平台。 核心是接入一组小程序组件，定制一些小程序特有的配置，并连接各种发布渠道。

虽然提到了很多低代码平台，但使用低代码开发已经成为一种热潮。 我建议不要盲目跟风。 低代码开发只是一种开发范式。 与往年任何发展范式相比，不高也不低。 合适的才是最好的。 评价标准只有两个：能否开发提高效率？ 能否赋予该角色权力？

彩蛋-合约对外开放&低代码引擎开源

最后，这是我最喜欢看到的复活节彩蛋~

下面我给大家介绍一下阿里巴巴低代码引擎的发展历程。 请注意，我将合同起草的节点标记为黄色，因为这个节点代表了整个集团从联军作战向集团军作战转变的关键里程碑。 未来的合约发布、群组引擎、UIPaaS等节点都会水到渠成~

低代码合约和低代码引擎在阿里内部经过近三年的揉捏和磨练，在生态建设和平台支持方面取得了不错的成果。未来我们会将其开源，让大家分享这个低代码——代码基础设施，不断接受社会的揉捏和锤炼

谢谢~