【图书】活动中台：揭秘vivo的千万级DAU活动中台

前言

不管是拉新还是留存或营销活动页都是各家公司所必须的。这期推荐的这本书来自Vivo官方出品的《活动中台：揭秘vivo的千万级DAU活动中台》

图书介绍从这开始~~

作者简介

@朱明鹏，一位具有丰富可视化搭建经验的技术专家，有近10年的软件开发与架构经验。先后就职于亚信科技、途牛旅游网，积累了丰富的前后端开发经验，曾负责并参与多个大型系统软件的基础架构和业务平台的设计与研发工作。目前是vivo互联网产品平台部系统架构师，领导低代码效能工具的设计研发和和大前端领域的技术探索。

• vivo官方出品：vivo的活动中台“悟空”久负盛名，早已实现千万级DAU，是活动中台领域的标杆，被竞相学习和效仿。

• 5维度讲解：从业务设计、技术架构、核心技术、实现思路、应用实践等维度全面讲解了活动中台的设计与实现。

• 提升活动开发能力：本书将从业务、产品、技术等多个维度全面提升企业的活动开发能力，从而提升活动的效果。

• 前端技术精进：包含微前端技术架构、可视化搭建、H5性能优化、H5跨屏动态适配等大量前端技术细节。

适读人群 ：1、企业技术团队架构leader；2、企业活动业务产品经理；3、对营销中台、活动中台感兴趣的CTO、架构师等。

内容简介

本书讲解了如何将企业的营销活动开发和运营能力通过中台标准化和敏捷化，实现对前端需求的快速响应和后端能力的整合复用，从而提升企业营销能力和营销效果。

本书的内容来自于vivo官方的实践，vivo的活动中台“悟空”是各行业竞相学习和效仿的标杆。本书从业务、产品和技术的角度对悟空中台的业务设计、技术架构、核心技术、实现思路、应用实践等做了全面的讲解。

全书一共7章，可以分为三个部分：

第1部分 活动中台前世今生

首先介绍了传统活动开发的模式和瓶颈，然后介绍了vivo结合中台理念探索出的一套创新性的活动开发模式，z后介绍了活动中台的功能架构和业务设计。

第二部分 活动中台架构设计

从前端的视角讲解了如何利用微前端和H5等技术实现活动中台的架构设计和落地，不仅讲解了活动中台的架构与实现，而且还包含诸如微前端架构、可视化搭建、H5性能优化、H5跨屏动态适配等大量技术细节。

第三部分 活动中台技术探索

这部分内容是 vivo中台团队对智能活动制作的探索与设想。不仅向读者介绍了中台配套的服务端Nodejs技术，而且还介绍了中台团队在活动中台上进行的低代码实践。

摘选：第2章　活动开发模式创新

在第1章，我们分析了各团队的基本开发模式，发现现有的活动开发模式已经不再适应互联网营销业务的开展，“烟囱式”的活动体系只能为企业带来资源无法再利用、创造力无法沉淀等问题，我们决定对活动平台进行改革。

2.1　“将平台交出去”的创新设计

通过上述的平台假设，我们发现将模板、组件、素材等开发能力交给业务团队，可以走出现有活动开发模式陷入的困境，达到快速拉齐企业整体活动开发能力的目的。接下来我们将详细说明如何设计具备这种能力的活动平台。

1.聚焦底层

第1章介绍的3种活动开发模式，都需要经历需求策划、开发、运营上线等环节，这些环节都会用到最基础的平台能力，包括可视化搭建、模板与组件、素材管理、权限管理、统一登录、活动生命周期管理等。我们可以将这些底层能力统一、合并、收拢，让业务只关注活动本身的效果，让活动轻装上阵。当我们设计的活动平台可以实现上述功能时，它就可以轻松满足绝大多数的活动需求。

通过聚焦底层打造的活动平台同时也具备了通用配套的能力。例如，当我们需要找到一种有效提高活动页面转化率的方法时，A/B测试实验是必不可少的解决方案，我们可以通过该平台直接集成公司现有的实验能力，让上层业务活动直接享受实验的能力。类似的能力还包括活动数据反垃圾、线上活动加载性能跟踪、BI数据统计分析等，我们都可以基于平台去收集这些通用能力，再将其转化为统一的平台能力来为用户端赋能。这也是中台架构的关键特征。

2.系统解耦

在之前的设想中，第三方业务可以自由入驻平台，并且平台支持第三方业务的定制化开发。业务方与平台直接相交的部分是活动组件与活动任务。活动组件主要负责呈现活动效果，并与用户进行完整的交互；活动任务是负责调整活动的配置信息和营销策略。活动组件和活动任务在后文中统称为活动制品，活动制品是中台产生大量定制化需求的真正来源。

