逻辑编排在优酷可视化搭建中的实践（一）

从可视化搭建说起

页面可视化搭建系统从16年开始如雨后春笋般涌现而出，从活动页搭建到中后台搭建，有开源有仅公司内部使用的，都致力于将前端从繁复的体力劳动中解脱出来，提高页面生产效率。优酷内部也有一套营销活动搭建系统，每年生产2K+活动页；能够满足这么多页面的需求，除了沉淀了大量可复用的组件外，围绕着搭建系统的前端研发每天都在不停地维护升级老的组件，同时生产新的组件。

痛点
页面生产能力上去了，研发还是一直埋头在组件开发需求中。这些需要都是从哪里来的呢？其实上面也有提到，就是两点：

老的组件需要添加新的能力，可能是UI改动，可能是逻辑变更
新的业务组件开发
需求是永远也做不完的，为了提高开发效率，研发侧不断地沉淀通用的基础库，与服务端商定标准化的接口，以此来减少维护成本，但基于现有模式锦上添花的优化远远不够。说白了，现有的可视化搭建效率和研发效率都已经达到瓶颈了，我们急需一种新的生产模式，给我们带来生产效率的突破性提升。

解法
我们思考一下，页面可视化搭建是如何解放生产效率的。它将完整的页面进行拆解，拆分为可以复用的组件，研发负责组件生产，产品运营负责组件配置，形成了一种简单的流水线作业的模式，这种模式的好处在于：

业务组件复用，避免重复开发，研发只需要专注于单个组件
产品运营可以介入页面生产过程，减少沟通损耗的同时分担了部分先前研发承担的工作
现在的瓶颈已从页面开发效率转变到组件开发效率上，我们做一个设想，让非研发角色也能介入到组件生产过程中，进一步提高生产效率。在此之前，我们需要先基于现有模式进一步拆分组件结构：

组件可以拆解为 UI + 逻辑。UI 可以通过细粒度的文字、图片、slider等组件搭建出来；逻辑主要涉及到接口请求、数据处理、能力调用，我们将一些常用的api调用比如跳转、常用的接口请求比如查询登录态等进行封装沉淀，加上语义化的描述，非研发人员可以将他们拖拽绘制成流程图，完成业务逻辑的编排。两者结合，就可以生产出完整的业务组件。而对于业务逻辑的组合编排，我们称之为逻辑编排。

举个栗子
我现在有个需求，需要实现一个简单的抽奖活动。页面分为两块，第一块是奖池，五个奖品横铺开，第二块是抽奖按钮，点击按钮，如果用户没登录，拉起登录面板，如果用户已登录，则进行抽奖并高亮展示对应的奖品。

我现在把UI撘出来了，就差逻辑来让对应的坑位展示了，我们把欠缺的逻辑部分拆成两段：

进入页面，也就是 componentDidMount 阶段，查询奖池
点击抽奖按钮时，查询是否登录，未登录拉起登录面板，已登录则调用抽奖接口

除了开始和结束以外的这种逻辑片段都是我们已经沉淀下来的，可以直接拖拽进来，绘制流程图。绘制完了后，我们选择模块的页面主动触发（设计给非研发用的，他们肯定不理解didMount），将它和查询奖品关联上；选择抽奖按钮的点击事件,关联上抽奖逻辑，这样模块就能在不同的时机做正确的事情了。可能你还有点小疑惑，我查询了奖品后，数据是如何映射到UI展示上的呢？要想知道如何映射，你得先知道逻辑是怎么运行的。

下图是我们在寒假战役中的一个应用场景：

Logic is Core

扯一点远的，不愿意看可以直接跳到“逻辑如何运行”小节。前端的逻辑编排相比服务编排要更复杂一点，并不是说前端逻辑编排更难，而是因为：场景更加多样化，C端模块搭建和中后台搭建的编排差异就很大；人员更加多样化，除了服务研发人员还要服务非研发人员；除此以外，还需要和UI进行结合，可能性就更多了。

这段时间比较火的 iMove ，初始被设计服务优酷活动搭建平台的逻辑编排，后面服务imgcook后，与优酷的逻辑编排在形态上已经截然不同，所以在前端比较难像服务编排一样，平台化、中心化然后去服务多种多样的业务。如果你真的很想去服务多样化的场景及业务，提供一个轻量级的库，让它足够灵活、可定制，这也是 iMove 正在走的路。

前面讲了很多，都是在说，逻辑编排需要follow不同的平台做对应的定制，但是不管形态怎么变，它的核心是不会变的，我们一定是在围绕着 “逻辑” 去做包装，将之打造为不同的产品形态。所以，逻辑才是核心！

