通常从这句话开始一个运营活动项目就立项了，都说好的产品是运营出来的，可见做活动是多么的重要，也从侧面说明工作量真不小。

在最初的阶段，一个活动项目需要经历需求评审、开发、测试评审、测试、发布、开放使用、下线等流程。完成这样一个周期，长的2-3周短的也要4-5天。做了很多很多这样的活动后，一些问题也逐步显露出来：

1. 重复工作：产品、技术、测试经常在做重复的工作。

2. 反复的流程：有时一个活动在线上不过2-3天，然而从评审到上线的流程要走5-6天。

3. 客服投诉：开发测试上线时间短，产品点子一直在变，用户无法理解，技术BUG，短时流量高都给项目带了很多投诉风险。

4. 无法量产：工作繁重无法解放人员就更谈不上量产了。

为了解决上述的问题，我们开始思考运营项目的新架构，以便加速整个开发流程。

一个产品能用的条件就那么一些，能送的奖品也就那么多的形式。经过大半年的原始积累，终于有一天产品说：“上次那个活动，改个任务，明天上”。从这一刻开始，运营项目模板化的初步条件达成，项目正式进入模板化的时代。

模板化的时代，活动还是那个活动，开发需要把常用的几个条件都做好，把能发的奖品都写好。于是产品只要在后台改改任务条件，再从奖品池子中选一种奖品发放，让设计重新为页面换一套皮肤，一个全新的活动就可以上线了。

模板是这样的：

批量生产是这样的：

模板化时代确实解放了项目组，似乎诗和远方就在眼前。然而，新的问题很快就出现了：开发一个活动需要4天，那么开发一个模板就需要8天（额外的4天主要用于开发后台配置页面）。长远看利益可观，实质上短期工作量却增加了。在开发模板前，产品们总是自信的说，它一定能被复用很多次的，于是蜂拥而来的模板化需求让我们倍感压力。

因此，基于组件化可拖拽自动生成的活动上线方式应运而生。只有组件化可以更细颗粒度的复用现有能力，我们的Noah系统就是在这样的背景下诞生的。

决定了组件化的方向后，我们开始思考组件化需要面对的挑战。下图是用组件化思想对书单献花活动的拆分，得到了如下几个问题。

• 一个页面包含几个组件他们分别是什么？

• 每个组件从什么抽象组件实例化而来？用的什么版本？

• 每个组件的配置信息如何保存和展示？

• 对于包含交互的组件，谁可以执行交互动作？

• 对于包含交互的组件，执行完交互后做什么？

• 部分组件的直出数据（随页面打开时一起展示的数据信息）如何获取？

• 组件如果存在定时任务如何实现？

• 组件如何执行那种一个活动只运行一次的初始化任务？

下面一张Noah系统结构图会为我们解答上面提到的各种问题：

Noah系统包含多个活动，每个活动又包含多个页面，每个页面从上到下布局包含多个组件。每个组件包含组件基础信息、配置信息、直出数据、初始化方法、API接口、定时器等几个部分：

• 组件基础信息主要用来表明这是哪个组件的实例，使用哪个版本等信息。

• 组件配置信息主要存储组件配置。例如上文中头图组件中图片的URL地址，转盘组件中各个奖品概率、奖品描述等信息。

• 直出数据主要展示需要随页面一起显示的组件动态数据。例如榜单组件中榜单信息、投票组件中当前角色票数等。

• 初始化方法是指部分组件在每次活动开始时需要调用三方做初始化动作的方法。例如折扣卖书组件，在每次活动开始时可能需要把本次折扣卖的所有书籍在后端注册。这个方法会在配置完成后，点击活动生效按钮时被调用。

• 每个组件都有自己的API接口，当用户触发组件交互时，会采用ajax调用的方式调用固定API接口，同时附带组件实例ID来执行相关交互逻辑。

• 组件定时器用来执行组件的定时任务。例如榜单组件可能会5分钟定时从三方获取榜单数据。

为了支撑组件的管理、业务闭环以及组件的最大规模重用，Noah引入了组件管理器、检查器、动作器、行为数据。

