查看原文
其他

移动端APM网络监控与优化方案

The following article is from 爱奇艺技术产品团队 Author 移动架构团队


01 背景

企业为了能够提升线上服务的可靠性和竞争力,需要从代码端的视角来监控自己线上应用的质量和性能,因此,APM系统(应用性能监控系统)应运而生。APM系统是互联网公司最重要的基础设施之一,它可以帮助发现并解决生产环境中遇到的各种问题。


APM系统为了能够实现帮助企业确保自身的IT支撑系统高效地运行,它需要建立一个强大的IT运维管理体系,用来时刻监控IT环境各组件的性能和质量,并且通过多维度实时分析监控指标的异常,快速定位并解决线上应用的问题。其中,网络环境质量是线上服务最基本的性能指标之一,网络耗时,网络请求错误率等指标极大地影响着线上应用的服务质量,APM系统应系统地建立起网络性能的监控。


在爱奇艺移动端APM系统上线之前,网络监控只是针对后端服务,因用户手机性能和网络环境复杂性相关,用户的真实使用体验和后台服务监控之间存在很大差异。因此,我们建立了一套基于用户层面的、实时、多维度的网络监控系统,并建立了针对端上的错误率、劫持率和网络性能的评估标准。经过多年的积累,爱奇艺移动端APM系统已经建立包括崩溃、网络、卡顿、日志、内存、图片等多项监控功能。


本文主要介绍移动端网络监控系统的建立及优化。


02 系统设计

根据移动端网络错误的特点,计算错误率时,将其划分为三类:

网络层错误

(错误发生在三次握手,SSL校验,数据传输过程中,如ConnectException)

HTTP响应错误

(服务端已明确返回错误码,如404)

解析错误

(服务端返回200,但数据格式有问题,导致前端无法正确解析)


由于重试机制的存在,我们只按照一组数据中的最后一次请求的结果,评判该次用户网络行为成功或者失败。


维度信息设计:

在后端存储的字段里,除了上述网络字段,还包括APM平台和用户设备的基础字段信息,这里就不一一赘述。


2.1 SDK设计

因端上网络请求频繁,数据采样需要考虑对手机性能影响的同时,也要保证数据的准确可分析,采样有如下措施可参考:

  ·  云控采样:云控下发采样指令,动态控制数据量;

  ·  合并压缩:缓存数据在达到时间或者数量的阈值时,进行批量压缩投递;

  ·  失败重投:投递失败的数据,会进行本地存储,下次启动尝试投递。


由于数据投递可能滞后,分析时可使用:端上发生时间和投递到达后端时间,利用两个时间戳分别进行分析。


2.2 后端设计

在后端系统设计中,需要支持高数据实时性、较大的存储数据量、灵活的查询和准确及时的报警。具体措施有:

  ·  实时性:秒级别

  ·  存储:支持千万级别数据量的搜索,聚合,TOP等

  ·  报警:分钟级别多维度报警, 通过邮件、短信、热聊、电话等形式通知责任人。


2.3 Web设计

Web展现错误率监控时,主要考虑是:

1. 快速查看整体状态

2. 查看所有业务错误数/错误率/请求数的top列表

3. 可分析具体原因


基于上述三个基本出发点,我们设计了首页,错误分布,占比详情,详情信息,耗时分析,劫持分析等页面


排查问题时,如果错误码集中,可以判断具体错误类型; 如果服务IP集中,可以判断出问题的服务器信息。


03 优化

网络监控和标准建立完成后,为了降低了网络错误率、劫持率和请求耗时等问题,又引入一些优化方案。


3.1 DNS优化

在HTTP协议里,DNS作用是解析出正确的IP地址,网络请求首先进行DNS解析,然后根据IP进行后续流程,所以,DNS的优化很关键。DNS优化主要从以下几个点考虑:

DNS劫持:在移动请求里,劫持指的是运营商DNS服务器被攻击,域名解析时返回了错误的IP地址,导致请求失败。

DNS TTL过长:TTL时间过长,可能导致两个问题:

1. 正常下线了某些服务器,运营商可能长时间未更新缓存。
2. 后台服务故障,需要及时更新服务器列表。

跨运营商:跨运营商可能导致访问慢。

LocalDNS获取失败:在网络较差或者特殊情况下,获取失败或者时间过长。


3.1.1 三层缓存

建立内存+网络请求+本地持久化的三层缓存机制。缓存都设置有一定的时效,内存缓存过期,使用网络请求;网络不通时,会使用本地的持久化缓存。

好处在于:

1. 快速获取域名DNS解析信息。

2. 网络较差或者获取LocalDNS失败时,可以从本地获取结果,进行尝试。

3. 可记录上次请求时,成功的IP,会记录其成功率和性能数据,下次重建连接,优先使用上次成功率较高,性能较好的IP。


3.1.2 HTTPDNS

