通用电商异步营销引擎设计-李浩

营销引擎设计

本文作者 李浩

业务场景-用户或者业务系统触发事件后，需要对用户进行营销。常见事件有

• 用户完成订单。
• 用户签到。
• 用户会员升级。
• 用户过生日。
• 其他一切可营销场景。

营销需求-用户场景触发后，可以对用户发放特定奖励，可以是优惠券，积分，现金额度等等系统支持的一切权益。

设计目标

• 面对复杂的业务需求，高可扩展性，高可复用性。一般营销活动单个活动单独编写，活动的可扩展性非常差，往往产品要支持一个新的活动，代码需要重新编写。支持的所有活动之间的联动变的非常困难。当你的系统拥有5个以上的活动后，维护一套这样的代码，变成程序员的噩梦。要迅速的支持新业务，也基本不可能。本设计用可配置的营销引擎，参与条件树和奖励树 完美解决了此问题。
• 请求量大，高并发性。
• 完善的工具支持，提供引擎后台，提供每笔营销业务的详细信息。全功能的营销活动配置客户端。

引擎功能

• 支持参与条件的无限复杂，并支持各个参与条件的动态关系扩展。
• 奖励发放条件，单活动无限奖励扩展，优惠同享与不同享根据需要动态扩展。
• 多条件满足部分条件即可发放奖励。比如10个条件，满足任意三个即可参加活动。
• 此引擎已经为多个线上不同的业务提供营销支持。
• 用户奖励预览。
• 事件取消，已发奖励回收。

概要设计

设计说明

• 蓝色区域内对应的对象，为动态对象，为每个活动请求都会生成一套。ActivityContext 是活动上下文，每次请求都会生成。上下文包含活动请求(ActivityRequest)，活动结果(ActivityResponse)，和活动处理的详细信息(ProcessInfo)。
• 浅绿区域内的类对应静态对象，是商户级别的活动配置，性能考虑，cache在jvm或者redis中，相对固定，有配置改动才更新。
• Activity 对应商户的一个活动，通过对应的ActivityBuilder构建。包含参与场景及参与条件过滤器树(FilterTree)， 奖励生成树(RewardProducer)。两个部件可都支持 AND-OR-TREE, 具备极大的扩展性,可支持复杂业务场景。
• Activity 通过 引擎Domain 构建
• AND-OR-TREE, 有两种节点，RelationFilter节点和BusinessFilter节点，RelationFilter必须有一个以上子节点，BusinessFilter只能是叶子节点。Filter接口返回一个bool值，代表是否通过，根节点表示最终是否通过，如下图所示
  
  
• 白色区域是需要持久化的对象
  ActivityRequest 经过验证后，会存储下来，用以保证信息完整，还原场景。
  ActivityRecord 是request 通过ConditionFilter后，生成的实体。代表request 成功参与了此活动（参与人次）。
  一个请求可以参与多个活动，并生成多个ActivityRecord。
  RewardRecord和ActivityRecord关联，代表参与此活动后发放的奖品。
  request参加Activity成功后，可以不生成或者生成多个RewardRecord.

并发设计

活动处理部署结构，保证高并发。异步处理，可以根据业务需要，分阶段添加节点。Cache变动小的信息，保证处理速度。

---

意见，建议 邮件 [e-mail]