[开发测试] 逻辑编排在优酷可视化搭建中的实践（三）

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 开发测试 -> 逻辑编排在优酷可视化搭建中的实践（三） - 元件与平台 -> 正文阅读

[开发测试]逻辑编排在优酷可视化搭建中的实践（三） - 元件与平台

前言

前一篇文章里讲解了逻辑与Runtime&DSL，也提到了逻辑编排三板斧：元件 + 编排器 + Runtime，我在本篇将主要聊一聊元件设计以及YOHO的平台化。

元件

元件在我们的设计中，分为基础元件和业务元件，业务元件就是我们需要创建仓库、编写源码、提交发布的的元件，它是逻辑片段的实体；除它以外的都是基础元件，我们在设计给好莱坞使用的编排方案中。基础元件只有开始元件和结束元件，只是为了降低非研发人员的使用成本，元件越少越好。

虽然分成了基础元件和业务元件，但业务元件实质上是一种特殊类型的基础元件，它们的关系类似于树和图，树也是图的一种，但书里常常会把书拆成单独的一个章节，因为树的体系足够大。业务元件也是，它就是基础元件中的 Custom 元件，但在元件体系中它的比重足够大，所以我们也将它抽出来作为一个大类来讲。

元件语言

业务元件的几个重要属性如下：
在这里插入图片描述
初始化业务元件后，我们定义的文件结构：

.
|-- schema
|   |-- input.json
|   |-- output.json
|   `-- branch.json
|-- index.js
|-- package.json

index.js: 元件的入口文件，源码就写在里面，发布时文件中的源码会被作为 code 字段进行存储
package.json: 元件的 dependency 就是从里面读取，作为元件的依赖项进行存储，和 code 字段配合使用
input.json: 配置元件编排时渲染属性表单的JSON Schema，作为元件的 input 字段进行存储
output.json: 用于描述元件的返回值，同样为JSON Schema，作为元件的 output 字段进行存储
branch.json: 描述元件有几个分支，以及每种值的中文定义是什么

我们对元件中分支判断的代码制定了规范，配合 branch.json ，将这种分支型业务元件的使用成本降到了最低，使用的复杂度转嫁为开发的约束性。拿《判断是否登录》元件举例，它有两个分支，已登录与未登录，代码进行分支判断是必须按照如下的格式书写：

function foo() {
  if (isLogined) {
    return { branch: 0, data: { key: value } }
  } else {
    return { branch: 1, data: { key: value } }
  }
}

如果已登录，返回 branch 值为 0 ，如果未登录，返回 branch 值为 1。那么对应的 branch.json 必须如此定义：

['已登录', '未登录']

元件中返回的 branch 的值，会作为 branch.json 中的索引，元件中分支实际判断标准要和 branch.json 中的数组一一对应上，这样 runtime 才会按照正确的走向执行逻辑。

元件整体设计
在这里插入图片描述
基础工具侧，我们提供了模板初始化的能力、提供对应的元件开发脚手架，保障元件的基础开发能力，正在建设的 VSCode 插件用于提升研发体验，基于元件 OpenApi 提供的元件 SDK 能够帮助元件录入元件市场，目前还只是服务本地研发，4月会进行线上元件开发的能力补齐。元件的表单配置项借助 form-render 实现了可视化的表单搭建，很好用，点赞。

基于底层设施，上层实现了统一的元件市场，会按照应用、标签等进行隔离，所有业务的元件在元件市场中收敛，方便以后统一落入优酷物料中心。

元件的一生

一个元件从被生产到被编排，最后在页面被运行，贯穿了逻辑编排的始末，也是“逻辑是核心”的论证，下面我们就以元件的视角来看看整个逻辑编排过程中它都经历了啥。
在这里插入图片描述
元件被发布后，进入元件市场，在编排界面，被拖拽生成元件实例，构建完整的业务逻辑。画布中，branch.json 被用于阐述各个分支，input.json 中的 json schema 通过 form-render 渲染为可配置的表单。编排实例创建完后，与UI编排进行关联，在UI搭建平台中创建的坑位，会需要元件执行后的返回值渲染UI，UI搭建平台会解析元件的 output.json ，将所有数据平铺展示。业务模块搭建完成后，跟随页面发布上线，runtime经过启动 --> DSL 解析 --> 元件加载&注册 --> 元件检查 --> 元件执行链路执行业务相关动作，在元件执行这一步，runtime 会进行 helper 和 payload 注入，提供帮助函数以及配置数据。

两个问题

这里有两个问题是我们落地过程中争论过的点，也希望各位看官提出自己的见解。

先是业务元件还是结束元件？
元件的 JSON Schema可以被修改吗？

前端特色的逻辑编排

集团内目前还是服务编排和业务编排比较多一点，也有服务端的逻辑编排，前端侧的逻辑编排却不多见。如果你对逻辑编排、业务编排、服务编排不是很清楚，推荐这篇文章 —— 《业务编排、服务编排、逻辑编排的区别》。在落地可视化搭建系统的过程中，结合搭建技术我们做了一点比较前端质的实现。

我们的模块搭建系统，每个模块都会生成对应的 CDN 资源，页面组装的时候，会将页面用到的模块资源在服务端进行拼接 —— JS Combo。在逻辑编排落地的过程中，我们一不希望入侵现有构建服务，增加开发适配工作，第二也不希望逻辑编排增大页面 JS Bundle。所以在 runtime 的 dslWillInterpret 生命周期里，我们进行逻辑元件的资源按需动态加载。元件都很小，一个完整的流程对应的 JS 资源只有几 KB，这一点加载时间暂可忽略。配合上对已加载元件 JS 资源进行缓存重复利用，需要加载的资源体积会进一步减少。
在这里插入图片描述
这个方案帮助我们解决了另一个问题，就是同一个业务模块中，我会创建多个编排实例，两个编排实例可能会在维护过程中出现使用同一个元件的不同版本，这种场景下，如果我们不进行按需动态加载，页面的 JS Bundle 可能会不可控地急速扩大。此时回头看，按需动态加载逻辑元件，帮助我们将页面的逻辑从 JS Bundle 中抽离了出去，替换成了简洁的 DSL，页面的 JS Bundle 也变小了，对于性能还有提升。

YOHO平台

YOHO平台的结构如下。

在图的最右侧，有我们对 YOHO 的定位，它是一个平台。我们不希望做完全中心化的平台，我们只想约束协议、规范，基于这套编排协议做统一的 node 服务，对外提供 OpenApi；在前端交互侧，不奢求一套交互可以满足所有业务，编排器的外框架只会基于编排协议实现各个板块的适配器，你可以选择用或者不用我们提供的面板或者画布，或者选择性的用，编排器同样会基于这套协议去实现自动检查、编排快照等能力。

求同存异是我们的选择。
在这里插入图片描述

未来规划

FBP，业务逻辑编排最后一公里

这就需要提到我们当初做YOHO平台，要服务营销搭建平台的愿景了。将业务模块从易到难进行排列，前面75%的模块将由逻辑编排来覆盖。剩下的25%包含了我们的玩法类的或者定制性极强的模块，它们共同特点的逻辑要求高，内部状态多，想支持，也能支持，但元件调试发布、编排调试发布显得极为麻烦，在我们的预期中，这部分复杂模块是由研发来承接的。
在这里插入图片描述
可视化搭建中逻辑编排的最后一公里还有解法吗？是可解的，基于现有能力去扩展 FBP 能力，让研发能够基于流来编程，在线编写 --> 在线测试 --> 流程纠错，你不仅可以更快的开发，而且你的代码会更加安全。