HTTPDNS是业内比较完善DNS优化方案,通过HTTPS请求,主动去自己的基础平台拉取域名对应的IP信息,好处也显而易见。


防劫持:由于接口存在于自己后台,不存在运营商劫持问题。

高时效:如果后台服务IP有更新,可以立刻更新上线,解决了运营商TTL问题。

结果最优:HTTPDNS可以根据当前后台服务状况,选择最优的IP排序返回。

上线后,观察到劫持率下降了80%。

在使用HTTPDNS时,设计了降级方案,如果HTTPDNS不可用,会降级为LocalDNS,在时效性方面,设计有超时机制,并且在网络环境改变时,会主动更新。


3.2 弱网优化

移动端上网络环境复杂,用户随时可能处于弱网环境下,为了保证用户体验,需要在弱网环境下进行特殊优化。


3.2.1 弱网模型

首先,需要进行弱网判断,甄别出用户当前所处的网络状况。


计算标准:

网络流畅分级模型,参考了多个维度数据,包括上行/下行网速、请求失败率、网络延迟等。针对不同维度的因素,设置不同的阈值,综合多个网络因素等级,最终确认整体网络等级。目前策略里,只要有一个因素落在VERY_POOR,POOR区间,就认为是弱网环境。


等级划分:

根据网速值,划分为六个等级,网络状态会投递至后端,判断时,在value<=1,表示弱网。


3.2.2 弱网优化

在建立好弱网模型后,我们又进行了一系列的优化,包括:

Brotli压缩:Brotli相对Gzip压缩效率提高17-25%,不过由于其更耗服务端资源,前后台约定,会在弱网下使用Brotli压缩。

减小并发:网络库中,存在网络请求线程池,弱网下,减小并发数。

建立优先级:重要域名使用优先级更高线程池处理。

减少响应数据:对返回数据大小进行缩减,比如,页面相关的,减少分页数,减少card数。


3.3 网关方案

网关方案——通过后台一个中转服务,分发请求,端上所有请求都复用现有的长连接,相当于间接实现了域名收敛。


相对正常HTTP请求,其优势有:

1. 多域名连接共享,实现0RTT多路复用。

2. 避免了DNS解析,防止DNS劫持。

3. protobuf编码私有协议,节省流量。


在一个接口上A/B实验的结果看,平均请求耗时从595ms降低至371ms,成功率也有所提升。


网络架构图:

3.4 超级管道兜底

这是爱奇艺自研的一种基于HTTP/HTTPS IP直连的低成本高通用性的业务代理服务。能够赋予业务异地多活功能。

前端:通过一个统一的域名进行请求,使用该服务的请求,可以将其请求信息,作为参数拼接在统一的请求里。

后端:通过中转服务,将不同的请求分发,并且,会进行异地容灾分发,减小单个地区服务器故障造成的影响。


在一次线上故障中,使用超级管道的接口错误率是3.95%,未使用超级管道的错误率高达28.96%。


3.5 合理重试

对于用户而言,需要最终的成功结果,所以,请求失败后,内部进行重试是十分有必要的,合理的重试,可以有效降低错误率。

我们使用的重试策略有:

原样重试:业务方可配置重试次数,防止网络波动引起的请求失败。

HTTPS降级重试:如HTTPS降级为HTTP重试,防止SSLException导致的请求失败。

HTTP2.0降级重试:网络状况较好时,HTTP2.0多路复用,带来了性能上的优势,但在网络不稳定时,HTTP1.1错误率低于HTTP2.0。

IP直连重试:直接进行IP直连,防止域名解析导致的错误。

超级管道重试:利用超级管道,进行兜底重试,进行异地容灾,防止单个机房故障导致服务中断。


3.6 其他

竞速连接:对于重要域名,使用TCP连接进行测试,选择最优的IP。

TLS1.3:TLS1.3相较之前版本,由2RTT降低为1RTT,降低了SSL握手失败的概率。

连接优化:预建连接,连接重建,备用/复用连接。


04 成果

错误率下降趋势显著

爱奇艺APP的网络错误率,随着版本的持续优化,Android端错误率从最初5.3%,目前稳定在0.48%; IOS端错误率从最初4.63%,目前稳定在0.35%。


05 结尾

网络监控系统上线后,已在爱奇艺APP各端,随刻、电影票、奇秀等独立APP落地。经过多个部门的合作,使爱奇艺APP的网络错误率有了较大幅度下降,并建立了网络性能监控体系,为爱奇艺APP网络服务质量保驾护航。


网络监控解决了APP整体网络请求质量的监控问题,对于单个业务网络请求质量监控的问题,又引入了全链路监控,网络诊断,日志聚合等功能,同时和用户反馈平台打通,方便排查单用户反馈的问题。后续会继续完善全链路监控,以及引入QUIC等其他方案,优化爱奇艺APP网络请求质量,提高问题排查效率。


参考阅读:



技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构
改变互联网的构建方式

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存