逻辑如何运行
说了半天逻辑多重要，假使我现在抽离了一个函数出来，把它发布了，我又用它拖了个流程图，它怎么才能执行呢？

逻辑最后想要运行，无论你是出码(to code) 还是在线执行，你都需要一个“逻辑编排解释器”，这个解释器可以读懂编排后的逻辑并且去执行逻辑，这个解释器我们称之为 Runtime。代码是冰冷的，解释器是没有智商的，它并不能真的读懂逻辑，只是因为我们约定了一个规则，定好了编排后的逻辑可能有几种情况，每种情况应该如何做，Runtime 只是在依章办事，而这个规则就是 DSL 。所以逻辑想要运行，它依赖于 DSL + Runtime ，要做一个逻辑编排平台，也一定是先定好 DSL，实现 runtime ，后面才是去做平台。

每个沉淀下来的逻辑，我们将其定义为逻辑元件，加上语义化的元件名称及详细的描述，然后发布到元件市场。使用者只需要根据元件名称来挑选需要的逻辑，通过连接线将他们连接起来，就可以组合成一个流程图，这个流程图也就是一段完整的逻辑。

可是流程图导出来的 graph json 都是点和线的集合：

这种 json 如果直接用 runtime 执行有两个问题：

流程走向不直观，每个元件执行完后需要浪费时间去查找下一个元件是哪个
无效信息太多导致json体积太大进而影响加载性能，比如坐标信息(x/y)、标签信息(label) …

所以我们需要先去约定 DSL ，保证足够直观且只包含必要信息，所以我们设计了一个转换器将 graph json 转换为 DSL 。每个逻辑流程图对应一个 DSL 产物，借助 runtime 的 interpret 方法，它可能会运行在 useEffect 中，也有可能运行在某个元素的点击事件中，或者是页面的滚动事件中。

逻辑元件生产与消费的分工
逻辑元件从被编排到被运行的过程，也是它被消费的过程。文章到这里，相信大家可以感受到这个消费的过程，非研发同学确实是可以进入的，因为我们设计的足够简单。我们把整个页面的生产当做一条流水线的话，以前是模块生产 --> 模块市场 --> 页面搭建，有了逻辑编排后，我们的流水线比之前划分的更细了。

这张图是产品进入到中期的一个形态，前期的时候产品的角色更多是由研发来承担的，然后逐渐过渡到产品，到了后期呢，产研联合给运营同学做培训，中间这部分会逐渐得过渡到运营同学那边。

因为整条线上大家需要关注的事情越来越细了，页面生产线出错的几率也会低一些。

逻辑编排
上面一直在从业务角度去聊，接下来就要深入到逻辑编排里去了，讲一讲逻辑编排的设计思想。逻辑编排最主要是分为三块，元件、编排器、runtime，我将它们称作逻辑编排三板斧。那问题就转换成了：

元件该怎么做？
编排器该怎么做？
runtime该怎么做？

这三块各自拆解出基本要素，用基本要素来描述它们，互相之间建立起连接关系，这些构成了逻辑编排的规范协议。这样不管什么业务进来，只要遵循这套规范，它们的底层就是一致的，各业务也不会显得散乱。

DSL
在探讨我们的 DSL 之前，一定要先聊一聊DAG（有向无环图），因为我们的 DSL 设计本质上就是 DAG 。

DAG
DAG 的 G 指 Graph（图），图是数据结构中最为复杂的一种，我们在了解 DAG 之前，回顾图的几个要点：

顶点(vertices)：图中的一个点
边(edge): 连接两个顶点的线段
度数(degree):从一个顶点出发有几条边，这个顶点的度数就是几

图就是由一些顶点和边组成，边就是顶点间的关联关系。DAG 中的 D 是 Directed，代表是有方向的，就是说顶点之间的边带箭头，常见的比如食物链，就是有向的；A 是 Acyclic，代表无环，从某个顶点出发，无论走那条路，都不会回到那个顶点。

基于有向无环图来约定我们的 DSL 正合适不过：

我们需要有向边来告诉我们逻辑的走向
流程从开始节点出发一定要遇到结束节点才结束
我们的逻辑元件可能有多个出口，就像顶点可能会有好几个度，比如说判断是否登录，就算是2度
逻辑编排中我们没法要求流程图一定绘制成树（一个顶点到另一个顶点，只有一条路径）那样

基于DAG的DSL

每一个顶点都是逻辑元件的实例，继承自逻辑元件，也可以修改自身属性。逻辑元件分了两大类 - 基础元件和业务元件。基础元件目前只有开始和结束，其他所有需要研发开发的都是业务元件，这么设计是为了降低编排使用门槛，你不需要有任何编程基础。

