一个实时精准触达系统的自我修养

问题定义

在互联网行业，唯一不变的是变化。作为技术同学，我们经常会碰到以下几种需求：当用户收藏的商品降价后及时通知用户，促进双方交易达成；新用户或近期内未成交的用户浏览多个商品后引导用户主动和卖家聊天、也可以给用户发个红包促进用户首单的达成；

这类需求本质上是这样的逻辑：实时采集分析用户行为，通过规则计算，对符合条件的用户进行精准触达。普通开发模式很难敏捷的实现承接这类需求，为此我们专门研发了Omega系统解决这类问题。Omega系统分为三个子系统：

• 行为采集中心

• CEP规则中心

• 用户触达中心

我们在之前文章已经详细说明前两部分，本次我们将着重阐述用户触达系统是如何设计和实现策略灵活配置和精准触达的。

系统设计

逻辑架构

为了方便读者理解，我们简单回顾Omega系统的逻辑架构。Omega系统基于高内聚低耦合的原则进行拆分，每个部分本身是独立完整的系统，也可以组装后提供服务。

• 第一层是用户行为采集中心，通过采集端上请求的MTOP(应用网关)接口和端上用户行为埋点，将数据清洗为规整的用户行为数据；

• 第二层是EPL（闲鱼基于CEP设计）规则计算中心，通过解析DSL生成Blink(Flink，开源流计算框架)流计算任务，输出满足规则的用户；

• 第三层为用户触达中心，定义触达策略和通道，将策略实时触达给用户。

三层环环相扣，既可单独对外提供服务，也可联合对外承接业务，目前已经在承接用户增长、玩法和安全相关业务。

以用户增长业务举例，当用户在体验的过程中，运营通过合理策略组合，引导用户完成交易行为，到达产品形态上的“啊哈”时刻。这些策略在端内可能是权益透出、POP和实时Push，在端外是Push、短信和外呼等手段。Omega系统通过整合端内/端外的主动/被动触达渠道，以用户的实时状态为核心，实现了一套满足长周期运营的策略编排技术方案体系。

触达流程

触达流程本身比较明确，我们将流程拆分为多个小的节点，每个节点之间通过配置化方式组合，保证每个节点是可插拔、可替换的实现。整体用户触达系统处理流程如下：

• 接收CEP规则计算结果，包括规则名和满足规则的用户；

• Action路由层根据规则名查询所有订阅此规则的Action列表；

• Action过滤层根据一定策略过滤有效Action列表，过滤策略包括黑/白名单，灰度、人群和疲劳度策略；

• Action下发层会根据策略配置执行，可以是通用的触达，比如发Push、短信；也可以是调用其他业务系统，比如调用安全系统处罚；也可以将Action下发到端上执行；

• Action执行后将相关信息按照通用协议埋点，方便后续数据统计；

用户触达是Omega系统流程的最后一环，需要封装足够多的通用触达能力，保证触达的实时性、有效性，不然对用户体验会有伤害，接下来通过详细设计看下用户触达系统如何保证触达策略可组装、可插拔的灵活配置和触达实时性等特性。

详细设计

注：metaq是阿里内部使用的MQ框架；HSF是RPC框架。

用户触达中心的目标是可以单独提供服务，支持灵活可插拔配置和策略精准触达，所以在设计上着重减少对外部依赖，对外通过MQ方式减少对外部系统直接依赖和耦合；对内明确各子模块的功能边界，通过配置化方式组合子模块。

用户触达中心的主要作用是维护触达策略和封装标准触达能力，整体分为以下部分：

• 输入数据源：用户触达中心可以接收上层规则中心计算结果，也可以由外部业务系统主动触发；

• 触达物料包括文案、图片等维护在云投放系统(闲鱼素材管理系统)；

• Action路由层维护Action与规则之间的订阅关系；

• Action过滤层采用责任链模式设计，各filter相互独立，可动态插拔和灵活配置；

• Action实现层封装了各种通用触达能力实现，目前主要是云端和客户端两种；

• Action触达后会按照统一埋点协议记录，后续会整理埋点上报和数据开发流程，减少数据开发成本，方便业务方查看Action实验效果和实验归因。

Action过滤层提供多种过滤器实现，通过责任链组合形成业务校验过滤链。

Action实现层后续可通过faas模式提供Action灵活快速上线能力。为了保证在客户端执行Action的实时性，我们专门维护了与客户端的长连通道，通过针对性优化，提升通道的数据传输速度和到达率，对端上触达进行了重点保证。

• 对目标人群触达准确率大幅提升；

• 金鳞玩法延迟在1s内；

• 授人以鱼不如授人以渔，提供运营工具，彻底解放开发资源；