快速实现运营需求，猫眼电影是如何做的？（上）

9 月 21 日，云+社区技术沙龙“小程序·云开发”北京站圆满落幕。本文是高英健老师关于猫眼团队借助小程序·云开发而开发的“小程序运营工具”后台管理系统的内容分享。

本文内容一共分成六个部分：背景、现状、探索、收益、规划、总结。

近年来小程序越来越流行，很多公司都开发出了自己家的小程序。为了吸引更多的用户使用自己的小程序，各个公司也推出了各种各样的运营活动。我不知道在座各位有没有用过猫眼电影的小程序呢？

大家没有体验过也不要紧，可以之后体验一下我们的小程序，入口在微信、钱包、猫眼电影小程序的入口。

猫眼电影小程序为了吸引用户使用我们的小程序，也推出了很多运营活动。比如说猫眼电影小程序的首页会有各种抽奖、拼团、秒抢、砍价、签到和照片墙活动，这些活动的流量比较大。

接下来讲一个小故事，发生在今年春节期间。有一天小明高高兴兴来上班，然后 PM 过来找我们说春节快到了能用一下之前七夕的活动吗？先介绍一下这个活动背景，去年七夕我们上线了一个晒情侣照撒狗粮的活动，点赞数越高排名越高，排名前十的人有电影券的活动。运营同事觉得这个活动的效果还挺好，今年春节也想上一个这样的活动晒一些团圆照。

但是这个活动是一次性的，当时没有想到活动效果这么好。匆匆忙忙一个星期好几个人加班加点开发出这样一个活动，没想到春节也要用。他说这次要改的地方有很多，要加一下这个功能、样式调整也要加一下。这个活动做过，我觉得挺快，明天能上线。然后前端开发说，这个活动一次性，假设复用需要改这些这些东西，这些这些需要后端支持，需要一起配合，大家一起商量一下。这个功能肯定需要新开发支持，明天上线肯定是不可能的。

运营 PM 说，这个需求很简单，怎么实现我不管，明天上线。前端开发很无奈，本来今天高高兴兴为什么说这种话，难受、想哭。但是很不幸，小明还是被拉去评审，来看一下这个需求到底改了什么。

左边是当年七夕活动真实的截图，右边是团圆照的设计稿。可以看到首页的样式调整还是很大的。在功能方面，新的功能支持了二级贴图的小需求，贴图可以选择某个分类下的子贴图，可以移动、删除、贴多张贴图。这是以前没有的功能，相当于重做。以前只支持一张图，但是新功能是需要支持 9 张图，多张图片的编辑、上传的功能。活动详情页样式的调整很大，而且里面有很多春节的元素。如果我们之后还想复用的话，这些元素肯定都是需要改动。

小明说，这个叫复用吗？迷茫。

据运营同学来说，这个活动的效果还比较好，所以春节时候要用，不光春节时候要用，春节之后没过几天的情人节还要用。说不定情人节之后其他的重要活动还要用。我们之前一次性的开发肯定是不合适的，这个活动应该是一个长期的，可复用的项目。

如果想要做这个，肯定要把可以变化的一些因素抽象出来，比如说背景图、文案、按钮、Logo 样式都需要配置，相当于每一次都换一次皮肤。情人节之后还有清明节等等，这不是一个段子，真的在清明节上了这么一个活动，和我们想象的不太一样，他们在清明节是晒照片其实晒的是踏青的照片，当时 PM 说清明节要上这么一个活动给我们吓一跳，这能上嘛。

现状

传统意义上如果想要复用一个活动大概分为以下几个步骤，首先 PM/运营、后端、前端大家一起商量一下这个活动哪些需要配置，把这些东西抽出来定义一下，后端就开发一个接口用来存可以变化的东西。然后前后端基于模板在管理后台添加一些活动的配置项，之后需要开发小程序，主要是前端将原来的活动模板化，然后使用后端提供的活动配置项，结合模版渲染活动。相当于运营同学可以在管理后台配置，然后前端将配置和模板化结合起来，将活动模板和数据结合起来就形成新的活动。这是很常规的操作，如果一线开发的话都会经历这样几个步骤。

传统的步骤虽然很常规，但是它真的是一个最好的方案吗？有没有其他更好的方案呢？现在大部分的项目都是前后端分离的，但是前后端分离有一些问题，比如说权责的问题。假如前后端开发一个功能的时候，有一些地方前端做没有问题，后端做也可以，前后端就会发生一些扯皮，说这个东西你来做，这时候就需要大家商量一下这个到底谁来做。

前后端服务不同，比如说前端需要部署一个 node 服务，后面需要配置一个 java 服务。这时候要联调，当后端、前端环境变得不一样的时候，前端用 node 服务是在本地开发，我们需要使用后端环境的接口需要等他们上线 staging 才可以进行联调，或者接入本地的 IP 地址进行联调。但是如果这样来回切换环境的话，联调过程会变得非常复杂，而且还要等后端去修 bug，我们才可以进行下一个联调步骤。大多数的联调时间前端同学都是在等。而且前后端分离的项目最大的时间成本在于沟通。

既然前后端分离的项目有这么多问题，那我们有没有其他的一些方案呢？

