本文主要介绍了AE策略中心的技术方案选型与落地实战。
项目背景
全链路营销是去中心化的运营方式，给用户发放精细化的营销权益，打造策略中心系统。根据用户的行为记录用户的喜好商品，在满足策略中心规则后，通过C端链路的触发实现营销权益发放和权益表达。
架构设计
架构调研
当前营销各应用都是采用TMF框架，由中台提供标准的节点，营销业务层进行节点编排，每个节点都提供相应的拓展点，可以让不同营销工具实现不同的营销玩法。
上图可以看出营销计算的流程是比较固定的，业务迭代一般在当前流程的节点上进行拓展，TMF提供的拓展点就是采用策略模式。比如文案构建节点，不同的营销工具需要返回不同的文案，根据营销工具类型匹配文案构建类，执行业务规则。
但是全链路营销面向的是玩法层，所以每次迭代的业务流程都是不固定的，对用户的行为要求是不固定的，对下游的依赖也是变化的。所以根据不同的玩法模板，执行不同的业务流程节点，这样做后续的拓展性会比较好。
全链路营销具有两个链路：数据准备和权益发放，数据准备阶段是用户行为规则校验通过后通过MQ消息触发，权益发放阶段是在用户在访问某个资源位时，由上游调用策略中心触发。
用户的每个行为对我们来说都属于事件，只不过有的是同步触发，有的是异步触发，所以依赖不同的事件来编排不同的业务节点，编排方式可以通过配置中心或者Java硬编码的形式，拓展性和灵活性更高，整体建设了一个基于事件驱动的流程编排系统。
系统架构
策略中心将不同事件通过不同的渠道（channelCode）进行标识，不同的channelCode触发不同的流程编排。
策略中心的代码架构整体分为4层：
流程设计
策略中心整体代码流程实现，如下图所示：
设计说明：
模型设计
领域模型
TacticsInstanceContext只包含基础的策略执行数据，但是策略层有多个子域，各个子域对Context的依赖不同，所以需要对策略实例做能力的拓展，常见的方式有：
我们采用接口拓展的方式解决该问题，因为项目的核心设计思想就是策略+工厂模式，可以根据不同的策略模板（templateType）构建不同的Context。
比如全链路营销3.0版本需要用户的商品数据，所以进行接口IItemContext的拓展：
策略模板
每种玩法对应一种策略模板，目前有全链路营销2.0和全链路营销3.0两个模板，所以通过模板工厂去获取模板的配置：
上图可以看出，getProcessorChain()提供了核心的流程编排能力，因为每个事件对应一个channelCode，所以流程编排是基于事件标识来完成，代码示例：
publicList
节点模型
接口类：
publicinterfaceTacticsProcessor{/***节点名称*/StringgetProcessorName();/***策略实例匹配校验*/booleanvalidate(TacticsInstanceContextinstanceContext);/***策略实例执行逻辑*/voidprocess(TacticsInstanceContextinstanceContext);}拓展子类：
幂等设计
业务玩法是循环发放权益，但是只有当前用户不存在可用的资产（未领取、过期、核销等），才进行发放。
权益系统可以保证一个幂等ID只会进行一次的资源扣减和资产的写入动作，并且当一次请求失败时，权益系统内部会主动重试或回滚，所以策略中心为了防止超发问题，做了两件事：
当用户资产表查询出现抖动或者其他情况时，我们将发放的次数置为0，第几次发放willSendCnt置为1。如果用户是第一次领取，那么会执行真正的权益发放，符合业务流程；如果用户非首次领取，因为相同的幂等ID只会扣减一次资源，所以不会造成超发。
项目总结
本文主要介绍了AE策略中心的技术方案选型与落地实战。从最初版的逻辑平铺的技术设计，到基于事件驱动的流程编排系统，我们做了系统架构的优化和提升，未来可拓展性更强，业务迭代只需要增加新的的策略模板和节点即可，不会影响其他策略模板逻辑，符合开闭原则。