持续迭代的电商可视化运营页面生成系统

上个月在前端早读课作了一次关于“可视化运营页面生成系统”的live，本篇文章是此次live的文字记录。

在电商领域，活动运营扮演着极为重要的角色，一场成功的运营活动甚至能够为公司创造数千亿的成交额。因此，服务好运营同窗，是技术团队必需要作好的重中之重。纵观转转发展的几年时间内，随着公司规模增加，运营团队成员呈现急速扩充趋势。相对的，技术侧资源紧张的弊端则日益凸显，如何用极少的人力hold住大量的运营需求，相信不止转转，每个高速增加中企业都有着相似的诉求。

而本场live中，咱们将会从运营活动的基本特性出发, 透过实际应用案例，推断出活动页面生成系统的核心需求，最后引伸出一套维护成本低，可持续"自我进化“的活动页面生成系统，由于这个叫法过于拗口，因此下面咱们将简称为可视化系统

首先明确一点，这套系统是服务于公司内的运营同窗帮助他们提升产出效率的工具。注意，“公司内”这一点很是之重要，由于他给定了一个子集。

• 你们看第一条，类比于你们都熟悉的标准的运营模型AAARR(获取用户, 提升活跃度, 提升留存率，获取收入，自传播)，由于咱们做为一个逐渐打磨产品的创业公司，现阶段运营实际上是用户获取，激发活跃，提升转化率这三个方面的，这就是咱们的子集，换言之裂变玩法，自传播这块就暂时不须要投入太多精力去作。
• 第二点，最快速度，最低成本，质量尚可，众所众知，大部分运营活动常常卡某个时间点上线或者追热点，并且持续时间很短，因此投入太多资源打磨产品是没有必要也不现实的。
• 第三点，多端投放，渠道投放进行引流，因此其实这种需求对于运营这块快速兼容各类app是有很高要求的，由于瞬时峰值很大，因此结构要设计的尽量简单，这点我们放在后面的部分详细谈。
• 而后第四点，也是最重要的部分，公司方向慢变量，运营效果快变量。借用何帆老师在变量里面提到的变量的观点，快变量很好理解啊，今天咱们发放了一笔优惠券，4毛100块，过了两天发现运营搞得特别好，全国人民都知道这事了，可是花的钱太多了，怎么办？动态的须要调整。金额，中奖概率，法律条款，文案，甚至图片颜色，一位富有经验的运营同窗须要时时的监控数据的变化并进行快速调整，并且经常半夜守在公司，因此你们在碰到运营汪低声下气的求着改文案的时候，也千万要体谅一下他们。
  公司发展慢变量，这个就厉害了，他是指公司战略层面进行调整， 持续增加，变现能力，一切经营活动都是紧扣一个主题进行的。若是想在一个阶段内支撑好某个旋律，就必定要有快速跟进甚至打好提早量的思惟。有人说这个是否是太虚了。好，让咱们来看一组数据。

左边的图是周末统计出来的咱们可视化平台上面的组件使用状况，最内圈上面的两种颜色是我特别追加上去的，较浅的表明2017-2018年上半年红包发放组件占总体活动页面的比例，大概是40%-50%之间，而18年下半年急降至不足20%，相反，对于商品展现流组件的需求大大提高。这是因为公司战略由拉新用户逐渐倾斜于订单转化率的大格局致使的，若是前瞻性的定制了大量红包组件的功能，最后的结果多是很糟的，中台面临的最尴尬问题，辛辛苦苦作出来东西可是没人用。这种滋味并很差受。

眼尖的同窗已经注意到了，除了说明公司大战略变化对于可视化平台组件需求的影响，这张图片还有几个更有趣的数据，红包组件，图片组件，商品组件在该平台的使用率分别达到了79%， 71%和20%。而这三个高频组件组织在一块儿使用率高达72%。换言之，这三个组件提供了可视化平台3/4的能力。若是您是一个小型电商公司，开发好这三种组件混搭布局的方案足以解放大半研发成本。
仍是想象不出来？让咱们看下实际样例。

看着各类花哨的页面，但其实本质上面就是三种组件组合成的专题页面，看吧，在电商领域，作好了这三个组件，你的可视化系统已经可以生存下来了。

好，讲了一些业务层面的东西，如今足以支撑起咱们作技术上的选型与判断了，咱们思考一个最核心的问题，可视化系统的技术难点究竟在哪？像axure同样的自由布局方案？事件流编辑器？组件的协同工做？谈到可视化编辑你们第一反应必定是上面印象。可是相对的，复杂的技术对于研发投入，维护成本彷佛不低。甚至对使用者来讲门槛也显得比较高，借用业界的一句灵魂拷问来讲：不会写前端的人就会用sketch了吗？。并且，并且业务迭代频繁，接口不统一，各类问题都会让状况变的复杂。公司在变，时代在变，设计一套系统以不变应万变，难。

因此，咱们决定作的简单一点，作一个专一于页面生成发布，组件粗粒度编辑器（就像前面提到的三种组件），同时，经过持续迭代和自定义组件赋予她无穷的可能性。面向运营，也拥抱开发者。

生存还远远不够，回顾一下标题，持续迭代的的电商可视化运营页面生成系统。是的，咱们不但要生存下去，还要迭代，发展起来。因此咱们提出了在这三大组件上面的渐进式开发策略，下沉到各个业务线上，一步一步的迭代出各类垂类组件。仍是有点抽象？不要紧，我们再具体一点。

