作者：vivo 互联网前端团队 - Wang Ning
本文依据王宁老师在“2022 vivo 开发者大会 ” 现场演讲内容整顿而成。公众号回复【2022 VDC】获取互联网技术分会场议题相干材料。
本文次要从前后端拆散的低代码计划、自研高性能渲染引擎、高效的可视化配置计划、千亿级内容投放、低代码如何与传统开发共存等五个维度 vivo 在低代码平台方面的实践经验，其中也会波及到动静交互如何使用低代码来编排和咱们在进步配置效率方面的全面摸索。
一、前言
青春才几年，疫情占三年，后疫情时代，到底须要什么样的新技术，能力真正解放 IT 生产力，我认为是低代码，一种可视化的利用开发方法，即“用较少的代码、以较快的速度来交付应用程序”。
低代码如果从表现形式来说的确不是新技术，1980 年就有了，但随着前端各种新技术的呈现及云原生时代的到来，低代码让咱们看到了积极向上的一面；对用户来说：图形化操作，容易上手；内置各种模板、组件，升高开发难度；可视化拖拽，开发效率高。对企业来说：可能缩短产品周期；节省成本，提高效率；而且保护便当，即改即用。低代码的劣势这么的不言而喻，天然也会在 vivo 施展它的价值。
随着 vivo 互联网用户量级一直减少，传统开发曾经不可能满足井喷式的经营需要，而后羿，正是咱们摸索解决方案过程中诞生的用于撑持经营后盾业务高效高质量落地的低代码平台，目前已是 vivo 后盾业务首选的在线可视化开发平台，咱们在平台建设的过程中也积淀了大量的教训，前面的内容将会以后羿为背景来具体开展。
接下来咱们将从以下五个方面别离开展咱们在低代码方面的实际：
- 前后端拆散的低代码计划
- 自研高性能渲染引擎
- 高效的可视化配置计划
- 千亿级内容投放
- 低代码如何与传统开发共存
二、前后端拆散的低代码计划
低代码平台经常前端局部要占据重头戏，所以在晚期，咱们采纳的是前端大包大揽的技术计划，但随着业务量的剧增，咱们遇到了各种各样的诉求，比方后羿侧是否能够输入独立页面，或者反对纯正的服务端低代码能力、产出独立的接口服务等。为了解决问题及时响应业务诉求，咱们大刀阔斧的进行了重构，在后续的版本，咱们采纳了前后端拆散的低代码计划，当然，这种拆散包含了“前后端开发拆散 ” 和“低代码服务能力拆散”，如下图，咱们可能直观的看到 web 开发两种最根本的形式。
前后端拆散较不拆散的形式，分工更加明确，真正实现解耦；前端能够专一于页面交互、用户体验和兼容性，而后端则次要负责高并发、高可用、高性能、平安、存储和业务逻辑，前后端拆散的开发方式也是时下行业的支流抉择。咱们再来看一下低代码形式开发利用的不同之处。
一种形式是产品视角，或者说是非开发的视角，当咱们在低代码平台搭建、开发业务时，无需关怀整个制品的具体分层和实现细节，只须要应用平台提供的能力来搭建咱们所需的端侧利用即可，这种形式下用户甚至无需具备业余的开发常识便可搭建出简略的利用，这种平台往往也是无代码平台。
另一种则是开发视角，这种思维模式下，用户至多会看到前端和后端两种服务，这两种服务通常来说可能是页面和接口，这种模式更加适宜程序员，与日常开发思维保持一致，所以平台学习老本也就很低，可能简略、疾速的开发出更加简单的利用；后羿次要面向开发者，自然而然的采纳了这种分层开发的模式。
低代码平台自身也须要开发者投入大量的开发精力，一个好的开发模式往往可能事倍功半，目前风行的低代码产品，大多是下图所示两大类实现形式。
前后端不拆散实现会导致平台的灵活性差、拓展性差、可集成度较低；反观前后端拆散实现的形式，咱们能够设计简略易懂的 DSL，下发到开发侧编译转换，施展各自的劣势；前后端版本迭代和优化降级也能够做到互不烦扰。
正如上图，得益于前后端拆散的分层架构，咱们在前端服务层又拆散出开发者平台和经营平台；开发者平台专一于可视化搭建，经营平台面向最终的业务经营；一个负责开发体验，一个负责用户体验；后端则通过微服务架构拆分出不同功能模块，实现了平台逻辑与业务逻辑的解耦。
前后端拆散的计划，分层明确，解除耦合，而且前后端各自的服务也实现了逻辑分层，得益于这种架构，咱们很轻松就实现了前后端低代码能力的拆散，来满足更加简单的业务诉求。
前文咱们提到，前后端拆散中还包含了前后端低代码服务能力的拆散。
如上图所示，开发者平台产出的 DSL，传递到端侧，通过各自的运行时解析，便能够针对不同用户提供不同的低代码能力；这样，用户就能够应用平台搭建页面来连贯本人的服务，或者编排接口来为本人的页面提供存储服务；既能够独自配置页面，也能够独立应用接口服务，这就是前后端低代码能力的拆散，前后端别离配置，也与传统开发逻辑、思维形式统一，对开发者非常敌对。
除此之外，前后端拆散的计划，也带来了其余的一些利好：前端侧通过引入 BFF 层可轻松实现动静接口代理、鉴权、日志；服务端也能够做接口的微服务化；通过性能拆分、组件懒加载等形式能够晋升性能；也可能更好的与传统开发兼容，各施所长；前后端独立部署更加灵便、高效；也更易被第三方利用集成。
三、自研高性能渲染引擎
渲染引擎是由动静表单渲染器、列表渲染器和动静交互解释器三局部组成的，他们可能各司其职也能够相互配合，渲染引擎的次要作用就是将可视化操作生成的 DSL 翻译成具备性能逻辑和交互的页面、模板或组件。
先来看看表单渲染器，
家喻户晓，表单场景始终都是前端中后盾畛域最简单的场景，通过自研的表单渲染引擎咱们提供了表单数据管理、表单状态治理、动静渲染、组件联动等性能；基于 JSONSchema 驱动的分层架构，实现了逻辑与 UI 框架解耦；通常，用户只须要略微理解几个胶水层的 API 便能够疾速上手；简单的场景下，用户还能够通过拓展组件属性或开发自定义组件的形式来满足需要；另外，咱们还将表单实例挂载到了动静交互的上下文，这样咱们就能够很轻松的实现各块级组件联动和数据交互。
特地阐明的是，自研齐全是为了更加贴合业务须要，开源社区有很多优良的动静解决方案，如 formily2、x-render、formast，他们都有各自的优缺点，咱们也是衡量了利弊之后抉择的自研，当然咱们也借鉴了 x -render 的 api 设计与 formast 的动静语法表达式，咱们谋求的是简略、好用、高性能及齐全可控。
再来看看列表渲染器，
列表是前端中后盾畛域又一个十分重要的场景，为了满足各种各样的列表需要，咱们二次开发了 vxe-table 这个功能丰富的开源列表库，各种工具，简单表格、树形表格、编辑表格、虚构滚动（ps：自定义渲染器的场景大数据的性能体现不佳）都是人造反对，咱们额定内置了图片、视频等 15 种罕用的渲染场景；与表单渲染器雷同，列表渲染器仍然是基于 json-schema 驱动的分层架构，学习老本极低，拓展简略，也反对用户自定义渲染器；同样，咱们也将列表实例挂载到了动静交互的上下文，实现与其余块级组件的联动和数据交互。
说到列表，咱们提一下图表，图表你也能够了解为列表的另一种展示模式，有了列表的开发教训，图表实现起来也非常轻松，只须要设计正当的 DSL 编译后下发给第三方库即可（如 Echart），次要的思路还是和表单进行联动，由表单来驱动查问条件，执行异步查问，失去的数据通过格式化后绑定到图表即可。
有了表单和列表，曾经可能搭出简略页面了，然而弹窗、按钮交互、接口申请如何实现呢？动静交互是前端低代码最简单也是最乏味的局部，上面就来揭开它的神秘面纱。
如上图所示，由用户点击按钮发动，弹出表单弹窗，填写表单，发动接口申请，依据响应后果提醒和列表刷新，其中有的是用户交互，有的则是程序在驱动；咱们通过对这样的动静交互流程建模，能够形象出流程源和一个个流程节点；当用户触发交互，一个个交互节点组成了动静交互队列，有序执行，尽管理论状况可能会更简单，有异步、有分支，但咱们也仅仅通过不到 30 行的代码便实现了整个动静交互的驱动，咱们把这个外围解决方案称之为动静交互解释器，如下图所示伪代码。
同样，动静交互解释器也是基于 JSONSchema 驱动的分层架构，解释器仅仅是一层胶水和内置的交互流程节点；执行器次要的性能就是储藏动静节点、传递动静上下文、解释执行动静交互、流转或终止流程。
前文咱们屡次提到了“将实例挂载到动静交互上下文”，正如伪代码中的 ctx，这是一个响应式的上下文，咱们会依据不同的业务场景有选择性的挂载表单、列表、图表的实例及相干办法和诸如路由信息、全局状态、利用信息等其余用户可能会须要的重要数据，以便各流程节点能够实时的拜访实例和动静批改对应的实例，这样就实现了各区块间的联动交互。
动静交互解释器也反对自定义，在极其简单的场景下咱们能够通过增加自定义流程节点的形式来拓展性能，满足需要。
四、高效的可视化配置计划
不同于其余低代码平台，在后羿中，咱们将页面视为资源，依照资源级别来治理、公布咱们的配置，这样做的 益处 有两个：
- 第一、咱们能够依据资源的层级关系设计不同的导航格调，能够是 tab-history 模式，也能够是面包屑模式，以及你能想到的任何菜单管理模式。
- 第二、资源的治理与页面的可视化配置解耦，治理更加高效；如上图所示，除了能够随时拖拽调整菜单构造，还能够高深莫测的看到资源的详细信息；得益于这种设计，咱们提供了针对资源级别的版本公布性能，能够实现一键迭代及线上热更新；基于 V 音讯的工单版本治理，平安高效可追溯，还可能实现秒级回退。
如上图，咱们还提供了模板、代码片段性能，模板专一于同类型页面的复用，代码片段则专一于组件、性能逻辑的复用；通过复用，能够极大的升高开发工夫，5 分钟搭建页面不再是夸夸其谈。
零碎性能上咱们提供了一键开启罕用的水印、菜单搜寻、音讯告诉等性能，还能够配置多种类型客服信息，不便零碎级的版本公布告诉及日常的值班人员保护。
页面内容的配置咱们采纳了大家最习惯的从左到右的拖拽配置形式，可视化的配置形式便捷、高效，而且实时拖拽，即刻预览。
动静交互同样反对可视化配置，流程的运行逻辑清晰的展现在画布上，直观又容易保护。
此外，咱们还提供了一些贴心的性能：内置动静接口代理，一键开启后，即可连贯本地或 mock 服务，开发调试十分不便；对立的服务配置入口，除了合乎开发直觉，也不便了零碎层面的接口治理及复用，零碎还会依据不同环境主动执行接口匹配。
咱们提供了页面构造纲要视图，只需点击 icon，便能够疾速定位到组件，解决了简单页面查找组件的苦楚；
开发或迭代时，对页面的改变无奈追溯也是一个痛点，于是咱们内置了版本比对，只需拖拽任意两个版本到比对框，就能够实现两者的准确比对，不便排查问题；每个版本也提供了版本疾速回退，点击即可一键回退。
右键性能也是进步配置效率的法宝，基于右键，咱们提供了组件的复制粘贴，并且能够跨区块、跨页面、跨利用的复制粘贴；右键也能够疾速定位到组件的 schema，批改 schema 也会实时同步到视图；代码片段的保留复用也是基于右键来提供。
得益于开发者平台的分层设计，只需依照编辑器协定配置，自定义组件同样能够享受可视化的配置能力。
多层嵌套配置，是可视化中相当苦楚的场景，于是咱们提供了扁平化配置计划，比起层层重叠的弹窗配置，配置更加不便，切换老本更低。
另外咱们对老手用户也非常敌对，除了疏导式配置，咱们还提供了字段级性能阐明及文档指引，以升高配置门槛。
说到文档（如上图），这可能是很多低代码平台都会遇到的问题，咱们认为一个好的文档必须要可能指引用户由浅入深的学习平台的应用姿态，否则会间接劝退一大批用户，咱们的用户次要面向开发者，这外面还拆散出前端、后端、利用、AI、大数据等等，如何让各岗位的同学都可能找到想要的解决方案真的是很辣手，于是咱们由浅入深，层层开展，简略到手把手教学，深刻到整个外围库的原理及实现，并且还提供了海量的示例，包含数据联动、动静交互、布局等等。
五、千亿级内容投放
内容投放是否高效会间接影响用户的抉择，后羿通过通用的 CURD 接口及可动静插拔的业务模块来实现数据的存储和解决。在用户实现操作后对立执行数据处理和入库，并应用独立的投放服务来疾速散发到各业务零碎。
对于形形色色的经营数据咱们会无差别的寄存在 MongoDB 中；通过自定义的分仓策略来保障业务隔离和可扩大；当然也会波及到数据的多级关联，自定义检索等，多种手段的加持下才达到最初的准确散发。
后羿平台承载了海量的业务数据，面对微小的用户流量，咱们必须保障投放的高可用。
如图所示，咱们在架构上采纳独立镜像服务来承载各个大流量业务，各独立服务又有本地缓存、磁盘缓存和独立 Redis 集群来保障单体服务的高可用。
除了高可用，还要可能反对高并发，目前咱们的 QPS 在百万级别，每次申请可能会关联查问上百个表单，最终就会放大到千、万亿级别的表单查问量。
咱们通过异步加并发的形式晋升服务的吞吐量，联合异步监听、动静更新、定时从新加载等形式来晋升零碎的性能；多种手段的加持最终保障了服务的高并发。
对于个性化的业务诉求，咱们还反对在后羿提供的 SDK 上二次拓展，这部分与传统的开发简直没有区别。
六、低代码如何与传统开发共存
说到传统开发，那咱们就来聊聊这个陈词滥调的话题：
- 低代码如何与传统开发共存？
- 低代码会取代程序员吗？
- 低代码会不会干掉传统开发？
- 首先咱们要明确的是，两者并不抵触！
低代码也不是银弹，而传统开发有着人造的定制化劣势，灵便且没有限度，配套的技术也相当成熟；所以咱们认为两者共存，优势互补能力施展更大的价值。
那后羿是如何实际的呢？
一方面咱们一直的丰盛场景模型，进步拓展能力和配置效率；另一方面则从底层架构设计上兼容了传统的定制化开发；咱们双向反对 iframe 及微利用，双向意味着后羿产出的页面能够嵌入到第三方利用中，也承受第三方利用嵌入到后羿中；并且反对页面级、区块级和组件级的嵌入。
这种设计除了能够施展传统开发劣势，还能让现存的老、旧利用发挥余热，简略革新，就能够将他们集成到后羿，而后在此基础上应用低代码能力持续保护；得益于后羿将菜单与页面内容隔离设计的计划，咱们能够轻松的实现与第三方利用的兼容，不破换其自有的菜单管理体系。
传统开发场景，为了让大家专一于业务逻辑，咱们买通了树懒的资源疾速部署能力，并且提供了多种类型的工程脚手架，反对脚本命令一键公布迭代；另外还反对素材托管，领有独立的业务空间，平安又便捷。
以上就是后羿的低代码实践经验，这么短的篇幅不足以揭开后羿的全貌，对于低代码来说也只是无济于事，咱们利用现有的资源、服务、基建（基建真的很重要）以最小的老本孵化进去了后羿低代码平台，其实能做的还很多，咱们也会继续摸索，让每个人都能享受到低代码的乐趣。