蘑菇街消息推送系统实践

一、引言

      移动互联网环境下，消息推送是最基础的需求之一。将消息通过多种渠道推送给用户，达到通知、提醒、营销等目的，提升用户活跃度。蘑菇街作为电商平台，在交易支付、物流动态、活动促销、穿搭推荐、风险提醒等等很多场景下需要通过消息触达用户。目前我们的消息渠道主要包括：APP下的PUSH推送消息、IM站内信消息、短信、微信公众号（蘑菇街服务中心）、手Q购物号、电子邮件等。

       基于这些消息推送的业务，我们搭建了一套系统，满足各业务方对于触达用户的需求。运营业务方可以在后台创建临时或者周期性的推送任务，对特定用户人群推送通知和营销等消息。技术业务方也可以通过我们提供的API接口，实时触发对于单一用户或批量用户的消息通知。

二、消息系统

       对于一条消息，我们对它的定义包括两个部分。一是消息的接收人，对于不同渠道，接收人的含义是不同的。PUSH推送对应移动设备id，IM消息对应用户账号userid，短信对应手机号，微信公众号对应微信体系下的openid。二是消息的内容，各个渠道类似，主要包括文案、图片、链接。

这里要介绍的消息系统，主要面向上层业务。对于各类渠道，主要是通过对接各通道层服务的形式来最终触达用户。整个消息系统的流程图如下： 

管理后台

       由于给用户推送消息的场景非常多，我们提供一个web后台，无论是运营业务方还是技术业务方，都需要在这个后台上创建场景才能获得相应权限。场景的内容主要包括：消息渠道、消息类型（通知 / 营销 等）、接收人类型（userid / 设备id / 手机号 等）、消息内容的模板、以及推送策略选项（是否对用户做推送频次限制 / 是否夜间不发送 等）。

       对于运营业务方，还需要提供人群数据，并选择任务的执行时间和周期。人群可以通过多种方式上传，不论以何种方式上传人群，系统都会将最终的人群数据保存到HDFS上。

       对于技术业务方，创建好场景后就可以获取一个分配的密钥appKey，以及这个场景的编号eventId。在调用API接口时，将这两个参数传入，再加上接收人id，消息内容模板中的可变部分，就可以推送一条完整的场景消息了。

另外后台还提供一个方便测试的功能，创建好场景后，可以直接给自己推一条消息测试效果。

任务调度

       任务调度是为了支持运营业务方按人群推送消息的需求。业务方在管理后台创建好任务后，需要通过调度程序实现两个机制。一是对于周期任务，在指定时间对更新人群数据。二是在指定时间执行消息推送任务，读取人群数据并调用API接口。

      任务调度是在LTS框架下实现的。LTS（Light Task Scheduler）是一个轻量级的分布式任务调度框架，它包含三个角色JobClient、JobTracker、TaskTracker。管理后台作为JobClient通过rpc将任务id和执行时间发送至JobTracker，再启动一个TaskTracker服务实现任务执行逻辑。任务的触发则由LTS本身的JobTracker执行。 

接入层

        接入层通过公司内广泛使用的rpc框架Tesla提供接入服务。在提供给接入方的开发包中将接口的输入和输出定义好。Client在订阅服务后即可实现和所有Server的长连接。

       在接入层，首先会对每一次请求鉴权，appKey和eventId不匹配时拒绝请求，也可以对各接入方做流量限制。消息内容的拼装也是在接入层完成的。在管理后台创建场景时填写的内容模板，套上请求参数里的可变内容，组成完整的消息内容。比如模板是『你在{$shopName}购买的{$itemName}已发货』，是请求参数是{"shopName":"阿迪达斯专卖店","itemName":"2017新款卫衣"}，那么最终的消息内容是『你在阿迪达斯专卖店购买的2017新款卫衣已发货』

通过接入层的监控，可以知道实时的消息发送量，以及各业务方的请求量，了解整个系统的状态。

逻辑层

逻辑层与发送层之间通过消息队列承接，在这一层实现所有的业务处理逻辑。举几个例子：

> id映射。比如上游提供的接收人类型是userid，而PUSH推送需要通过设备id，则会将userid映射为设备id。当然并不是所有id类型都可以互相映射，这要看是否接入对应的数据服务。

> 频次限制。过于频繁的消息会打扰到用户，通过在cache中对每个用户的推送次数计数，过滤掉超过次数上限的消息。

> 夜间屏蔽。短信、微信等渠道无法在移动端完成夜间屏蔽功能，在逻辑层会根据创建场景时的配置选项判断是否过滤夜间消息。

发送层

发送层的职责就是将消息按不同的渠道发送到对应的通道层服务。PUSH推送消息对接的是内部的PUSH推送服务端；IM站内信消息对接的是内部的IM服务端；短信对接的是第三方的短信供应商服务；微信公众号和手Q购物号消息对接的是腾讯的API接口。

在发送层，会针对不同渠道做一些动态配置的功能，比如限速，比如同一渠道下的多个通道流量分配和切换。

      要特别说明的是，为了避免不同渠道的消息或者不同类型的消息互相影响到处理延时，接入层与逻辑层之间的消息队列，逻辑层与发送层之间的消息队列，都按照渠道+类型划分为多个队列。比如在发大量的营销类PUSH推送消息时，不会导致验证码短信消息受到影响而延时过长。因此，逻辑层和发送层的框架也是一个多线程并发的形式，同时消费多个队列的消息。

日志收集与呈现

       消息可能会因为系统原因或业务原因无法最终触达用户。比如系统本身故障、被策略屏蔽过滤、网络信号原因导致终端无法接收等。因此，需要对每一个消息发送的链路环节做跟踪，便于分析消息发送量的折损情况，调整策略来提高消息的最终到达率。通过在每个环节做日志打点，可以将所有的日志收集到一起，处理之后再呈现出来。我们对日志的处理包括在线和离线的方式。 

      在线会通过cache实时记录每个场景的发送量、过滤量、到达量以及用户点击回访的数据，生成实时报表，并且设置阈值对可能的异常发出告警。也会对所有日志按用户维度做聚合，这样可以查询每个用户在每个环节的发送记录。

离线会将所有的打点日志落地到hive表中，每天生成详细的效果报表，指导运营调整推送策略。

以上就是消息系统的大体介绍。对于关心的核心指标，系统上主要是消息的到达率和延时。业务上主要是用户接收消息后的点击回访情况。在推送策略上，也经常需要做一些ABTest，通过DMP圈选特定特征和偏好的人群，实现更精准的个性化消息推送。

更多流量、广告、搜索、算法相关内容, 敬请关注“美丽联合数据技术”公众号