二维火营销底层实践

前言

营销是餐饮行业非常重要的一环，如何通过各种营销帮助商户实现老客回流，潜在客户的推广引流，以及店内客流的数字化转变和数据沉淀等，是餐饮行业公司的核心竞争力。随着二维火会员营销业务的快速发展，营销活动业务需求越来越多，每次对接营销活动需求，对于开发人员来说，重新开发一套，都是一个费时费力，成本巨大的工作，上线的活动伴随着也越来越难维护,一个小改动也会导致系统不稳定。如何快速，灵活的去对接活动需求以及容易维护是当前面临的一个挑战。

为了应对这个挑战，会员营销底层研发团队启动了营销底层改造项目，主要围绕以下几个方面进行展开:

• 框架流程统一: 活动流程统一，提升效率, 避免重复代码，便于维护等等。
• 规则解析引擎: 优惠活动规则的配置，解析和匹配功能，将业务规则决策逻辑从系统逻辑中抽离出来。
• 优惠组件化以及优惠自动化: 封装可重用优惠组件，提升代码的可复用性。业务不关心优惠发放，优惠自动化发放。
• 工具化: 业务流程代码界面可视化，查找问题更高效，很大程度让开发人员从线上问题群解放出来。

解决方案

在明确改造点之后，我们就开始了营销底层系统的设计，具体的系统架构图如下所示。下面我们开始逐层的介绍。

框架流程统一

在框架流程统一之前，每个活动单独一套代码，因为历史原因，是由不同开发人员去开发。导致代码风格不一，代码链路也很长，后期维护人员比较难维护，一个小改动可能也会造成链路不稳定，引出其他问题。

因此，我们根据不同活动流程，梳理核心主链路，统一流程，不同活动统一流程接入。以下是部分时序图。

这里简单说下典型的两条主链路:

发布活动场景下:

• 所有营销活动都会涉及到商家发布保存这块，一般都是活动先添加保存，然后发布，整体代码流程是统一的。这里要提到的是发布这里因为不同营销活动涉及的逻辑还是有稍微区别的，所以这里提供了钩子HOOK，主流程嵌入前中后钩子，以便不同营销活动业务去扩展主流程，满足自己的业务个性化需求。这里主要还是通过活动类型路由反射去寻找不同钩子，jdk反射本身效率是很低的，目前引入了reflectasm，同时反射对象缓存了下，以便提高效率。（不过本地缓存这块有对象个数上限，后期可以考虑引入淘汰算法主动淘汰）
• 活动发布过程当中，同时也伴随着一些事件的触发，比如店铺打标等。目前主要提供了基于spring事件驱动同步或异步的钩子去满足相应需求，同时给业务方提供了相应的mq消息通知，让业务方订制业务处理。

发放优惠场景下:

• 发放优惠，首先会经过规则解析引擎这块，匹配相应的规则，进行判断，比如是否满足100块，是否是新人等，然后触发执行相应的统一发送底层接口。底层触发组件管道链路，不同组件会有不同的二进制位置标识，数据路由可以控制到不同优惠组件，优惠组件然后各自执行业务逻辑。接着也预留了个消息口子，让业务方定制化处理，比如消息触发等。

规则解析引擎

之前规则条件判断这块比较分散，规则条件判断与其他系统代码耦合在一起，改动起来也比较容易出问题。另一方面，每一个营销活动的接入都涉及到规则的开发，规则唯一不变的就是"多变"。出于规则统一的角度，以及后续平台规则可以让业务运营方定制化配置角度的考虑，引入了规则解析引擎。

规则引擎这块还是比较复杂的，不过目前我们规则这块还是比较简单的，主要还是涉及到Condition条件与Action动作。举个例子，比如判断是否新人，送礼品。

规则的判断通过condition注解标记方法去控制，规则通过的话，触发相应Action标记的方法行为。
上面只是个简单的举个例子。实际上规则判断这块，没这么简单。一般规则涉及到多个规则组合触发行为，以及多个规则有一个规则通过（可能涉及优先级@Priority），就触发行为，后续规则直接中断等。目前营销底层规则策略主要还是单个以及组合策略，还是比较简单的, 可以满足现在的需求。后面随着业务越来越复杂，以及营销活动平台开放出去的发展，运营配置化等，我们会去考虑规则动态化配置，规则策略的完善，规则表达式解析等等。

优惠组件化以及优惠自动化

优惠组件化，主要还是出于模块重用性以及代码复用性考虑，优惠之间如何执行互不影响，各自维护自己的业务以及保持自己的稳定性。目前我们优惠组件主要还是包含下面这几个:

这里提到的自动化主要还是指，基于规则触发优惠自动化发送这块。上面已经提到过，营销活动业务自己定义一些规则，判断用户是否发送优惠，主要先经过规则解析引擎，满足后触发底层优惠发送接口。后续给用户发送什么优惠，以及发送多少，失败重试以及补偿，底层自动化处理，业务方不用关心，只需要简单触发一下。当然我们也开放出去了接口，支持业务方去自定义发送什么，流水记录是否记录等。

工具化

目前我们营销业务这块正在快速发展中，随之伴随着线上大量业务的问题咨询以及答疑。开发往往在这方面花费不少时间与精力去排查。工具化就是基于此诞生的，简单说就是用产品的思维开发出这套工具，让工程团队等去查询问题，知道问题出在哪一步，极大解放出来了研发。

上面说到我们目前框架流程统一，这样其实让工具化更好统一了。那究竟工具化是怎样的呢？

比如，优惠发放整个流程节点如下图:

工程团队在使用工具化后台的话，要查看某个用户的权益发放情况。输入店铺编码与手机号，出现活动列表，选择商家相应的活动，进入到类似上面的节点图。工程团队可以查看每一步的执行情况，比如step3，触发领卡动作，可能这一步会失败，那结点上会显示为什么失败，具体原因可能是会员卡删除了还是其他的什么。简单说就是整个业务流程可视化了，可以看每一个结点的执行情况，当然业务方可以自行定义结点，在流程展示出来。不仅仅对于工程团队，对于研发来说，其实也很大减轻了排查问题的效率。

从技术层面考虑，工具化实现，除了本身框架流程自行会记录下来关键数据，我们在数据底层提供了相应的服务接口暴露开放出来，可以让业务自行自定义结点，埋点记录下来业务执行数据。目前业务结点关键数据是存储在TIDB，主要还是因为TIDB既能像MySQL一样便于使用，能让业务几乎不用做任何修改，又能满足分布式的存储需求，同时还能保证查询性能。这里提到一点，随着业务的接入，这个接口后期可能QPS还是很高的，我们目前还是通过mq去削峰，以及并发控制。

总结以及后续规划

营销底层其实很大程度上提高研发效率，以及系统稳定性。除了上面提到的一些点以外，营销底层其实还做了很多，比如动态日志级别输出等。后续随着业务的迁入，营销底层后面主要还是更多的考虑怎么去完善底层链路，规则策略，动态配置化，以及平台化开放等。

招聘

最后插播一个招聘广告，会员营销部门是一个崇尚自由、开放、互通的部门，对营销产品开发感兴趣的可以发邮件给 [email protected]

---

如果你觉得我分享的东西有所帮助,不妨关注下。