移动端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网络监控与优化实践