在云栖TechDay活动第二十八期上，淘宝无线技术专家子之讲述了如何快速构建一套用于支撑营销类型产品的快速交付体系。他提出具体的解决方案是通过不同复用类型的活动解决方案的组合，以最快的效率达成业务上的诉求。
业务特征
营销活动形式多样，且经常在双十一这样的焦点事件中。
上图很好地反应了营销类业务特色：以双十一为分界点，在此之前手淘用户在线整体流量比较平稳；但在双十一之后，整个模型发生突变，呈过山车式，流量在前一分钟激，在下一分钟又会下降；在这种业务特色下，开发团队面临着巨大的挑战：首先是超大规模流量，峰值达到百万，这对系统的性能、灵活性、稳定性都有很高的要求；其次，这类活动通常在线周期短，但活动频次由特别高，会面临很多活动临时叠加功能等各类问题。
无论是阿里这类的成熟公司还是小型创业公司，对于营销活动而言，都面临着共同的境遇：一是传统工程模式笨重、耗时，跟不上业务前进的脚步；二是营销活动在开展过程中，有很多事情单靠前端无法完成，还需要多个服务端、客户端配合；很多情况下都是拼体力、重复劳动，缺乏技术积累。
极速交付模式
经历了一系列痛苦之后，在2014年初，提出来释放生产力，规模化地快速解决此类问题的方案——极速交付模式。
从宏观上看，所有的公司拥有的资源和面临的环境都是一致的。因此，可以把活动进行分级，将业务和团队业务做了分开，其中一部分业务称之为模板，可以直接快速配置完成此类业务开发；还有一部分是插件组装业务，需要提前进行积累；剩下的业务就是真正需要研发的业务，每一级别的业务都对应着不同的解决方案。其中对于高复用类型的部分需要模板化，使得可以通过配置直接完成；部分复用的共性功能插件化，以便于快速组装；对于真正需要研发参与的业务，要做到提速不可复用类型活动的研发。
模板化
在模板化方面，首先需要将需求进行梳理，之后再将其输出到前后端的模板上，通过在该模板上添加一份数据配置生成活动。换句话说就是将活动拆为模板和数据配置两部分，线上所有活动都是由N个模板和M份数据配置生成NXM份活动。
模板基本上作为活动原型，需要通过平台进行实例化去生成活动，然后再通过数据配置完成差异化和素材内容的填充，最终生成线上活动，整个过程开发人员不参于。
在模板方面，对淘系业务而言，相对较为单纯，早期无非是各类流，如图片流、卡片流等。其中图片流失通过图片+链接可以完整表达所有信息，具体实现是将页面切成很多行，每一行都是一个小区块，在前端代码处理上，每一行内的图片会根据上传时的尺寸自动布局分割。
除了前端模板化之外，还向后端进行了延伸，在服务端进行模板化，首先将业务进行抽象，之后再利用服务加数据的方式生成对应的活动接口。通过服务端模板化，手淘团队也沉淀了一些互动系统，如抽奖系统、排行榜、淘口令服务、活动评价等等。
插件化
模板化看起来是解决了很多重复性工作，但对于差异化的部分，模板是无法满足需求的。因此，手淘团队将这部分差异化的东西组件化，如淘长图、云中转之类，可以通过配置化的方式让被人将各个组件去合成最终的业务。
这其中的核心点在于通过系统增加上数据配置，一般运营人员是不懂技术的，为了便于运营人员使用，开发了MT页面服务。在MT中，数据定义分为面相开发者和运营人员两类。
开发和运营人员操作完成后，如何将这套服务提供出去呢？实际上，数据平台本身作为一个独立的服务，该服务共分为几块，一块是小二后台，它只完成两件事情：数据的定义个数据的填充。小二平台做完后会把这些数据送给数据服务模块，数据服务模块将数据存储下来，并通过CDN、MTOP以及其他服务提供给他人使用，最终通过CDN或者其他安装服务，让客户端、H5页面都能够直接使用。
研发提速
对于Buy+这类产品，是没有任何组件可以利用的，属于一个全新的项目，能够做的就是研发提速：首先在服务端上化繁为简，进而使得客户端更加灵活和自由；同时希望前端互动开发更轻松一点，效率更高一些；还希望能够和业务公共成长，有一个数据看板即时反馈结果，能够在业务上做一些判断。
服务端上化繁为简
在服务端的接口层面抽象，将所有的API统一成一类API，这一类API分为三种：普通不可登录接口、普通登录接口、安全登录接口。在入参上面，将参数分为两种，第一种是活动标识；第二种是活动入口的参数。基于这个模型，把所有的API归纳成一个统一的API，前端只用这类API即可。这类API 沉淀为APLATFFORM平台，该平台使用Groovy作为开发语言，工程成本较低，内置了测试工具，可以快速完成API测试、脚本管理以及发布管理等等事情。
客户端更加灵活和自由
服务端问题解决后来看一下客户端问题。客户端的核心问题比服务端更严重，首先客户端上线以及下线的节奏会难上很多倍，通常而言服务端代码写完之后，还可以进行流量测试，判断哪些功能被使用，然后再进行相应的功能删减；但客户端不行，因为客户端不知道谁再用，也不可能把所有的用户日志全部记录下来，只能采用抽样的方式，去抽取一些核心指标。因此，一旦新功能上线之后，在客户端功能是不敢轻易下线的，进而导致手淘安装包的大小一直在增长。该怎么解决呢？我们通过额外的东西实现在不增加手淘版本的情况下完成对UI和API功能的扩展，对应的产品分别是Poplayer和Slience，现在来重点介绍下Slience（Poplayer在其他分享中会重点介绍）。
Silence项目是在2016年双十一之前启动的，之所以叫做Silence是因为它完全不需要用户主动更新，是一个纯静态的行为。Silence设计用来在无需发版的情况下，动态加载脚本来扩展客户端API功能；服务端通过配置下发脚本到客户端，客户端通过hotpatch/dexloader机制动态加载类，H5调用统一的jsBridge，通过路由调用具体的方法。Silence的好处是可以随时随地扩展客户端功能，而且不增加客户端安装包大小；下线后删除脚本不堆积在客户端，对于增加性能消耗的功能，只在脚本运行期间产生额外开销。当然，也存在不足之处，Silence是基于脚本设计的，它都C层的API几乎完全无力支持，并且性能会比原生更低点，不适合做太复杂的运算逻辑。
那么Silence是如何构建的呢？在Server端，通过在云端完成整个脚本的发布和打包，加密后再发送到CDN上，将CDN作为下载的入口；脚本准备好之后，同时再通过ORANCE推一份配置给到客户端；ORANCE会告知脚本管理系统需要下载所需的脚本，下载的前提示脚本要足够的小，在几十K到一两百K之间；对业务来讲，大部分是通过H5或Poplayer这两个入口进入，这两个入口通过jsBridge API调用Silence模块，然后该模块会根据活动标识判断是否存在此类活动，如果有此类活动，则会将该活动加载起来，这里可能会出现两个意外，一是没有得到配置，也就是脚本上不存在该配置，此时需要去服务端主动查询是否有该活动；第二是配置上有，但脚本不一定有，如果没有脚本会尝试下载脚本并且运行，通过这种方式可以非常静默的让手淘版本快速获得Native的功能。
互动常用的动画开发模式
在前端开发时遇到一个严重的问题，当在开发互动项目时，运营人员不断提需求，希望动画效果更加炫酷，有更多的互动。传统的方式需要设计人员先进行设计，之后再将设计成品导成视频文件或FLSH，便于技术人员使用。也就是说，在没有一个完整的动画解决方案之前，大概需要一个专家级别的工程师耗费一天才能完成这一个动画的制作，耗时耗力。
为了降低动画开发成本，我们提出了AFT解决方案，希望通过AFT解决方案，将动画描述变成一个API接口，降低开发成本；同时使得动画组件积累可复用，同时降低与设计师的沟通成本。
基于AFT开发模式，我们希望在构建动画这件事情上有所积累，让技术同学真正从体力活中解脱出来，与设计师处于一个相对自然顺畅的沟通模式，让一线的施工者转变为设计者。因此，需要配合者整个设计工具和设计体系与工程师一道通过AE/AC等动画工具，去导出AFT可以消化成品。所以会将其进一步向DSL和解释器方向发展，最终的目是能够像做模板一样，将重复的简单耗体力的事情快速解决。
经过上述优化，目前可以做到产品5分钟上线，但是该产品的效果如何，并不可知，该怎么办呢？通过将上述系统所有数据结合，打通业务与行为数据，形成统一的报表，定义出在互动领域的模型；再通过该模型进行一些基础的数据分析；再加上实时的指标进行汇总。在整个过程中，数据埋点与收集全部自动化进行，开发与业务可以不用关心，可以通过数据看板即时查看反馈结果。
移动营销极速交付体系
上图是移动营销极速交付体系的技术层面的大概框图。根据需求进行模板化、插件化、测试支撑、投放支撑以及数据看板等等，形成了较为完整的解决方案。除了技术层面之外，也进行了其他层次的探索，例如根据前端和Native能力进行WebGL、WebVR、AR、3D等探索，旨在为未来应用降低成本，快速上下线。
最后来看一个经典的极速交付实践案例。双十一期间红包项目发送总金额有九千万左右，这九千万分三天发放，每天几千万，双十一当天是六千万左右。整个项目是通过Poplayer提供的火山弹出渠道，在会场和首页弹出红包火山，在开发时首页和会场页都不知道红包火山的存在。
在整个过程中，Slience提供了与首页的联动能力，能够从首页滚动到底部；流量方面，利用APLATFORM承担流量中心，能承受瞬间百万量的级别；抽奖采用Wlp承担，同时采用AFT制作动画，加快了项目研发效率，可以说整个项目中几乎用到了所有的基础技术。
在双十一快结束时，交易额已经突破一千亿，当时老板希望整个交易额能够凑个整数，需要再发红包。老板的决策是在11点下达的，从需求到上线最终只用不到半个小时。如果采用传统的方式根本不可能完成，但通过Poplayer和投放系统合作，将红包火山再弹多次；其次在搜索中又添加了其他命令，瞬间完成任务。
总结来看，之前做营销活动，更多的是煎熬，是在拼体力；但是有了今天这些解决方案之后，创造了很多不可能。将精力从上线、发布、测试中解决出来集中于攻克技术难题，提高用户体验以及业务逻辑的完整性。
