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

本文来自网易云社区

做者：李弈远

消息推送平台现已为几十个产品提供推送服务，同时在线用户链接数超过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

本文来自网易云社区，经做者李弈远受权发布。

相关文章：
【推荐】 30分钟，让你完全明白Promise原理