传统活动平台的形式是将活动产品的代码直接集成到平台代码中，然后根据各种上游业务的需求来定制开发。这些活动制品的开发停留于完整的平台代码中，完成开发后升级整个平台，再将制品功能提供给用户去使用。从活动需求的生命周期来看，上线的活动强依赖于平台；从编码的角度来看，活动产品代码也与平台代码紧密耦合。当活动制品的需求发生变更，活动平台需要整体发版升级，需要投入大量的开发和测试人力。

系统解耦的概念是将活动产品代码与平台系统代码分开，但是制品使用场景将返回到平台本身，这意味着活动制品可以在线集成到平台中以供用户直接使用且互不影响。

第三方如何根据自身需求完成功能定制？难道开放平台代码给业务研发团队维护？或者线下开发需求，再将功能合入主线软件版本吗？这样肯定是行不通的。先不论庞大的底层的系统需要大量人力去了解掌握，仅仅是一个制品功能，不同的业务方都会有不同的想法和诉求。在极端情况下，接入的业务方越多，发版上线就越加频繁，业务方会互相影响。

平台需要具备功能级别的解耦能力，不仅可以实现功能解耦，还可以被业务方离线二次定制开发。活动开发完成后，可以热集成至平台且无须再次发布。该扩展开发行为对平台是无损的，业务方不仅可以复用平台搭建，而且大大缩短了定制化活动上线的周期，提高了二次复用的效率。这种架构相当于在一棵参天大树上生长出的一个分支，可以在主干的基础上向着自己的方向发展，同时还可以源源不断地从大树主干中汲取营养。后续章节将会详细地对这种架构实现进行阐述。

3.共享创意

随着各业务产生的个性化制品日益增多，平台会积累大量优秀的活动制品。如果这些制品仅服务于创建的业务方，那这无疑是一种对优质活动制品的浪费。我们需要在平台上设计一个类似市场的系统，以便让每个业务的创造力在平台上流动，更好地为平台用户提供服务。当平台发展成熟后，开发人员在面对营销活动需求时，不再像过去一样第一时间进行个性化开发，而是会优先在海量创意产品中，选择符合活动定位的活动插件进行组装上线，快速响应互联网用户的需求。

为了让入驻的业务在平台里互不打扰，我们需要对业务进行虚拟隔离，在平台上设计了个人空间和共享空间。默认情况下，业务属于私有空间。私有空间具备所有通用功能，所有业务自有的个性化互动玩法、活动制品、素材、权限等与其他业务隔离，互不干扰；在共享空间中，与活动相关的模板、玩法、素材、制品都可以进行二次分享。用户可以在公共市场中，浏览其他业务方共享的优秀玩法和素材，并将其引用到本地进行二次开发或直接复用。

我们设计的平台不仅是活动创建发布平台，还是创意交流的平台，让创意碰撞，释放更多的想象力。总体而言，这三个能力是相对独立的，但同时也是可以互相促进增长的，它们共同实现了上层入驻业务、中层共享服务、底层夯实系统的功能。

到目前为止，我们已经对平台的功能进行了充分的研究和设计，明确了平台的功能要求。打造一款可共享也能定制的活动平台，迫在眉睫。

2.2　让研发人员也成为平台的用户

活动运营、产品经理是活动中台的主要用户，他们根据活动需求，在线可视化设计生成最终的H5页面。H5页面的核心组成部分是由各研发团队提交的活动制品，所以业务团队的研发成员也是平台的主要拥护。

为研发用户设计一款开箱即用的在线开发平台，是突破常规活动支撑模式的核心要点。我们带来了一站式的开发体验，提升开发效率，缩短平台活动制品的生产时间，更好地去支撑线上营销活动的开展。

回归最原始的开发诉求，该平台本质是在基础架构上重新架设了一款代码生成器，建立平台与第三方业务的开发桥梁。提升活动开发者的开发体验，主要是围绕质量、效率进行的一系列功能和流程优化。我们从开发环境、开发管理两个维度出发，武装我们的代码工具，帮助开发者快速交付活动。

1.开发环境

如果系统提供的基本组件和任务不能满足业务方的需求，则业务端开发人员应根据自己的业务场景开发相应的活动产品。这些产品可能仅在业务场景中有所不同，但是基本功能是相同的。接下来，我们将从工具库、内置组件、代码开发助手、开发人员文档这4个角度来讨论开发环境的可支持性。

（1）工具库

活动投放场景多种多样，交互触发的方式也会各不相同。例如同样的唤醒客户端分享能力的方法，A场景的方法为showShare，B场景的方法可能就会变换为goShare。为了适应不同的终端环境，我们需要封装能力统一、支持按需加载的工具类库。其中包含了强业务性的能力封装，如环境判断、用户信息获取、不同环境的分享或下载能力唤起等。

