随着用户体量不断扩大，vivo互联网营销业务面临众多的效率问题：如何在活动营销中减少成本、降低难度、提升效率？如何优化终端用户的体验？

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

本期高手问答嘉宾我们邀请到来自vivo互联网系统架构师 @朱明鹏 老师。朱老师将与大家一起探讨 活动中台在vivo互联网中是如何解决营销业务的效率问题的。 

嘉宾简介

朱明鹏

近10年的软件开发与架构经验，曾负责并参与多个大型系统软件的基础架构和业务平台的设计与研发工作。目前是vivo互联网系统架构师，领导低代码效能工具的设计研发和大前端领域的技术探索。 

问：在“通过中台进行标准化和敏捷化的营销和运营”的背景下，请问“创新性的活动开发模式”和“传统模式”的差异要怎么理解，谢谢。

答：传统的活动开发模式，例如纯编码的形式、或者通过活动后台或SaaS产品进行搭建开发，抛开纯编码开发，后面两者都会有活动能力依赖项目本身。例如A活动需要具备砸金蛋组件，如果平台本身不具备，就需要负责该平台的团队或厂商进行定制开发升级上线。 而活动中台的活动开发模式，是将组件的开发能力交给了该活动的团队，开发完成后平台无需在线升级，就可以将组件热加载至活动编辑器进行使用。

问：老师 ，您好！ 活动中台是不是在设计之初就要抽象出一套通用的设计概念，然后不断的增加具体实现,如果先具体实现再抽象概念 ，是不是会造成代码重构等问题 ？ 还有一个问题是关于低代码平台， 会不会造成技术人员懒得用,非技术人员不会用的现象？

答：

1、活动中台在设计之初就是在摸索可以兼顾个性化和通用化需求的搭建方案。如果这个方案一直不满意，那将不会有活动中台，顶多算是活动平台，另外如果先考虑实现活动需求后再抽象，抽象的余地会很少，难以达到中台诉求。

2、首先我们认为术业有专攻，技术人员无法完全承担非技术的职能，相反也是这个道理。两者只能在浅层能力交界处进行适当的“跨界”输出。还有一种就是低代码提供80%-100%的案例模版，让两者都能适用。

问：如何平衡使用复杂性和功能灵活性的问题？当我需要把一个组件做到很灵活，能适应很多不同种类的活动，那么要么把组件的粒度拆分得很细，要么把组件的配置选项做的很多，这都会造成产运人员使用上的困难。如果把组件做的很傻瓜，那么就得针对不同的需求产出不同的组件，造成通用型下降。现在不太明白如何平衡这些问题。希望老师赐教。

答：

我们在抽象化组件上同样也遇到了这样的场景。产品希望设计的组件足够强大，可以面对不同活动场景。可往往到了活动运营同事那里，发现配置太多、太细，常用的就那几个，插件配置体验差。如果对组件配置进行精简设计，那其他业务的同事，大几率会反馈组件功能不满足诉求。 至于活动中台的平衡方案不能说是绝对完美，但也解决缓解了现状问题。

首先我们在设计组件时会搭配【推荐设置】，另外也会使用【渐进式的配置方案】来引导用户学习使用（例如抽奖只暴露了UI配置，负责的抽奖设置，我们使用“任务中心”的概率来承接）。 另外我们也开发了jsonschema to from的能力，帮助开发者【快速开发】多项配置的活动组件（当然插件UI需要预留能力）。

问：我一直很好奇 微前端的架构和设计模式是一个什么样的流程 还有低代码的一个实现 以及需要实现的场景？

答：活动中台简单的微前端架构设计，在vivo的公众号活动中台文章中也有介绍。在活动中台的低代码承接的使命，主要还是快速帮助开发者生成活动组件和玩法场景。

问：请问在低代码平台中各个组件间通信是如何进行的？组件是版本是如何进行管理的？谢谢。

答：组件的通信方案，您可阅读vivo的公众号文章。当初步了解活动中台下的组件加载方案，您自然就明白组件的版本是如何控制的。

问：你好，首先关注你们很久了，你们的文章内容很棒。

关于活动中台我看其他人问的比较多的是前端范围，我的问题是后端如何做到灵活适配各种活动的？比如一个签到活动，可以做成打卡满多少天，或者完成任务才能打卡，而这个任务就是每个活动不同了。那是不是就需要提供新的后端接口呢？或者你们是通过什么途径达到动态的呢？模板？规则？

再一个就是对活动中台的监控，目前的监控维度是只能支持常见的一个活动期间内，活动销售额情况和竞品对比。还是能针对不同的活动有不同的监控维度呢？

答：

一、活动中台灵活运营

