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

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

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

SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。

这是衡量一个大型分布式系统是否“健康”的常见方法。在开发设计系统服务的时候，无论面对的客户是公司外部的个人、商业用户，还是公司内的不同业务部门，我们都应该对自己所设计的系统服务有一个定义好的SLA。

因为SLA是一种服务承诺，所以指标可以多种多样。最常见的四个SLA指标，可用性、准确性、系统容量和延迟。

对于消息推送而言，我们主要关注的是消息能否及时可靠的送达给用户，也就是SLA中关注的时效性和稳定性的问题。

目前消息中心针对实效性和稳定性的开发已经完成并初显成效，下面主要针对时效性和稳定性的监控做一些介绍。

如何做到时效性的无死角监控，那么我们就要对消息推送的整个流程进行拆分，把整个流程拆分成若干个独立且无依赖的可监控节点。

从消息系统流转图中可以看到，整个推送流程是清晰明了的，消息的的推送主要会经历推送鉴权、用户查询、防疲劳过滤、防重复过滤等的逻辑处理。

考虑到每个业务逻辑的处理是相互独立且无依赖的，那我们就可以根据具体的业务处理逻辑进行节点的拆分，这样就可以做到拆分无遗漏，监控无死角，拆分后的具体节点如下：

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

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

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

为了能感知到消息推送中发生的异常和耗时情况，这就需要我们标准化监控指标和监控的节点。

其中耗时指标可以感知节点的耗时和代码的坏味道，阻塞量可以监控到节点的堆积情况，推送成功率可以感知节点的推送异常等。

另外节点拆分后我们可以很快定位到异常发生的具体位置，经过拆分监控的主要节点包括鉴权、风控、用户查询、防疲劳、防重复、厂商调用等。

另外消息中心每天推送大量消息给得物用户，SLA监控任何一个操作嵌入主流程中都可能导致消息推送的延迟。

这也就要求监控和主流程进行隔离，主流程的归主流程，SLA 的归 SLA，SLA 监控代码从主流程逻辑中剥离出来，彻底避免SLA代码对主流程代码的污染，这也就要求SLA逻辑计算需要独立于推送业务的主流程进行异步计算，防止SLA监控拖垮整个主流程，那么Spring AOP+Spring Event就是最好的实现方式。

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

时效性节点监控：

时效性节点告警：

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

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

厂商监控告警：

厂商每天有数亿的消息推送，这也就意味着厂商的监控不能嵌在主流程中处理。厂商的监控代码要从主流程逻辑中剥离出来，避免监控拖垮主流程，同样避免监控异常影响到推送的主流程。针对厂商推送的监控，目前使用的是有界内存队列实现。

消息推送厂商监控上线之后，可以及时感知到厂商推送的异常信息，对于厂商推送的异常和厂商规则的更改等可以做到及时的感知。

监控上线后及时发现了发现了厂商推送线程关闭失败，厂商推送跌零、厂商营销消息规则更改、厂商通道偶发不可用等问题，并做到了及时的止损。

时效性监控上线后发现了多个服务可以优化的点，其中多个厂商和推送节点在高峰推送时耗时较高，很明显节点耗时和厂商推送 SDK 连接池和连接时间参数需要优化。优化后消息推送整体的吞吐量实现了翻倍的提升。

由于时间问题，目前消息监控只做了时效性和厂商推送稳定性相关的监控，但是监控上线后带来的收益还是比较可观的，可以预见的是监控的构建在未来必将带给我们更大的收益，后续我们可以从以下点丰富现有监控。

消息平台监控上线后带来的收益还是比较可观的，包括多次异常的及时发现和止损，还有发现多个可以优化的性能点，实现了服务高峰吞吐量的翻倍，同时也解决了我们现在遇到的以下痛点。