在此基础上，我们还需要提供常用的研发级的能力封装，例如 Cookie 操作、Fetch能力、Stat统一埋点操作等工具方法，帮助开发者进一步将精力聚焦于业务开发，提升活动组件开发的效率。同时，我们可以将该工具类库在公司内部开源，持续跟进最新、最优的解决方案。

（2）内置组件

内置组件是由活动平台官方的开发团队提供的快速场景获取的组件，它经常作用于活动的配置面板，例如媒体选择器、富文本、弹框、通用表单等。封装常见研发的场景，节省业务团队开发配置面板的成本。内置组件另一大优势是，可以直接调用平台的系统能力，如上传素材、获取系统数据等能力，让平台的能力更直接地服务于业务团队。

（3）代码开发助手

为了统一开发环境，不改变开发习惯，提供高效的开发工具，我们开发了一个基于VSCode的代码开发辅助插件。它集成了初始产品代码、远程代码托管、插件私服托管、开发素材存储等功能，从初始化代码生成、本地开发环境调试预览到代码自动托管，提供一站式的开发体验，帮助研发人员实现快速交付。同时，该插件集成了本地开发工作台，支持跨设备配置同步、本地存储组件组合关系等功能，开发者所见即所得。

（4）开发人员文档? ?

同时我们需要提供完善的手册说明。建立了在线开发者手册，可以帮助开发者快速上手，降低入门成本。对于理解开发环境所具备的能力来说，文档只起辅助作用，我们还需要通过将指导渗透到各个关键功能项中，因此，完善的功能提示也是提高易用性的关键。

2.开发管理

上述的开发环境的能力支撑都是从线下的维度进行的，而线上维度的管理，则需要提供活动在线开放平台去完成研发产物的管理、活动制品的流程闭环、通用能力沉淀、横向交流渠道等功能。通过在线开发平台，可以改善活动的生态，快速提高组织活动的开发效率。因此，最基本的物料素材管理、权限管理、组件管理、开发社区都是必不可少的。

（1）物料素材管理

在开发活动的过程中，我们需要托管字体、图像、音频、视频和数据文件。传统开发过程中素材物料需要在活动完成后进行统一的上线，而开发素材往往缺少线上的管理和托管，通过统一的文件服务，我们可以帮助
研发人员快速完成物料的存储。

（2）权限管理

独立完成活动或者组件开发的场景毕竟属于少数，活动的开发一般少不了多个开发者的通力协作。当活动需要多个研发人员进行协作时，就需要一套权限逻辑维护活动与开发者的关系，方便开发者配置权限。同时，该权限逻辑会关联至VSCode开发工具，从而实现线上、线下权限一致。借助权限管理，所有业务发展都变得更易于管理，问题也更容易定位和跟踪。

（3）组件管理

组件管理不仅停留在上述的权限管理，我们对组件还要进行更加细粒度的控制，例如增加了组件状态、组件版本、组件预览、组件API等一系列围绕组件使用的功能：

组件的状态分为上架、下架、已删除，方便研发将开发完善的组件交付给产品运营；

组件版本是为了解决组件升级、回滚等场景出现，有了版本切换的功能，可以更加方便地应对线上诉求，避免突发情况发生；

组件预览是为开发者提供了一套内容容器，让组件可以脱离活动直接在前台被预览，方便研发人员快速了解历史组件；

组件API结合了组件使用手册和组件能力暴露的双重作用，通过提供场景化富文本形式的输入机制，帮助使用组件的用户快速理解组件的功能。

（4）开发社区

我们在活动开发过程会遇到各式各样的开发问题，这些问题或多或少可以通过开发自治去解决，但是如果没有一套规范的开发社区，来自开发者技术相关的探讨不能有效落地，也没有人牵头对接解决，就会急剧地降低开发者体验，影响开发效率。因此，我们需要搭建一个开发者社区，方便开发用户交流、表达诉求。

至此，我们完成了活动中台对研发的全方位的生态支撑，通过我们的预研和实践，同时满足了开箱即用的活动搭建和在线定制的活动开发的能力，双管齐下才是真正的活动支撑方案的制胜利器。

2.3　原来这就是活动中台

近些年，“中台”的概念风头无俩，各大企业争相追逐，前有国外著名游戏公司Supercell的经典实践，后有阿里巴巴共享事业部中台战略下的聚划算诞生。这一切仿佛在向行业宣告中台的好处，让行业认为只有通过建设中台才能取得更大的成功。一些企业甚至将产品后台直接更名为中台，并对外宣称中台化成功。中台不是任何一家企业独有的概念，偶尔的成功或失败并不能说明中台的优劣。当中台的潮水退去后，留在岸上的是珍珠还是空壳？

