关于工作流:实时营销引擎在vivo营销自动化中的实践-引擎篇04

作者：vivo 互联网服务器团队

本文是《vivo 营销自动化技术解密》的第 5 篇文章，重点剖析介绍在营销自动化业务中实时营销场景的背景价值、实时营销引擎架构以及我的项目开发过程中如何利用动静队列做好业务流量隔离，动静公布，应用规定引擎来晋升营销规定的配置效率等几种关键技术设计实际。

《vivo 营销自动化技术解密》系列文章：

1. vivo 营销自动化技术解密|开篇
2. 设计模式如何晋升 vivo 营销自动化业务扩展性 | 引擎篇 01
3. 状态机引擎在 vivo 营销自动化中的深度实际 | 引擎篇 02
4. 工作流引擎在 vivo 营销自动化中的利用实际 | 引擎篇 03

一、背景

 营销自动化的触达场景依照时效性划分次要有两大类：

1. 离线指标用户群发。

通过对业务离线数据的剖析决策，制订适合的经营策略对指标用户进行群发触达。典型的场景有：新品举荐、流动预热、定期关心、用户召回等。

2. 实时个性化触达。

通过剖析单个用户在一段指定工夫内的行为轨迹，进行个性化的实时性营销触达。典型的场景有：领取揭示，满足流动条件触达等。

离线指标用户群发个别依据流动规定，T+ n 或者周期性对大数据离线用户数据进行批处理剖析查问，获取满足条件的指标用户，从而进行营销触达。

须要关注的问题是：海量大数据的贮存、查问性能和稳定性。而相比于离线指标用户群发，实时个性化触达对时效性的要求更高，一般来说触达成果也会更优，比方：

1. 对 24 小时内珍藏订单后，同时退出购物车的用户，push 推送流动领券揭示；
2. 对支付优惠券 1 小时内未应用的用户，推送应用揭示；
3. 对流动期间胜利下单总金额达到 999 元的用户，推送支付处分揭示；

实时个性化触达须要关注问题包含：

1. 事件实时接入的高扩展性。

须要疾速撑持接入不同业务零碎的各类行为事件和规定，须要进行对立的散发解决。

2. 高性能高牢靠对立散发解决。

3. 简单多源数据的解决。

包含数据的补全，各种规定指标的统计，指标用户的交并差计算。

4. 高效可扩大的规定匹配。

对业务定义的各种简单规定，须要有一套强扩展性的规定匹配工具。

二、外围架构设计剖析

接入层

提供多种业务事件数据接入形式（比方反对异构内部零碎的通用 HTTP，外部的 DUBBO、MQ 等），最初转成 MQ 的形式对立散发。

1. 因为事件数据源的不同，须要对宿主业务进行队列流量隔离管控，同时还须要评估后续队列的容量伸缩效率。
2.  须要满足新增事件时，无需对系统进行重新部署，须要进行动静音讯队列接入（下文会进行具体解析）。

数据处理层

实时引擎的外围局部。次要负责对事件数据进行加工解决，次要包含：

1.  业务数据的对立标识补全，将多源数据进行买通关联。
2. 对业务数据进行各种指标计算。常见的是基于工夫窗口和会话窗口的流式计算，个别应用 Flink 来搭建。
3. 指标用户匹配。罕用的用户间接交并差集计算，可能更好的对指标用户进行试验。
4. 业务规定匹配。基于业务逻辑对用户的数据进行匹配。

数据输入层

负责后果数据输入散发，次要目标是数据调配和触达发送策略。

数据管理

保留事件元数据的配置。

数据仓库

离线数据的贮存，作用于流程中各种数据处理流程。

三、要害组件和流程设计

3.1 事件实时接入的扩展性设计

因为公司外部业务技术栈不尽相同，须要反对多种业务事件数据接入形式，比方通用 HTTP 接口，Java 技术栈的 DUBBO 接口、和 MQ 音讯队列的形式，为了零碎外部能够进行对立治理，最初转成 MQ 的形式进行对立散发。

3.1.1 接入队列设计

因为事件数据源的不同，须要对宿主业务进行 MQ 队列流量管控隔离。不同业务零碎事件接入需要有以下不同的设计方案：

计划一：为每个接入的事件创立一条新队列，不同事件应用不同队列。

• 长处：最小粒度的流量管制，不同事件接入之间能够做到隔离，互不影响。
• 毛病：每次接入新事件都须要申请创立队列，随着事件接入数据减少，队列保护老本比拟高。

计划二：同一接入方的事件应用同一队列，不同接入方应用不同队列（目前音讯核心的计划）

• 长处：按接入方来进行流量管制，接入方之间进行隔离，同一接入方只需在首次接入应用时创立队列，后续接入新事件无需创立。
• 毛病： 不同接入方接入时须要创立队列，同一接入方不隔离，有相互影响的危险。

计划三：不同接入方、事件均应用同一队列

• 长处：业务方应用敌对，后续接入无需变更，耦合度小，不便切换 MQ 中间件。
• 毛病：最大粒度的流量管制，无奈做到隔离，危险较高，须要常常进行队列扩容。

计划四：当时评估每个事件的优先级（如流量），高优先级的事件独自创立一条队列，低优先级的事件共用同一队列

• 长处：按事件的维度进行流量管制。
• 毛病：对接入方应用不够敌对，不同业务接入时须要创立队列。

各计划比照如下：

论断：依照以后我的项目优先级综合评估来看，业务隔离性 > 可伸缩性 > 可维护性 > 接入方敌对性。