左边是咱们的双十一预热抽奖页面，这是一个典型的与业务同窗一同混合开发专题活动，在第一次迭代过程应用了图片组件，商品流组件和自制抽奖。然后分别定制了推荐组件和秒杀组件进行替换。抽奖组件最开始是所有内容接口写死的，但随着以后的活动咱们开发了接口的配置项，奖项配置，皮肤配置等等。这个过程是全程持续交付的。运营同窗能够经过咱们的可视化编辑器随时调整，因此在咱们的方案里，可视化平台的核心也是一个组件化交付平台。

下面开始基本就是干货了，我将重点讲一下咱们的可视化平台魔方系统，工做原理及架构图，可视化仿真器以及插件系统。

首先来看下咱们的主界面，分红预览区域和编辑区域两部分。魔方的特点在于左侧预览区域采用了“仿真器”的设计结构，可以作到逻辑，样式100%与发布后的专题保持一致，而且不须要额外的代码，并且最重要的一点在于，她不借助与任何后端服务。
而后编辑区域则是中规中矩的组件树，页面级别设置，和组件设置。

说完了主界面，让咱们看下总体的架构，其实这套系统和编译器结构稍稍有点相似，简单的能够划分红预览编辑层，页面生成层和组件层三个部分。每一个专题在编辑时会生成一个json文件用以描述该专题的配置信息，而后生成层读入这个json文件，经过webpack打包成一个完整的静态页面，是的，魔方系统从稳定性方面考虑，并无借助任何ssr或后端模板技术，纯粹是经过webpack进行打包构建的。组件层则是经过npm安装在服务器上，供动态加载器和专题生成器调用，这两块咱们一会再详细说。而最下层的核心技术栈则提供了总体的编译脚本和统一版本的第三方依赖。

好，让咱们看下仿真器这块，说仿真以前，其实咱们须要先解释一下页面生成了什么、第一段代码其实就是生成器的核心渲染逻辑简化版，返回一个组件列表而且注入相应的数据。在生成层的逻辑中，咱们以在生成模板执行构建命令，利用环境变量将专题json读入，经过分析生成下面左侧的代码，经过宏替换注入模板，最后经过webpack构建打包成最终产物。

而仿真器则是在一个iframe中内置了一个空的模板, 经过父层向iframe注入js(动态加载库)，并修改全局widgetsMap，右下所示。最后经过setState从新渲染页面。整个过程是无需后端参与的。

关于动态加载库，能够类比code split技术想象成须要哪一个组件就请求哪段代码，这里篇幅有限，暂时不展开谈论，感兴趣的能够关注大转转FE进行互动讨论。

对于分享及其余native拓展能力来讲，各个app提供的API并不相同，甚至在某些容器中没有相应的功能，为了让模拟器正常工做，咱们须要一种抹平多端差别的公共库，使得各端不会抛出错误。

说完了模拟器，咱们想聊一下组件系统，前文说过，可视化平台的核心也是一个组件化交付平台。若是开发一个组件的门槛太高就会致使开发者抛弃这套系统。因此咱们设计的一个组件将是下面的样子。

咱们的组件分红两个部分，即组件实体和配置项，在最初的组件开发过程当中，不须要任何配置项，魔方组件就是一个普通的react组件，上手的成本很是低。而随着版本迭代，愈来愈多的配置项进去，咱们提供了一套简洁的api用于快速增长配置项。关于配置项这里，咱们也尝试过采用json来描述，最后从灵活性上面来看略微不知足需求。并且可拓展性不足。

魔方提供了一套内置的api用以轻松的完成某些动做，我总结了一下大概如上6类。

为了让开发人员方便的进行定制组件的调试，咱们又设计了一套组件开发的sdk工具集，大概包括下面四个方面，第一：第三方库集合，包含所有魔方组件依赖的第三方库，在初始化一次后，任何组件编译过程当中不会从新安装。第二，面向开发者透明的构建脚本生成器，用以进行组件的本地化测试构建。第三，一个简易的编辑模拟器，用于开发时测试Config到Preview的数据流动。最后，还有一个用于快速建立项目的组件脚手架。

在组件管理这块，咱们采用monorepo+安装时构建的策略来处理组件包的。组件管理的最让人头疼的地方在于组件所依赖的其余第三方npm包的管理，利用monorepo来组织代码可使结构更加清晰，权限明确，所有组件共享构建脚本使得底层优化更加可控，安装时构建更能够确保第三方组件不会重复或多版本引用。

关于第三方的依赖的打包，咱们采用一种多层的优化策略，按重要程度划分红4个类型，金字塔最上面的是必要且稳定的一类，好比react，antd，这种是经过dllplugin打包成一个js，全部的专题均引用这一个js。其次是部分组件依赖的，组件构建时extrenal掉，当专题生成时打包进专题内，好比无限滚动插件。还有一种会频繁更新，采用外链直接引用的方式，而其余未知组件，是禁止添加到项目源码中的。

说了这么多实现细节，再说点咱们的梦想，从最开始的架构图其实能够看出，魔方的本质是可视化生成json，而后读取json生成静态页面，实际经过描述甚至能够组装成native页面，微信小城序，产出存在着各类的可能。咱们也会陆续尝试向这个方向探索，而后回顾一下咱们的仿真器，我认为能够在生成页面时进行预渲染提高速度，最后就是随着公司规模扩大如今看起来单机构建效率不足，因此咱们会考虑利用分布式构建来提高效率。

好了，总结一下本次live的观点：

1. 运营活动有不少特征，好比咱们的电商公司：图片，商品流和红包是运营的核心要素。
2. 运营活动变幻无穷，以不变应万变很难，因此让可视化系统保持生命力的关键是持续迭代和支持插件。
3. 魔方的工做方式是经过可视化编辑器生成json，经过json注入模板生成静态页面。
4. 开放插件及定制能力须要完善的配套系统。
5. 插件系统棘手的难点在于第三方依赖的管理。