一份运营活动平台的概要设计草案

背景

• 日益增加的运营活动类需求与有限的开发资源间，已经有越来越大的矛盾
• 推广活动的运行模式，具备可抽象性

整体抽象

针对常规活动，其产出机制可大致进行如下划分：

1. 针对具体活动，其预算需要确认
2. 奖品确认
3. 活动规则确认（用户参与活动需要完成的任务）
4. 用户属性的限制
5. 活动载体制作（h5）与上线
6. 针对完成任务的用户，进行奖励推送

针对上述划分的步骤，可提取出具体的服务：

1. 活动配置服务：针对活动涉及的交互组件进行组装，并生成活动实例；活动实例被下面各个服务实例依赖
2. 预算服务：创建预算实例，依赖活动实例；对接银行账户，且对所有活动的预算进行限制。预算实例可能是实际金额，也可能是虚拟产品
3. 奖品服务：创建奖品实例，依赖预算实例；对具体奖品进行配置与生成（现金或其他虚拟产品）
4. 规则服务：创建规则实例，依赖活动实例；对活动任务进行设置（比如用户需要完成注册/开户/入金/出金/抽奖等任务，就算是完成活动任务），用户完成任务后进行记录
5. 资格服务：创建资格实例，依赖活动实例；对参与活动的用户进行限制（地区限制，新用户/已注册用户/已开户用户 等属性限制）
6. 发奖服务：创建发奖实例，依赖活动实例；对完成任务的用户进行发奖（比如把现金发入用户账户，给用户的微信账户发微信红包，给用户的账户发虚拟产品等）

其中，规则服务需要察觉用户用户完成的各项任务（登陆注册、开户、入金、出金等），会依赖登陆注册服务、开户服务、出入金服务等其他服务，这里使用发布/订阅模式进行机制实现：

1. 消息总线：团队中的其他关键服务，比如登陆注册服务、开户服务等，在用户完成具体事件后，对消息总线发出具体消息；规则服务对消息总线进行订阅，对完成事件并符合资格的用户进行记录

另外，可能还需要一些服务：

1. 报名服务：创建报名实例，依赖活动实例；当需要用户通过具体活动页登陆注册后再完成任务，才能领取奖品时，需要进行用户记录
2. 抽奖服务：创建抽奖实例，依赖活动实例；对每个抽奖实例，涉及概率计算，与奖品池分配，还有可能需要动态进行奖品池调整

具体活动站点架构

对于一个具体的活动页，其可复用的东西，是页面组件，以及组件在页面中的组合关系，也就是：

1. 组件
2. 模版

接下来再设计好使用模版生成页面的调度关系，即可批量生产 h5

经过简单调研，初步考虑使用 gatsby 作为静态页生成器

开发人员开发出常用的活动交互组件（比如页面轮播 banner，抽奖转盘，手机注册 form 表单等）

开发人员在 gatsby 的架构约束下使用模版拼装组件，然后使用模版生成实际页面；也可以使用 gatsby 对接具体的数据源，在 CMS 中进行组件拼装

CMS 说明

CMS 需要对接活动涉及到的微服务群，比如奖品服务、发奖服务等。大部分的对接，是常见的表单输入、列表展示、详情展示，但针对活动页组装 组装的这部分对接，会相对复杂。

针对活动页组装的交互，主要是 3 个点：

1. 组件罗列与预览：通过 npm 统一管理组件，CMS 的组件依赖需要和活动站点的组件依赖保持同步
2. 模版预览：在页面中划分出模版预览区域，区域中展示组件拼装效果
3. 组件拖拽：待详细考虑

后续思考

1. 批量生成运营活动载体（h5）有非常明显的业务价值，但这些业务价值的具体指标，一般要如何计算
   1. 计算手工开发活动的人力成本，然后计算使用平台配置活动的人力成本，进而做对比差异
   2. 计算活动运行下来的平均收益，再和上面的对比相乘，进而得出运营平台上线后的收益指标
   3. 具体收益指标，都是指哪些指标？待进一步考虑
2. 在打造运营活动平台（low code 平台）的过程中，开发人员要如何借此增加自身的核心竞争力（或者说，这里面最硬核的东西是什么）
   1. 业务抽象能力？
   2. 非常明显的业务价值？