因发展需要，大多数公司会将业务职责进行分解，成立不同的业务事业部。各业务单元通过自建前后台系统完成业务需求，每个项目系统都像一个孤立的烟囱，导致系统重复建设、资源不能共享、相同经验无法沉淀、数据孤岛等问题愈发严重。通过研究行业成功案例，我们发现中台架构的核心—功能复用，可以用于抽象和整合系统功能，以解决企业“烟囱式”系统的难题。

功能复用的另一个红利是可以帮助前端业务完成敏捷创新。互联网时代，前台要快速响应用户的需求，而后台要更多关注系统的稳定性和可靠性，因此二者在响应需求时会出现“速度差”。此时中台作为业务服务的提供方，既可将上层通用业务需求进行抽象沉淀，又可将后台能力进行分类收口，起到了类似“差速器”的作用。中台允许前台业务快速从已有服务矩阵中被孵化，同时能够带来更高的稳定性。例如字节跳动搭建的直播中台，就是将技术和团队进行抽象整合再复用，支撑了字节系的所有直播业务。

那么，企业如何判断自己是否适合搭建中台架构呢？我们可以通过三个自检问题进行分析。

• 目前业务系统间是否存在协同完成任务的情况？

• 若业务的独立性强，无法找到可以作为入口的共性功能，没有功能服务抽象的余地，就不太适合搭建中台。

• 目前业务是否处于成熟期，已有完整的闭环业务系统流转模式？

若目前处于成长期，过早地搭建中台系统会导致抽象返工，反而会影响实际业务发展。

中台建设需要的资源是前后端建设的好几倍，这样的资源投入企业是否能够给予足够的支持？

中台的成功不是短期就能见到成效的，需要前后台业务接受变革，并且要不断与中台相互打磨，这个过程需要大量资源去支撑。

那么，中台是否必须在各个系统都成熟稳定的前提下才能开始实施建设呢？答案也不是肯定的。如果团队已经有过类似的业务经验，对企业自身业务有深刻的认知， 并能很好地协调中台与各业务之前的关系，可以尝试从零开始建设中台。综上，我们可以明确，建设中台的前提在于企业内成熟业务存在大量协同效应，在此情况下，中台能够很好地提升业务抽象能力，从成熟共性切入作为突破口。中台协同的业务越多，其抽象和复用能力就越强，能够为前台业务提供越多的价值。

中台的建设，也需要从企业架构角度自上而下去地切入，在政策上给予支持，真正实现数据互通、业务协同、承上启下。当然，由于每个企业的业务类型和组织结构有着天壤之别，并没有中台建设的“万金油”，企业应该慎重考量，制定出最适合的中台方案。如果“为了中台化而做中台”，生搬硬套，后果将会让企业痛苦不堪。

如果我们确定企业里有共性的业务可以抽象整合，并需要赋能更多的业务，但目前各系统处于成熟稳定状态，此时我们该采用什么样的措施去实施建设呢？接下来我将为大家介绍vivo营销活动中台化的建设历程。

2017年是vivo互联网快速起步的一年，大量的营销活动逐渐上线。到2018年下半年，企业内部各业务线都开发出了符合自身业务特性的活动系统，用来支撑线上营销活动的开展。这些营销活动中，小到优惠券的领取，大到节日活动的运营，大部分都可以抽取其中的共性。

在这一时期，虽然各种业务活动模式趋于稳定，但大量的相似活动非常消耗资源，例如很多共性的系统能力建设，如监控、实验、反垃圾等。2018 年年底，vivo 成立了互联网产品平台事业部，使命是更好地调度共用资源，实现内部创新孵化和业务支撑，这恰好符合中台“抽象整合达到敏捷创新”的目标。针对上述的问题，最终部门内部决定打造一款活动中台产品来赋能所有业务线的活动开展。那么，如何将原有的支持模式过渡到中台模式呢？

业界普遍采用三种方式建设中台：固旧立新、平滑迁移、破而后立。

• 固旧立新，简而言之就是保留原始系统，以新系统为试点，逐渐将旧系统迁移和转换到新系统上。

• 平滑迁移，是维持现有系统的正常运行，在中台层面逐步沉淀共享服务中心，把前端应用的后台调用关系逐步迁移至中台中，这种升级方式对前端系统和用户无感知。

• 破而后立与前两者差别较大，要颠覆原始系统，利用中台架构全部重新构建。重新构建后的系统会为业务的各方面都带来非常大的提升，这也是重组带来的价值和效果。

由于我们采用了全新的分离式活动开发方式，打造线上线下一体的活动生态场景，所以最终决定基于单点业务进行试点，采用破而后立模式进行构建，开始开发可以支撑所有活动业务的活动中台。

本书更多内容，可以通过下方二维码详细了解

或者

更多图书推荐