1消息推送简介1.1什么是消息推送？消息推送每天都在我们的手机上发生，如图，除非你的手机没有安装App或者关闭了通知栏权限。1.2消息推送的价值从用户生命周期的角度来看，消息推送对提高应用活跃度、用户粘性和用户留存率起到了重要作用。提高新用户次日留存，低成本促活，对平台短期留存率影响显着。提高老用户的活跃度，推送可以通过外部提醒起到拉动活跃度的作用。对于很多内容平台APP来说，用户推送在上线初期的占比都在10%以上，因此推送对DAU的增量贡献不容小觑。丢失用户召回，当用户丢失时，如果没有关闭推送权限，可以通过消息推送再次唤醒用户。2背景与痛点消息中心为得物App提供了强大高效的用户接入渠道，其中推送对得物DAU贡献了相当大的比例，意味着每条推送消息都是与用户的一次交流，因此，稳定性推送成为了我们的首要关注点，所以我们遇到的以下痛点亟待解决。消息中心对消息推送没有明确的耗时标准，业务和技术存在差距，业务方对推送的消息什么时候到达没有明确的心理预期。从技术上讲，每个节点推送消息的耗时是不明确的，不可能优化每个节点的耗时，这就需要我们监控节点推送消息的耗时。消息推送的稳定性依赖于第三方推送渠道，而第三方渠道对我们来说就是一个黑盒子。如何及时发现第三方渠道异常，止损也是需要考虑的问题。在我们正常的迭代过程中，有时候难免会出现一些异常或者难闻的代码。这些问题能否及时发现，及时止损，能否及时警示。3监控实践3.1SLA监控介绍SLA（Service-LevelAgreement），又称服务水平协议，是指系统服务提供者（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监控拖累整个主进程，所以SpringAOP+SpringEvent是最好的实现方式它。3.3.5完成结果消息推送的有效性监控后，可以及时发现服务节点的耗时异常，关键节点的耗时指标也已经完成，使得可以清楚地看到所有节点每次的耗时情况。同时也对各节点的消息推送优化起到指导作用。时效节点监控：时效节点告警：3.4厂商推送监控3.4.1监控指标制定消息推送接入有多个推送通道。如何无死角地监控这些渠道，及时感知。在做厂商监控之前，我们已经遇到过厂商渠道推送降为零的情况。在这种情况下，整个推送通道都宕机了。我们不得不及时通知供应商修复它，所以需要供应商推送零掉落警报和供应商余额监控。从现有数据来看，厂商的推送成功率、接收成功率、点击率都稳定在一定范围内。如果厂商推送的指标数据偏离这个范围，就说明推送异常，所以需要对推送成功率、接收成功率、点击率进行监控。此外，从发送业务请求的用户数量来看，每天的消息推送基本稳定，对应的厂商接收量和点击量也稳定。然后监控厂商的推送成功数、接收数、点击数也有一定的参考意义。业务方请求的用户数：厂商监控告警：3.4.2技术方案实现厂商每天推送数亿条消息，厂商监控无法嵌入到主进程中进行处理。厂商的监控代码要和主流程逻辑分离，避免监控拖累主流程，也避免监控异常影响主流程推送。对于厂商推送的监控，目前使用的是有界内存队列。3.4.3结果消息推送厂商监控器上线后，可以及时感知到厂商推送的异常信息，可以及时了解厂商推送的异常情况和厂商规则的变化。4好处4.1及时发现异常监控上线后，及时发现厂商推送线程关闭失败，厂商推送降为零，修改厂商营销消息规则，厂商渠道偶发不可用等，及时止损。.时效性监控上线后发现，由于厂商推送线程创建和关闭失败导致线程数逐渐增加，避免了上线失败的情况。厂家异常导致推力跌至零。监测发现后，及时通知厂家，止损。发现厂商营销消息规则变更异常，及时整理各大厂商文档后发现，除了多个厂商渠道外，下个月还会有规则变更。实现了及时止损。4.2服务性能提升时效性监控上线后，发现多个服务优化点。其中，很多厂商和推送节点在推送高峰期耗时较长。节点耗时明显，厂商推送SDK连接池和连接时间参数需要优化。优化后，消息推送的整体吞吐量提升了一倍。5展望未来由于时间问题，目前的新闻监控只是监控厂商推送的时效性和稳定性，但监控上线后带来的收益还是很可观的。可以预见，监控的建设必将给我们带来更大的收益，未来我们可以从以下几点来丰富现有的监控。考虑到业务计划的推送量和推送时间是稳定的，我们可以为业务维度增加推送数据的监控，及时感知上游推送数据的变化。其次，我们可以监控各个节点的推送异常、漏斗转化率、服务性能，进一步丰富消息平台的监控体系。对于消息推送，我们还需要考虑推送的转化率，所以卸载、屏蔽等指标也是我们需要监控的点。通过这些业务指标，我们可以及时感知推送的效果，实现精细化管控。6小结新闻平台上线后的监控带来的收益是相当可观的，包括及时发现并止损多个异常，以及发现多个可以优化的性能点，使服务峰值翻倍吞吐量。也解决了我们现在遇到的以下痛点。时效性明确提供了不同优先级的耗时标准，避免了业务和技术的落差，业务方对耗时推送也有明确的心理预期。时效性让节点的耗时性能问题一目了然。通过优化现有节点的耗时问题，使消息服务的吞吐量翻倍。供应商稳定性监控可以让供应商及时发现异常情况。厂商稳定性监控上线后，发现了很多厂商推送的异常，并及时解决和止损。SLA时效性和厂商稳定性上线后，消息中心可以及时发现推送链接异常和代码异味，特别是新上线的代码，如果有异常可以及时发现及时。
