vivo 低代码平台【后羿】的探索与实践

青春才几年，疫情占三年，后疫情时代，究竟需要什么样的新技术，才能真正解放IT生产力，我认为是低代码，一种可视化的应用开发方法，即“用较少的代码、以较快的速度来交付应用程序”。

一种方式是产品视角，或者说是非开发的视角，当我们在低代码平台搭建、开发业务时，无需关心整个制品的具体分层和实现细节，只需要使用平台提供的能力来搭建我们所需的端侧应用即可，这种方式下用户甚至无需具备专业的开发知识便可搭建出简单的应用，这种平台往往也是无代码平台。

另一种则是开发视角，这种思维模式下，用户至少会看到前端和后端两种服务，这两种服务通常来说可能是页面和接口，这种模式更加适合程序员，与日常开发思维保持一致，所以平台学习成本也就很低，能够简单、快速的开发出更加复杂的应用；后羿主要面向开发者，自然而然的采用了这种分层开发的模式。

低代码平台本身也需要开发者投入大量的开发精力，一个好的开发模式往往能够事半功倍，目前流行的低代码产品，大多是下图所示两大类实现方式。

前后端分离的方案，分层明确，解除耦合，而且前后端各自的服务也实现了逻辑分层，得益于这种架构，我们很轻松就实现了前后端低代码能力的分离，来满足更加复杂的业务诉求。

前文我们提到，前后端分离中还包括了前后端低代码服务能力的分离。

如上图所示，开发者平台产出的DSL，传递到端侧，经过各自的运行时解析，便可以针对不同用户提供不同的低代码能力；这样，用户就可以使用平台搭建页面来连接自己的服务，或者编排接口来为自己的页面提供存储服务；既可以单独配置页面，也可以独立使用接口服务，这就是前后端低代码能力的分离，前后端分别配置，也与传统开发逻辑、思维方式一致，对开发者十分友好。

除此之外，前后端分离的方案，也带来了其他的一些利好：前端侧通过引入BFF层可轻松实现动态接口代理、鉴权、日志；服务端也可以做接口的微服务化；通过功能拆分、组件懒加载等方式可以提升性能；也能够更好的与传统开发兼容，各施所长；前后端独立部署更加灵活、高效；也更易被第三方应用集成。

先来看看表单渲染器，

众所周知，表单场景一直都是前端中后台领域最复杂的场景，通过自研的表单渲染引擎我们提供了表单数据管理、表单状态管理、动态渲染、组件联动等功能；基于JSONSchema驱动的分层架构，实现了逻辑与UI框架解耦；通常，用户只需要稍微了解几个胶水层的API便可以快速上手；复杂的场景下，用户还可以通过拓展组件属性或开发自定义组件的方式来满足需求；另外，我们还将表单实例挂载到了动态交互的上下文，这样我们就可以很轻松的实现各块级组件联动和数据交互。

特别说明的是，自研完全是为了更加贴合业务需要，开源社区有很多优秀的动态解决方案，如formily2、x-render、formast，他们都有各自的优缺点，我们也是权衡了利弊之后选择的自研，当然我们也借鉴了x-render的api设计与formast的动态语法表达式，我们追求的是简单、好用、高性能及完全可控。

再来看看列表渲染器，

列表是前端中后台领域又一个非常重要的场景，为了满足各种各样的列表需求，我们二次开发了vxe-table这个功能丰富的开源列表库，各种工具，复杂表格、树形表格、编辑表格、虚拟滚动（ps：自定义渲染器的场景大数据的性能表现不佳）都是天然支持，我们额外内置了图片、视频等15种常用的渲染场景；与表单渲染器相同，列表渲染器依然是基于json-schema驱动的分层架构，学习成本极低，拓展简单，也支持用户自定义渲染器；同样，我们也将列表实例挂载到了动态交互的上下文，实现与其他块级组件的联动和数据交互。 

说到列表，我们提一下图表，图表你也可以理解为列表的另一种展现形式，有了列表的开发经验，图表实现起来也十分轻松，只需要设计合理的DSL编译后下发给第三方库即可（如Echart），主要的思路还是和表单进行联动，由表单来驱动查询条件，执行异步查询，得到的数据经过格式化后绑定到图表即可。

有了表单和列表，已经能够搭出简单页面了，但是弹窗、按钮交互、接口请求如何实现呢？动态交互是前端低代码最复杂也是最有趣的部分，下面就来揭开它的神秘面纱。

