背景
目前手机APP都具有消息推送功能,比如电商类APP会推送活动宣传和促销信息,天气类APP会根据天气变化为你推送天气信息,新闻类APP会定期推送新闻资讯,聊天类APP会把离线消息做成实时推送消息,可以说推送功能已经在手机APP中扮演着越来越重的角色。从运营的角度看推送也是召回用户,提高用户活跃度和粘性的有效手段。
在iOS平台推送功能全部由APNs(ApplePush Notification service)接管,对开发者来说别无选择,当然效果也非常好。
图1 iOS 移动PUSH推送流程
在Android平台Google也提供了一个类似于APNs的功能,但是由于众所周知的原因Google的服务在国内经常不可用,所以国内很多手机厂商直接直接把GCM/C2DM(Cloudto DeviceMessaging)模块去掉了,所以Android推送在国内就出现了很多解决办法。安卓推送总体来说有三种模式:一、手机品牌厂商自建推送通道(小米推送,华为推送等),二、第三方推送比如(个推推送,极光推送等),三、手机应用自建推送通道。
图2 Google GCM/C2DM推送流程
目前Android上绝大部分推送都是基于长连接的Client-Server架构,需要客户端和服务器之间保持一个长连接,虽然Android是可以允许程序驻留在后台,但是由于手机厂商和各种清理程序查杀工具越发严格,所以这个长连接非常不稳定,除非具有庞大用户群和巨大话语权的APP,所以自建通道对普通APP效果不一定最优。手机厂商自建推送通道在自己手机品牌上使用的系统级长连接,所以在自有品牌上到达率是有保证的。第三方推送由于拥有许多手机应用可以做到各种应用直接相互唤醒,所以也能在一定程度上提高到达率。
表1 活跃用户(A通道)各个品牌手机到达率
表2 活跃用户(B通道)各个品牌手机到达率
对每种品牌手机我们希望选择到达率高的通道进行推送,所以多通道推送就成为我们迫切的需求,同时为了增加可靠性,确保服务有较强的容灾能力,我们也需要多通道推送作为保证。
图3 智能多通道推送整体流程图
为了实现多通道推送,客户端会集成多个推送通道的SDK,SDK会在初始化时将客户手机Token上报给服务端,但是每个SDK都会在一定时间间隔向服务端发送心跳,这样就会使客户端程序耗电量成倍增加,所以客户端要在开启SDK之前请求服务端,根据服务端下发的开启通道指令初始化对应的SDK。具体要开启哪个SDK是逻辑控制层根据取配置中心规则决定,只有在配置发生变化时才会重新通知SDK重新上报Token,这样就也减少了服务端存储重复Token的问题。
图4 客户端Token上报流程图
多通道推送分为多种模式,一种是根据业务需求实时推送,另外则是根据某些特征进行的批量推送。我们既要减少数据库的查询压力又要保证数据有比较小的延迟。我们用两个线程分别对发送内存队列做扫描,当消息个数或时间满足条件才会聚合数据,到数据库批量查询结果,最后组装包体交给pushProvider程序。
图5 multiPush客户端原理图
该模块有两个主要功能:一是要尽快把数据推送到第三方推送平台,二是根据配置中心的配置选择出正确通道。
图6 服务端多通道推送流程图
配置中心有两种数据,一种是根据各个通道,各个手机品牌,各个APP的推送到达率不同,推荐出的最优通道,二是需要我们人工干预的通道选择开关选项,用于容灾控制和品牌到达率对比。
实时统计是作为推送服务提供方,提供给服务使用方必备的功能。上游推送使用方发送完推送功能之后,可以使用实时统计推送结果查询推送结果。同时我们也可以在实时统计中进行达率统计,并对其进行监控,这样就可以及时发现第三方推送中出现的问题,我们随时进行调整。同时我们也可以对批量到达率进行统计分析之后放到配置中心,作为通道选择统计的必备数据。
图7 实时统计监控
本文介绍了58智能多通道推送的推送方案和每个部分的设计框架。分享出来希望和大家交流讨论。接下来我们可能会选择自建通道,虽然自建通道对到达率提高不会有太大帮助,但是现在需要我们对推送目标状态进行更加详细的数据,在线状态,网络情况,长连接的强度,推送失败的具体原因,只有拥有这些数据才能把推送到达率再上一个台阶。