• 组件管理器主要用来添加、编辑组件版本等信息。

• 动作器、检查器是对组件行为的进一步抽离，用于提高组件的重用性。你可以做一个组件是邀请10位用户可以砸蛋，砸开后是送起点币80点的组件。也可以做一个砸蛋组件，至于谁可以砸通过检查器配置，砸了以后做什么通过动作器配置。

• 行为数据主要通过埋点收集用户行为事件，通过大数据分析形成业务闭环。

下面的流程图说明了一个Noah活动页面是如何从用户输入URL开始一路走到最后的：

进入页面逻辑相对简单些，通过URL获取全局唯一的活动ID，通过活动ID找到这个活动下排序为0的页面，我们称为默认页面。

如果需要进入非默认页面需要在URL上跟上页面ID，通过活动ID和页面ID的组合就可以指定到某个活动下的某个页面。

由于Noah采用前后端分离架构，请求进入后先由node框架机承接，框架机会请求php获取渲染页面需要的数据，然后调取html模板使用nodejs将数据拼接到模板中输出给用户。

下图是用来渲染Noah书单献花活动首页的部分数据。

所有带动作交互的组件都有一个固定的API，当用户点击按钮触发交互逻辑时，前端通过ajax调用API附带组件实例ID。通过实例ID可以获取到组件配置信息。例如书单献花活动中的砸蛋组件，当用户点击砸时触发ajax调用，用get方式上传砸蛋组件实例ID，通过实例ID获取砸蛋组件配置的检查器ID、各个奖品概率和奖品动作器ID。

检查器是对所有检查条件的汇总。例如获取用户今日献花数量的检查器ID为1，获取用户今日消费总数的检查器ID为2。如果产品需要用户今日献花大于3即可参加活动，检查条件设置为 #{C1} > 3 即可。如果产品需要用户今日献花大于3且消费总数大于100可以参加活动。 检查器只需简单的配置为 #{C1} > 3 && #{C2} > 100。

下图说明了何如把自定义表达式#{C1} > 3 && #{C2} > 100转化为需要的代码。

首先需要有一个方法获取今日献花总数（如下图）。在配置动作器时，先找到这个方法，通过PHP反射获取到代码全部注释解析，同时获取参数列表和默认参数值。提示产品输入每个参数的值，有默认值的参数可以不输入。如果参数是运行态数据如userId可以用${userId}这样的固定符号替换，最终形成调用这个方法的全部参数列表。之后通过正则替换#{C1} > 3 && #{C2} > 100为 self::runCheckerById(1) > 3 && self::runCheckerById(2) > 100 在php中调用即可。

如果用户符合检查器条件，则可以进入下一步逻辑，执行组件本身逻辑。砸蛋组件本质就是一个概率抽奖，根据产品设定好的概率执行抽奖逻辑，抽到奖品后调用奖品对应的动作器。

动作器是所有可以执行动作的汇总，例如给用户发放起点币、发放礼品卡设置标志位等都可以用动作器实现。其实现方式和检查器类似。产品只需要配置#{A1}即可执行Id为1的动作器。

实现业务闭环中数据统计是不可缺少的一环。所有组件开发的时候需要约定好上报逻辑，当用户出发特定动作时，对外发起一个HTTP调用，附带几个参数：UserId、ActivityId、ComponentId、Time、P1、P2、P3、P4，其中P1到P4是自定义参数。例如砸蛋组件可以约定P1代表用户砸的第几个蛋。P2可以代表用户砸到的起点币数量。这样就可以知道什么时候哪个用户在哪个活动的哪个组件做了什么动作。下图是通过数据上报分析到的砸蛋组件奖品中起点币分布情况图。

Noah系统实现了活动项目的量产，但量产活动是否真的可以带来业务的增长呢？通过下面统计图可以看到，不断的活动刺激对于收入确实有明显的促进作用。这也从产品角度进一步体现了Noah系统的价值。

至此Noah系统已经基本满足了产品需求，当然还有不少问题。比如集成多个项目、多页面关联、集成数据分析等。将来，我们还会不断完善Noah，使其可以做的更好。

编者按：