同样，动态交互解释器也是基于JSONSchema驱动的分层架构，解释器仅仅是一层胶水和内置的交互流程节点；执行器主要的功能就是贮藏动态节点、传递动态上下文、解释执行动态交互、流转或终止流程。

前文我们多次提到了“将实例挂载到动态交互上下文”，正如伪代码中的ctx，这是一个响应式的上下文，我们会根据不同的业务场景有选择性的挂载表单、列表、图表的实例及相关方法和诸如路由信息、全局状态、应用信息等其他用户可能会需要的重要数据，以便各流程节点可以实时的访问实例和动态修改对应的实例，这样就实现了各区块间的联动交互。

动态交互解释器也支持自定义，在极其复杂的场景下我们可以通过添加自定义流程节点的方式来拓展功能，满足需求。

不同于其他低代码平台，在后羿中，我们将页面视为资源，按照资源级别来管理、发布我们的配置，这样做的好处有两个：

• 第一、 我们可以根据资源的层级关系设计不同的导航风格，可以是tab-history模式，也可以是面包屑模式，以及你能想到的任何菜单管理模式。

• 第二、 资源的管理与页面的可视化配置解耦，管理更加高效；如上图所示，除了可以随时拖拽调整菜单结构，还可以一目了然的看到资源的详细信息；得益于这种设计，我们提供了针对资源级别的版本发布功能，可以实现一键迭代及线上热更新；基于V消息的工单版本管理，安全高效可追溯，还能够实现秒级回退。

我们提供了页面结构大纲视图，只需点击icon，便可以快速定位到组件，解决了复杂页面查找组件的痛苦；

开发或迭代时，对页面的改动无法追溯也是一个痛点，于是我们内置了版本比对，只需拖拽任意两个版本到比对框，就可以实现两者的精确比对，方便排查问题；每个版本也提供了版本快速回退，点击即可一键回退。

多层嵌套配置，是可视化中相当痛苦的场景，于是我们提供了扁平化配置方案，比起层层堆叠的弹窗配置，配置更加方便，切换成本更低。

另外我们对新手用户也十分友好，除了引导式配置，我们还提供了字段级功能说明及文档指引，以降低配置门槛。

对于五花八门的运营数据我们会无差别的存放在MongoDB中；通过自定义的分仓策略来保证业务隔离和可扩展；当然也会涉及到数据的多级关联，自定义检索等，多种手段的加持下才达到最后的精确分发。

后羿平台承载了海量的业务数据，面对巨大的用户流量，我们必须保证投放的高可用。

如图所示，我们在架构上采用独立镜像服务来承载各个大流量业务，各独立服务又有本地缓存、磁盘缓存和独立Redis集群来保证单体服务的高可用。

除了高可用，还要能够支持高并发，目前我们的QPS在百万级别，每次请求可能会关联查询上百个表单，最终就会放大到千、万亿级别的表单查询量。

我们通过异步加并发的方式提升服务的吞吐量，结合异步监听、动态更新、定时重新加载等方式来提升系统的性能；多种手段的加持最终保证了服务的高并发。

对于个性化的业务诉求，我们还支持在后羿提供的SDK 上二次拓展，这部分与传统的开发几乎没有区别。

说到传统开发，那我们就来聊聊这个老生常谈的话题：

• 低代码如何与传统开发共存？

• 低代码会取代程序员吗？

• 低代码会不会干掉传统开发？

• 首先我们要明确的是，两者并不冲突！

低代码也不是银弹，而传统开发有着天然的定制化优势，灵活且没有限制，配套的技术也相当成熟；所以我们认为两者共存，优势互补才能发挥更大的价值。

那后羿是如何实践的呢？

一方面我们不断的丰富场景模型，提高拓展能力和配置效率；另一方面则从底层架构设计上兼容了传统的定制化开发；我们双向支持iframe及微应用，双向意味着后羿产出的页面可以嵌入到第三方应用中，也接受第三方应用嵌入到后羿中；并且支持页面级、区块级和组件级的嵌入。

传统开发场景，为了让大家专注于业务逻辑，我们打通了树懒的资源快速部署能力，并且提供了多种类型的工程脚手架，支持脚本命令一键发布迭代；另外还支持素材托管，拥有独立的业务空间，安全又便捷。

以上就是后羿的低代码实践经验，这么短的篇幅不足以揭开后羿的全貌，对于低代码来说也只是杯水车薪，我们利用现有的资源、服务、基建（基建真的很重要）以最小的成本孵化出来了后羿低代码平台，其实能做的还很多，我们也会持续探索，让每个人都能享受到低代码的乐趣。