移动端APM网络监控与优化实践

2020 年 11 月 10 日

移动端APM网络监控与优化实践

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 网络请求质量,提高问题排查效率。


本文转载自公众号爱奇艺技术产品团队(ID:iQIYI-TP)。


原文链接


移动端APM网络监控与优化实践


2020 年 11 月 10 日 14:001322

评论

发布
暂无评论
发现更多内容

【总结】设计模式

小胖子

架构师训练营 week 3

iLeGeND

架构师训练营 -Week 03 学习总结

华乐彬

通过JUnit学习模板方法模式和策略模式

破晓_dawn

架构师训练营第三课作业

曾祥斌

第三周总结

麻辣

week3 总结

Gavin

单例模式及组合模式

走过路过飞过

week03 作业

Geek_196d0f

Homework-手写单例模式

River Tree

组合模式 Homework 手写单例

架构师训练营 第三周 总结 设计模式

CR

架构师训练营第三周总结

坂田吴奇隆

极客大学架构师训练营

架构师训练营第三周【作业】

小K

架构师训练营第三周作业

+╮(╯▽╰)╭/>……

第三周架构课程作业

dj_cd

极客大学架构师训练营

架构师训练营-第三周-学习总结

sljoai

week3 作业

Gavin

Week3总结

王志祥

极客大学架构师训练营

【总结】互联网架构模式

小胖子

第三章作业

小胖子

架构师课程 --week 3-- 课后作业

莫莫大人

极客大学架构师训练营

第三周作业

考尔菲德

week03 小结

Geek_196d0f

第三周总结

changtai

极客大学架构师训练营

架构-面向对象的设计模式-总结

架构5班杨娟Jessie

极客大学架构师训练营

第三周作业

麻辣

架构-第三周作业-设计模式

架构5班杨娟Jessie

极客大学架构师训练营

架构师训练营 第三周【学习总结】

小K

架构师训练营总结 -3

River Tree

极客大学架构师训练营 学习总结

架构师训练营第三章作业

JUN

架构师训练营第三章总结

JUN

移动端APM网络监控与优化实践-InfoQ