探索

我这边列出了其他两种解决方案，不想跟后端打交道，不想在联调的时候浪费太多时间，那无非就是挪到前端来做。所以第二种解决方案是前端利用 node 存储并提供接口，我们自己提供接口自己存，自产自销；第三种解决方案就是去年下半年腾讯推出的小程序开发 serverless 的解决方案。

对比下开发成本：

首先是传统意义上的开发，前后端还有运维同学都需要有一定的开发量；如果是用前端 node 存储并提供接口的方案，后端开发量变少了，但是所有的开发量都挪到前端来做，其实人力成本方面并没有减少太多，只是前端增加了一些工作量。

小程序的开发工作量又会怎样呢？现在我们还不了解，在去年的时候我们还没有接触过云开发，所以我们当时是不了解的，我们就了解了一下云开发到底是什么。

假如要开发一个新服务，如果只有一位开发人员，他需要管这里列出所有的事情，包括业务开发和后端需要做的事情和运维做的事情。如果使用云开发，你只需要管业务逻辑就可以，其他的逻辑全都是由云开发商来提供，也就是腾讯来提供。

相比于 serverless 开发方式，相比于物理机托管、云主机、容器来说，在人力成本和金钱成本其实都有一定程度的下降。因为你不用去买一些主机，不用投入人力去维护。所以说假如以前还需要多一个人去维护这个机器，现在只需要一个开发人员专注于业务开发就可以了。

由于 serverless 给前端工程师提供了可以安全、高效率操作数据库的方式，职能方面前端工程师更靠近于全栈工程师。

小程序云开发提供了三个功能：存储、数据库、云函数。存储是用来存文件，比如说图片、音频；数据库是用来存数据的，底层使用的 MongoDB。这里补充一下存储是自带 CDN 加速的。数据库底层类似于 MongoDB 的数据库，对于前端来说更好的一种存储方式，它是用 json 来存储的，更合适前端来用。然后云函数是用来跑逻辑的，云函数相当于前后端分离的项目，这种开发方式类似于 node 中间层。但是云函数其实是跑的 node 的逻辑，是放在小程序云上跑，只是一段代码而已，你不需要去维护 node 的服务。

我们要来做什么？

在业务需求方面，我们希望提供给运营/PM，配置活动配置项的功能可以自由的编辑活动数据。我们希望下一次再上这种类型的活动不需要我们参与了，可以新建一个活动配置数据，只要点上线就产生了一个新的活动，可以把这个活动的小程序码或者是链接投放到想投放的位置。

我们还希望可以给运营同学提供可视化编辑，因为每次配置完成数据都需要在小程序端预览，没问题再发布。有了可视化编辑或者模板积木化可以实时看到这次活动是如何变化的。不光是运营同学用的爽，开发也希望开发的爽，我们也给自己提了一些需求。比如说我们希望新的服务前端可以操作数据库的内容，小程序端可以更加容易地使用，减少一些接口的对接。因为接口对接太频繁，花费时间也比较多。在了解了云开发开发之后可以填一下之前的表格。

后端相比于第二种方案差不多，现在也是把所有东西都放在前端来做。但相比于第二种方案来说，由于云开发不需要写接口，所以前端接口操作可以省掉。而且小程序是天然支持云开发，也就是把小程序的环境配了，小程序可以直接调用云开发的 API 去操作数据库，去取数据库的资源或者是上传图片这样的操作。之前开发的时候，如果自己写上传的操作，不光是前端，后端也需要管上传的逻辑，前后端代码都要很多。但是小程序如果使用云开发，只需要调用 API 几行代码就可以搞定，也不需要开发接口。由于云函数不需鉴权，用户鉴权后端逻辑也可以省掉。所以相对于之前的第二种用 node 存储提供接口的方案开发成本有所降低。

基于开发，我们开发了一个小程序运营工具，代号叫“唐图”。

这个工具每一条数据都是活动的实例，可以有一些操作，比如说新建、查看、编辑、上下线、置顶、设为模板等操作。

为什么要做模板操作呢？其实有的时候运营同学假如要上一个新活动，不见得在一以前的活动上改很多内容。我们的活动比较复杂，所以配置项是蛮多的，如果所有活动都让他从头到尾配一遍估计要疯了。这个活动可能跟之前某一个活动比较类似，他可以基于之前的某个活动改一下，改一下某些图就可以继续复用了。这个模板功能是可以复制之前的某个数据，基于之前的某个数据进行小批量的修改就可以使用。

这是一个编辑的详情页，我们支持各种各样的组件允许它进行活动素材编辑。比如说上传图片、是否启用贴纸的功能。我可以操作一下背景图是什么，给它设置一个背景色。甚至现在支持了比较小范围的部分可视化编辑。比如说选择了某一块区域，这块区域可以编辑文案和颜色，我可以把这块区域可以编辑的东西展示出来供他编辑。

基于“唐图”的电影工具，我们已经把照片墙活动进行了模板化，这是已经开发完成功能的真实截图。之前所有设计稿的功能已经被实现了，我们也支持了很多照片墙活动。

讲了这么多大家一定想知道在小程序和唐图里面是如何调用云的能力呢？