计划二比拟适宜。（不同的我的项目能够依据本人的理论状况按优先级进行适合的选型）

3.1.2 动静音讯监听

背景：当须要做好业务间危险隔离时，就必须按业务或者事件的维度进行队列拆分。此时若进行新接入事件就可能须要从新创立新的队列。

初期计划：采纳公司中间件 vivo-rmq, 当接入方须要新增队列时，须要批改代码新增队列监听，从新发版，这样做的问题是从新发版老本较高，依照我的项目流程治理进行效率低。

优化计划一： 批改启动加载类加载指定目录下的配置文件，新增队列时批改配置文件上传。

• 长处：无需发版。
• 毛病：仍须要重启服务器，同时须要保护配置文件目录等信息。

优化计划二：保留队列配置信息到数据表中，启用定时工作在服务器运行时动静监听数据库配置，新增或者下线队列配置记录后，主动进行队列变更。

• 长处：无需发版和重启。
• 毛病：定时工作实时性稍差，必须确保队列监听胜利后在告诉业务方接入。

论断：采纳计划二，新增事件无需对系统进行重新部署，应用运行时动静形式进行音讯队列接入。

3.2 对立散发解决

形象公共散发模板：事件参数和有效性检测 → 散发到事件规定匹配器 EventMatcher →  输入到渠道发送流程

牢靠平滑启停

1. MQ 生产端散发主流程未解决实现，零碎重启可能会造成事件音讯失落。

解决方案：配置 MQ 生产端没有返回 ack 时，MQ 服务端从新发送音讯，此时业务生产必须保障幂等性。

2. MQ 散发主流程解决实现已返回 ack，然而在散发到业务线程池过程中，因为 JVM 重启而失落。

解决方案：这种场景工夫极短，能够期待散发实现再进行 ack。

3. MQ 散发主流程散发到业务线程池解决过后，然而线程池解决渠道发送过程仍可能因为 JVM 重启而失落。

解决方案：

1. 利用 JVM ShutdownHook 钩子函数设置重启标记 flag，MQ 取数据时能够依据 flag 不再取出数据；
2. 业务线程池不再承受新的工作,  同时利用线程池本身的 Hook，期待解决线程池实现已有的工作。

3.3 简单多源数据的解决

指标补全

业务接入方能够提前将业务数据加载到对立大数据平台，并补充元数据配置，反对实时事件数据之外的数据补全。

指标统计

对规定配置数据进行，应用 Flink CEP 负责事件处理，反对工夫窗口计算。

交并差运算

基于 Presto 计算查问引擎，对不同指标用户群进行交并差负责运算，失去解决后的后果数据。

3.4 规定匹配器义

传统计划 

应用简略间接的硬编码的形式，依据不同的事件条件进行编码解决，适宜迭代更新要求低的小型零碎。

传统计划存在的问题

1. 硬编码开发成本高，交付工夫长，难以应答需要变动。
2.  业务规定反复累赘，难以保护。
3. 业务规定发生变化须要批改代码，重启服务后能力失效。

规定引擎

广义上 的规定引擎是业务规定管理系统，英文名为 BRMS(即 Business Rule Management System)，指一整套的规定治理解决方案。

而 狭义上 的规定引擎是指一个能够将业务决策从利用程序代码中分离出来的输入输出组件，接管业务数据输出，并依据业务规定输入决策。

规定引擎重点关注的是：规定配置的通用性和扩展性，以及规定匹配的性能。

规定引擎长处

1. 业务规定与零碎代码拆散，实现业务规定的集中管理。
2. 在不重启服务的状况下可随时对业务规定进行扩大和保护。
3. 能够动静批改业务规定，从而疾速响应需要变更。
4. 规定引擎是绝对独立的，只关怀业务规定，使得业务剖析人员也能够参加编辑、保护零碎的业务规定。
5. 缩小了硬编码业务规定的老本和危险。
6. 应用规定引擎提供的规定编辑工具，使简单的业务规定实现变得的简略。

规定引擎的实现选型

目前开源规定引擎 Drools、Easy Rules、表达式引擎 Aviator，还有动静语言 Groovy、甚至间接应用 SpEL 进行封装都能够作为规定引擎的一种实现计划。

1. 如果须要搭建一整套残缺 BRMS 的性能，从规定配置工作台，图形化语言建模，规定库治理等一站式解决方案，能够间接选用 Drools。这也是大家认为 Drools 应用起来比拟“重”的起因，组件繁多逻辑简单，学习老本高。
2. 如果业务场景绝对简略，只是心愿解决规定迭代频繁的问题，晋升配置管理的扩展性，能够选用 Easy Rules 或者利用表达式引擎 Aviator 为根底搭建。

规定引擎罕用利用场景

1. 危险控制系统：危险贷款、危险评估
2. 反欺诈我的项目：银行贷款、征信验证
3. 决策平台零碎：财务计算
4. 促销平台零碎：满减、打折、加价购等营销场景
5. 其余利用场景

四、总结

本文重点剖析介绍在营销自动化业务中实时营销引擎的设计，实时营销是通过剖析单个用户在一段指定工夫内的行为轨迹，产生动静的经营决策，能够对用户进行即时性的触达。

实时营销引擎架构设计次要分为事件接入、数据处理、指标计算、数据输入、元数据配置和数仓治理等模块。在我的项目开发过程咱们利用队列隔离做好业务流量隔离，队列动静配置反对事件高效接入公布，对立散发解决晋升流程的抽象化，平滑公布保障数据的可靠性，规定引擎来晋升营销规定的配置效率。