type: 目前只有三种类型，Start | End | Custom
func: Custom类型专用，可以是函数体，可以是函数名，如果是函数名，需要提前在 runtime 中注册
payload: 元件会开放配置项给运营配置，form表单数据会作为payload传入给顶点对应的函数
next:每个顶点都会有一或多个出度（出口），next指向目标顶点的uuid

跟 Flow-based programming不一样的是，我们移除了顶点之间的值的传递，运营不是研发，他们很难理解计算值如何流动以及如何操作它们。

Runtime
前面说到数据如何映射到UI时，不是故意卖关子，实在是要配合着 runtime 一起给您讲解一下。逻辑与UI的结合这里也只是粗略提一下，要留到后面的文章细讲。

Runtime与UI
React自身定位是用于构建UI的Javascript库，它做的就是通过 data 驱动 UI 展示，react 的 data 通常都存储在 state 中，我们刚才已经通过逻辑编排拿到了奖品数据，对此 runtime 唯一要做的就是在内部 data 与外部 react 中间架一座桥。

将逻辑内部生成的数据全部存储在内部 context 中，利用发布订阅模式，每当 context 有更新时，通知 UI 组件执行 setState，state 更新后，React 自动更新 UI。

runtime.subscribe('context', (val) => {// handle datathis.setState({ data });
})

轻量的Runtime
YOHO 的 runtime 很小，不到 10k，麻雀虽小，五脏俱全，接下里我们看看这小麻雀是如何支撑起流程编排的最后一公里 - “执行逻辑” ，又是如何和业务打交道的

逻辑编排在优酷可视化搭建中的实践（一） - 逻辑与Runtime相关推荐

逻辑编排在优酷可视化搭建中的实践之上
从可视化搭建说起页面可视化搭建系统从16年开始如雨后春笋般涌现而出,从活动页搭建到中后台搭建,有开源有仅公司内部使用的,都致力于将前端从繁复的体力劳动中解脱出来,提高页面生产效率.优酷内部也有一套营 ...
逻辑编排在优酷可视化搭建中的实践（二） - 编排器与业务
背景与价值说到逻辑编排大家应该都不陌生了,目前我们集团有多面向后端的逻辑编排技术专项,且没有统一的标准.沉淀通用的方案.也有前端逻辑编排项目,但均面向前端开发提效的逻辑编排,而我们是要打造一个面向非 ...
（原创）优酷androidclient 下载中 bug 解决
在网络情况不好的情况下,优酷androidclient下载视频会终止,用户放弃下载点击删除该任务以后,切换到网络好的情况下进行下载,会显示该视频已在下载队列里,然后clientUI界面却什么都看不到 ...
php 手机swf播放器,php获取优酷土豆页面中视频swf播放器地址_PHP教程
项目用到临时写的.待完善 /* * 根据用户提交的(swf/html)地址,获取优酷,土豆的swf播放地址 * */ private function _getSwf ($url = ") ...
php 获取优酷视频教程,php获取优酷土豆页面中视频swf播放器地址_PHP教程
项目用到临时写的.待完善 /* * 根据用户提交的(swf/html)地址,获取优酷,土豆的swf播放地址 * */ private function _getSwf ($url = '') { if ...
优酷 Android 构建速度优化实践
作者:苏彦郊(木磊) Android 项目一般使用 gradle 作为构建打包工具,gradle 简洁.动态的功能特性为人津津乐道,同样,构建执行速度缓慢的缺陷也一直为人诟病. 近年来,随着优酷功能特 ...
优酷弱网平台落地实践
作者:孙长浩(火炏) 弱网环境下的质量保障一直是公认的难题,实际生活中每个人都会遇到弱网环境,比如用户在景区地铁里,高铁上,电梯中,景区周边等场景使用APP大概率都会遇到弱网场景.优酷作为视频内容AP ...
优酷客户端质量保障体系实践 | 完整PDF
分享嘉宾:阿里文娱技术专家翀宸优酷技术质量部海川平台负责人,主要负责优酷客户端测试解决方案的调研和实现,以及优酷基础架构业务的质量保障. 分享大纲: 优酷客户端质量保障体系的挑战基于打包构建过程 ...
关于优酷开放SDK中setOnRealVideoStartListener
在方法onRealvideoStart()中: 从mediaPlayerDelegate.videoInfo.getVid中获取播放的id,然后通过plugin.onRealVideoStart(), ...

逻辑编排在优酷可视化搭建中的实践（一） - 逻辑与Runtime

从可视化搭建说起

Logic is Core

逻辑编排在优酷可视化搭建中的实践（一） - 逻辑与Runtime相关推荐

最新文章

热门文章