1、对于通用的运营活动（例如会员权益领取，完成任务才能打卡），我们将活动抽象成Rule + Action这样的模型，Rule是一系列规则表达式的集合，Action是满足Rule执行的动作。 2、对于玩法比较复杂的活动（例如抽奖、大富翁等），这类活动玩法新颖、多变，且复用价值较低的后台服务，我们推荐业务方自行提供或中台团队评估后开发。3、我们已经在尝试在模型中融入用户资产（例如参与活动需要扣除积分），抽象奖励，能够快速的支撑任何形式的奖励发放。

二、活动中台的运营指标监控

1、对常见的监控指标做，比如日活、留存、点击率等，活动中台制定统一的采集标准和采集方法，活动的开发者和产品不用重复建设。另外对于不同的监控维度，前后台都暴露了采集的方法和接口，利用统一的监控平台进行细分管理。

问：活动中台的功能架构和业务设计，有没有使用什么设计模式？

答：您可阅读vivo的系列文章。初步了解活动中台下的功能架构和业务设计。

问：请问，中台和普通的一个业务服务有什么区别？ 假设有一个支付业务服务，和一个支付业务中台，这两个在设计的时候，有哪些不同的考虑点？

答：不同类型的中台，切入点和使命是不同的，但是它们的出发点都是类似的，需要通过【抽象复用】、【敏捷定制】的能力进行支撑前台业务诉求。在活动中台的实践和设计过程中，我们需要同时满足了通用化和个性化两个目标，这就和普通的活动平台设计产生了区别。

问：中台在设计的时候，有哪些安全性要考虑的。中台架构和普通的微服务架构区别在哪？

答：该中台目前仅在vivo内部使用，对于常规系统，安全性要求没有特殊地方额外考虑。可能大家考虑的是中台发布的活动本身的安全性要求。另外中台是抽象企业业务能力的一种设计实现，该实现是需要使用微服务技术架构来搭建中台所需要的原子服务。在活动中台，前端架构设计中，微组件的概念也是同理。

问：请问， “大中台，小前台”，在vivo 团队有啥指导的原则和最佳实践呢，可以分享下吗？

主要还是将我们的经验进行阐述一下。 我们在2018年初，遇到了因为活动的业务属性和需求紧急程度不同，各业务团队都在构建符合自身业务的活动后台。这个过程中，各系统近70%的能力时重复建设的。那如何满足基本的【抽象服用】和个性化的【敏捷定制】，我们在这个问题的驱使下设计了活动中台，目的就是整合活动能力，快速达成前台需求。这个过程中，其实缺少不了组织的推动力，来帮助中台真正的扎根、进化。

问：中台一般都会对接各个部门的多个业务线吧。这些业务线的数据是否要隔离，是否要设计租户的概念。请问，这一块如何设计？

答：你好~中台的作用是为了解决重复造轮子的问题，将不同业务线中的相似功能归并，最大化复用资源，降低企业成本。多租户概念来源于saas化服务，是否需要隔离数据，在中台建设中视具体场景而定，如会员中台，聚合企业会员信息，统一对外提供会员服务，就无需分隔数据。 如活动中台，按照各活动对系统性能的敏感性、资源使用情况考虑，可进行多租户的处理，一般从系统层-虚拟化技术，应用层-负载路由，数据层-库、表、字段等方面入手。

问：搞中台的话，一定会面临的问题是各个业务线的个性化需求，这么多个性化需求，如何处理，是都接过来做，还是都不做（只专心中台核心功能）。你在上文提到的个性化的【敏捷定制】能展开讲讲吗？

答：你好~前端的敏捷定制，一方面是支持H5组件的离线开发，在线集成；另一方面提供了全链路的开发套件。详细可以阅读vivo的公众号悟空系统文章进行了解，服务端目前无法完全支撑敏捷定制，过于个性化的诉求，需要业务方单独提供。

问：阿里都在去中台了，现在还能上中台吗？上了中台后，最大的坑是什么？中台好像只提供业务的标准版和核心功能，对接的业务方还要做不少的定制化需求，这样的话，是不是个性化需求太多的不建议接中台，没什么个性化需求的才可以考虑接入中台？

答：你好~不同的中台切入点不同，就活动业务而言，我们不仅需要是服务端的微服务能力，更多是最大化复用能力去满足活动运营对前台灵活搭建活动的诉求。就活动接入中台，他将具备插拔式的插件开发模式、低代码组件及配置生成能力，组件市场，全链路的活动支撑能力，如：监控、风控、实验、反垃圾等能力。就算该活动组件过于定制化，除去服务端能力需要单独提供，但其他的配套的能力也是很吸引开发者的。