消息推送平台高可用实践（下）

作者：李弈远

消息推送平台现已为几十个产品提供推送服务，同时在线用户连接数超过300w，日收发消息量达几千万，对消息的实时性和可靠性均提出了较高的要求。上篇 从架构设计和部署方案角度介绍了消息推送平台的高可用保障，下面将从监控层面介绍系统服务质量保障。
推送系统的服务质量可以从几个方面来考量，直观看来，从系统开发人员的角度，主要关注于系统的负载、稳定性、性能和异常情况下系统可用性等，接入推送系统的产品方则更多关心推送的效果，如一次广播最终被多少用户接收到等，而普通用户则看重响应体验，如能否第一时间收到对方发送的消息以及消息有没有丢失等。实际上，上述这些质量要点是相互影响且互为一体的，为此推送服务从以下几个层面对系统的服务质量进行实时监控和评估。

1 服务器资源监控

服务器资源监控主要对服务器的cpu、内存、io、网络等资源的使用情况进行监控。由于推送平台部署用到了物理机和云主机，故需要同时对这两者的资源负载进行监控，另一方面，不同服务对服务器负载的关注点也不同，如redis服务器主要关注内存和io的负载情况，接入点服务器主要关注cpu和内存负载等。
服务器资源监控的报警策略一般采用设置阀值的方式进行。
几乎所有产品都会对上述资源负载进行监控，故在此不做累述。

2 进程监控

推送平台主要监控的进程有Tomcat进程、RabbitMQ进程、Redis进程、NodeJs进程等，除监测进程存活状态及CPU、内存外，监控项还包括：

• Tomcat进程：请求数、处理线程数、处理时间、JVM GC等；
• RabbitMQ进程：消息生产速度、消息消费速度、队列中堆积消息数目等；
• Redis进程：请求连接数、命中率、处理命令数等；
• NodeJS进程：GC等；

进程监控的报警策略一般采用监听进程存活状态以及设置阀值的方式进行。

3 应用级监控

应用层监控取决于服务特定业务逻辑，推送平台的应用层监控主要可以分为以下几类：

• 终端连接：接入产品各类终端的长连接数目等；
• 消息推送：接入产品的各类消息推送数/速度、实际到达各类终端的消息数/速度等；
• 接口调用：接入产品服务端和终端访问推送平台对外API的次数/响应时间等；

由于推送平台有多套部署环境，某些环境涉及上百个部署节点，且已接入数十个产品的多种终端类型，故一个监控项可能从好几个维度才能进行完整定义，且需要按照指定的一个或多个维度进行聚合。
以终端连接监控为例：

value=200,env=online,host=push2.photo.163.org,serverId=push2lxc10,platform=android,product=news.163.com

表示某一时刻连接到线上环境物理机push2.photo.163.org的LXC节点push2lxc10上的新闻产品（news.163.com）android终端长连接数目为200。 但最终监控结果可能需要按照不同的维度来显示，譬如：

• 某一个LXC节点上的Android终端长连接总数
• 某一台物理机上所有终端类型长连接总数
• 某个产品的所有终端类型长连接总数
• 某个产品的Android终端长连接总数
• ......

为此，需要对聚合维度进行定义：

Aggregation-Keys={serverId,host,env+product,env+product+platform},......

由于应用级监控和服务业务逻辑有关，所以不适合采用设置阀值的报警方式，可以考虑变化率报警方式，例如，某个产品当前时刻Android终端长连接总数比前五天同一时刻长连接总数的平均值低20%，可以认为服务存在异常，触发报警。

4 7*24自动化测试

上述应用级监控主要监测单个零散的业务逻辑功能点是否正常，没有就整个业务流程运行状况进行监控，为此可以使用机器人和实际终端7*24自动化运行完整功能测试用例，覆盖各类终端的典型应用场景。若应用场景业务流程某个环节用例测试失败，则触发报警。
推送平台现有的自动化测试用例覆盖了Android、IOS、Web、PC终端从注册、绑定到获取在线/离线消息、解绑的整个业务交互流程。

5 SLA

SLA全称服务品质协议，是服务提供者和用户之间的一个正式合同，用来保证系统服务质量，如性能、稳定性、响应速度等达到定义的品质。例如，消息推送平台的SLA部分指标为：

• 系统可用时间大于99.9%；
• 99%点对点消息到达时间<1S；
• 独立部署产品全域广播至100w用户<30S；
• Android SDK长连接心跳月流量<500k；
• ......

SLA的关键在于可测量，否则无从验证是否达到了承诺的服务质量。推送平台由于请求异步执行及移动互联网的特性，SLA测量存在一定的难度。以点对点消息到达时间为例，测量需要考虑的因素有：

• 推送平台对产品是个黑盒系统，难以从产品方获取数据；
• 推送平台作为一个高可用系统，每个组成模块都有多个节点，接入点更是多达上百个，难以覆盖所有节点和路径；
• 用户终端使用的移动网络环境存在不确定性；
• 直接在用户终端注入统计代码对流量/电量和产品体验的影响；
• 终端由于网络环境上报统计数据有丢失可能；
• ......

上述因素将导致SLA测不准而失去意义。为此，考虑采取模拟采样方案，具体描述如下：

1. 建立一个SLA专用产品域，与其他产品共用线上环境；
2. 针对每种终端类型在云主机上模拟一定数目的终端连接，终端链接数目>10*接入点数目，每个终端连接具有不同的deviceId，但模拟相同的用户账号，并以固定时间间隔主动进行重连；
3. 模拟产品服务端以固定时间间隔推送消息；
4. 统计消息推送路径各组成部分的耗时；
5. 以此域的服务质量统计数据作为SLA指标的验证依据；
6. 根据统计数据输出90%/95%/99%图表，并建立报警；

6 效果统计

上述监控措施为系统的服务质量和快速运维响应提供了较为完善的基础，但是尚无法解决接入产品最为关心的一个问题，即推送的实际效果如何。例如，一次广播有多少用户是在线收到的，在多长时间内收到的，又有多少用户是离线收到的，最终在广播TTL时间内一共成功推送给了多少用户，又如，某个产品的私信TTL时间为一周，那某天发送的私信有多少是当天就被用户收到，第二天至第七天又分别有多少被用户收到，从而为调整TTL设置提供依据等。
为此推送平台根据不同的统计需求，基于数据上报、日志输出等方式，通过BI等计算统计结果，并提供接口供产品方调用获取，以对推送效果进行评估，进而调整推送策略和内容。

网易云大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者李弈远授权发布。