从0到1，亿级消息推送的稳定性保障｜得物技术

原创暖树得物技术

消息推送简介

1.1 什么是消息推送

消息推送每天都在我们的手机上发生，如图所示，除非你的手机没有安装App或关闭了通知栏权限。

1.2 消息推送的价值

从用户的生命周期来看，消息推送对于提高App活跃度、提升用户粘性和用户留存率都起到了重要作用。

提升新用户次日留存，低成本促活，对平台的短期留存率影响显著。
提升老用户活跃度，push可以通过外部提醒起到拉活的作用。很多内容平台类App的用户push首次启动占比可达 10%以上，因此push对DAU的增量贡献不容小觑。
流失用户召回，当用户流失后，若push权限未关闭，通过消息推送的方式，有可能重新唤醒用户。

背景和痛点

消息中心为得物App提供了强大，高效的用户触达渠道，其中push对于得物DAU的贡献有可观的占比，这也就意味着每一条推送消息都是一次与用户沟通的宝贵机会，所以推送的稳定性成为我们关注的首要问题，那么我们遇到的以下痛点就亟待解决。

消息中心没有明确消息推送的耗时标准，业务和技术之间存在gap，业务方对于推送的消息什么时候到达没有明确的心理预期。
从技术上来讲消息推送各个节点的耗时不明确，无法对各个节点的耗时做针对性的优化，这也就需要我们针对消息推送的节点耗时进行监控。
消息推送的稳定性依赖于第三方的推送通道，而三方通道对于我们来讲就是个黑盒子，如何做到三方通道异常及时发现并止损也是需要考虑的问题。
在我们正常的迭代过程中有时候不可避免的会出现些异常或者有坏味道的代码，这些问题能不能及时发现、及时止损，能不能及时告警出来。

监控的实践

3.1 SLA监控简介

SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。在开发设计系统服务的时候，无论面对的客户是公司外部的个人、商业用户，还是公司内的不同业务部门，我们都应该对自己所设计的系统服务有一个定义好的SLA。因为SLA是一种服务承诺，所以指标可以多种多样。最常见的四个SLA指标，可用性、准确性、系统容量和延迟。

对于消息推送而言，我们主要关注的是消息能否及时可靠的送达给用户，也就是SLA中关注的时效性和稳定性的问题。目前消息中心针对实效性和稳定性的开发已经完成并初显成效，下面主要针对时效性和稳定性的监控做一些介绍。

3.2 系统架构图

3.3 时效性监控

3.3.1 节点的拆分

如何做到时效性的无死角监控，那么我们就要对消息推送的整个流程进行拆分，把整个流程拆分成若干个独立且无依赖的可监控节点。从消息系统流转图中可以看到，整个推送流程是清晰明了的，消息的的推送主要会经历推送鉴权、用户查询、防疲劳过滤、防重复过滤等的逻辑处理，考虑到每个业务逻辑的处理是相互独立且无依赖的，那我们就可以根据具体的业务处理逻辑进行节点的拆分，这样就可以做到拆分无遗漏，监控无死角，拆分后的具体节点如下：

3.3.2 节点耗时的计算

具体的节点拆分逻辑和耗时逻辑的计算如下图：

备注：

节点耗时的计算：记录节点消息推送到达的时间，并计算节点推送耗时，例如防疲劳耗时=T7(antiFatigueConsumeTime)-T6(checkrepeatConsumeTime)

节点阻塞量的计算：记录节点消息推送的瞬时阻塞量，例如防疲劳节点阻塞量 = 防疲劳的总量-防疲劳已经处理的量

3.3.3 节点指标的制定

既然需要监控的节点已经拆分明确了，那针对这些节点我们监控哪些指标才是有意义的呢。

目前消息推送高峰耗时较长，各业务域对于消息的到达时间也没有明确的心理一个预期，另外消息中心也无法感知推送在整个链路各个节点的耗时情况，无法针对节点耗时做到有针对性的优化，所以节点的推送量和推送耗时就是我们需要重点关注的指标。
节点的阻塞量可以让我们及时感知到推送中存在的积压问题，在大促期间，消息的推送量也会达到一个高峰，消息目前是否有堆积，处理的速度是否跟的上，是否需要临时扩容，那么节点的阻塞量就成了一个比较有意义的参考指标。

考虑到消息推送是有优先级的并且区分单推和批量推，所以我们要针对不同的优先级和推送方式设置不同的标准，消息推送耗时的具体标准如下。

3.3.4 技术方案的实现

为了能感知到消息推送中发生的异常和耗时情况，这就需要我们标准化监控指标和监控的节点。其中耗时指标可以感知节点的耗时和代码的坏味道，阻塞量可以监控到节点的堆积情况，推送成功率可以感知节点的推送异常等。另外节点拆分后我们可以很快定位到异常发生的具体位置，经过拆分监控的主要节点包括鉴权、风控、用户查询、防疲劳、防重复、厂商调用等。

另外消息中心每天推送大量消息给得物用户，SLA监控任何一个操作嵌入主流程中都可能导致消息推送的延迟。这也就要求监控和主流程进行隔离，主流程的归主流程，SLA 的归 SLA，SLA 监控代码从主流程逻辑中剥离出来，彻底避免SLA代码对主流程代码的污染,这也就要求SLA逻辑计算需要独立于推送业务的主流程进行异步计算，防止SLA监控拖垮整个主流程，那么Spring AOP+Spring Event就是最好的实现方式。

3.3.5 结果

消息推送实效性监控做完之后，对服务节点耗时异常可以及时感知，同时也完成了关键节点耗时的指标化，可以明确的看到所有节点在各个时间的耗时情况，同时也对消息推送针对各个节点的的优化起到了指导作用。

时效性节点监控：

时效性节点告警：

3.4 厂商推送监控

3.4.1 监控指标制定

消息推送接入的有多个推送通道，如何做到对这些通道做到无死角的监控，及时感知呢。

在做厂商监控之前，我们就已经遇到了厂商通道推送跌零的情况，这种情况下整个推送通道都挂掉了，我们要及时通知厂商进行修复，所以厂商推送跌零告警和厂商余量监控是必须的。
从现有数据来看，厂商的推送成功率、回执成功率、点击率都稳定在一定的的区间。如果厂商推送的指标数据偏离这个区间则说明推送有异常，所以推送成功率、回执成功率、点击率的监控是必须的。
另外从业务请求发送的用户数来看，每天的消息推送基本是稳定的，相对应的厂商的回执数量和点击数量也是稳定的，那么对厂商推送成功的数量，回执的数量和点击的数量监控也有一定的参考意义。

业务侧请求发送的用户数：