二维火营销底层实践

前言

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

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

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

解决方案

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

框架流程统一

在框架流程统一以前，每一个活动单独一套代码，由于历史缘由，是由不一样开发人员去开发。致使代码风格不一，代码链路也很长，后期维护人员比较难维护，一个小改动可能也会形成链路不稳定，引出其余问题。

所以，咱们根据不一样活动流程，梳理核心主链路，统一流程，不一样活动统一流程接入。如下是部分时序图。

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

发布活动场景下:

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

发放优惠场景下:

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

规则解析引擎

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

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

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

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

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

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

工具化

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

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

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

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

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

总结以及后续规划

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

招聘

最后插播一个招聘广告，会员营销部门是一个崇尚自由、开放、互通的部门，对营销产品开发感兴趣的能够发邮件给 lurou@2dfire.com

---

若是你以为我分享的东西有所帮助,不妨关注下。