云音乐WebAPM平台

kkdev163

分享大纲

平台定位、已有功能

为何这样设计

第一部分

能解决什么问题

有哪些帮助

架构演进之路

监控系统技术栈

第二部分

难点及解决思路

提供参考

后续规划

思考

第三部分

不足、该进

一、平台定位、已有功能

平台定位

• WebAPM(Web Application Performance Monitor) Web前端应用性能监控平台
• 它应该是服务于开发者的, 帮助开发者提升应用性能质量
• 它应该提供一种衡量标准，能够证明开发者不仅可以代码、工程做的漂亮，同时产出的应用也有良好的性能和用户体验
• 终极目标：Make the web more awesome. -Google

功能模块

监控手段

真实用户性能监控

实验室合成测试监控

RUM(Real User Monitor)

需要在页面上安装SDK

Lighthouse、WebpageTest

持续测试达到监控

真实用户性能监控

真实用户性能监控

用户访问数据

页面加载时性能

页面运行时性能

数据分析

访问量数据

访问量数据

访问量数据

页面加载时性能

Navigation API

页面加载时-关键指标走势

页面加载时-瀑布图

加载性能地理分布

样本分布

加载时性能数据

页面运行时性能

Longtask API

超过50ms的Task可能会影响页面帧的渲染频率

页面运行时性能-长耗时任务发生频次

页面运行时性能-单次长耗时任务持续时长

数据分析模块-基于不同维度对比

自定义埋点API

数据分析模块-开发侧关心的自定义埋点分析

实验室合成测试监控

合成测试底层使用谷歌Lighthouse

输入URL即可发起测试

等待数秒…

测试结果

原始报告

关键指标解读

资源分析

Chrome自带的审计功能

为什么Chrome已提供，还要来WebAPM平台测试？

Performance分数权重构成

宿主机网络差异

宿主机CPU繁忙程度

影响

FCP

FMP

CPU-IDLE

Interactive

Speed-Index

造成

分数波动

为什么来WebAPM平台测试更好呢？

前端发起测试

WebAPM测试流程

Lighthouse

Manager

Docker容器

…

优势一：测试的宿主环境相对稳定与一致的

Docker容器

Docker容器

HeadLess

Browser

URL

WebAPM定时测试

优势二：十分钟测试一次计算均值，减少单次测试不稳定性

WebAPM定时测试

优势三：关联上了时间维度，形成了页面性能的走势

性能优化的成果，可以很明显地体现在走势上

WebAPM定时测试

优势四：组织内页面排名

将孤立的测试结果与其他页面形成关联

正序

逆序

WebAPM定时测试

向杨老师的古典专区致敬

WebAPM 与H5搭建工具平台合作

H5搭建工具发布上线

WebAPM平台

url+运营人员邮箱

自动加入定时测试

功能模块

监控手段

真实用户性能监控

实验室合成测试监控

RUM(Real User Monitor)

需要在页面上安装SDK

Lighthouse、WebpageTest

持续测试达到监控

对比

真实用户性能监控

实验室合成测试监控

RUM(Real User Monitor)

Lighthouse

两种监控手段的优势与短板其实存在互补关系

数据的价值

参与决策

主动发起性能优化

述职、CPP材料

推动上下游优化

二、平台架构演进之路

简化模型

数据采集

服务端

上报

时序

数据库

写入

查询

查询

可视化展示

WebAPM模型

数据采集

服务端

上报

时序

数据库

写入

查询

查询

可视化展示

浏览器SDK

Node JS

Influx DB

Antd

Influx DB

什么是时序数据库？

时序数据库特点-以influx DB为例

每条记录都包含时间字段

内置基于时间的聚合函数

时序数据库特点-以influx DB为例

聚合函数-MEAN求均值

时序数据库特点-以influx DB为例

时序数据库特点-以influx DB为例

GROUP BY time()

时序数据库特点-以influx DB为例

没错，我们已经掌握了时序数据库的基本用法!

WebAPM模型

Influx DB

浏览器SDK

Node JS

上报

写入

查询

查询

Antd

Influx DB

这个监控架构我们也掌握了！

但是，我们仍然有些细节需要注意的。

现在我们要计算7天的平均值

假设是一个大流量应用且有7天有1000万条用户数据记录

❓

哨兵报警

将计算均摊到每分钟

…

…

直接计算1000万个点

每分钟

计算

计算10080个聚合后的点

60 * 24 * 7=10080

如何定时做每分钟的计算？

7天数据

Influx CQ

(Continue Query)

CQ 原理图

表A

CQ_表A

00:00:00

00:00:59

….

00:59:00

00:59:59

….

…

…

}

00:00:00

}

00:59:00

现在我们要计算7天的平均值

假如这个应用是云音乐主站吧大概1000万条记录(采样过)

WebAPM存储与计算模型

浏览器SDK

Node JS

上报

Influx DB

写入

查询

聚合查询

Antd

CQ计算

我们掌握了时序数据库的高级用法。

随着应用接入

存入的原始数据越来越多

Influx单机版内存开销越来越大

来源：influx官方文档

浏览器SDK

Node JS

上报

Influx DB

写入聚合后

查询

聚合查询

Antd Pro

聚合计算

在写入数据库前做将原始数据做聚合

只存入聚合后的数据，可缓解DB压力

我们可以直接在Node JS上

做聚合计算吗？

浏览器SDK

Node JS

上报

Influx DB

写入聚合结果

查询

聚合查询

Antd Pro

1分钟的数据窗口，聚合后存入

如果Node JS是单机部署

聚合结果写入

浏览器SDK

Node JS

Influx DB

查询

聚合查询

如何来协调 每台机器上一个窗口的数据，进行同步、进行汇总，设计将会变得复杂

Node JS

Node JS

Nginx

上报

负载均衡

Node JS 为集群部署时

如果时间窗口由1分钟变为1小时、甚至1天，Node JS会成为瓶颈

订阅原始数据

发布计算结果

聚合结果写入

浏览器SDK

Node JS

集群

Influx DB

查询

聚合查询

引入Flink来做聚合计算

Flink

消息队列

订阅计算结果

上报

发布原始数据

聚合计算

Flink在此可简单理解为做聚合计算的中间件

云音乐Flink计算平台-Magina

Source输入源、Sink输出源、Operator操作

2. Flink可以配置自定义的聚合函数，对数据的加工能力

将不受限于Influx DB内置的聚合函数。

浏览器SDK

Node JS

集群

Influx DB

写入

查询

聚合查询

引入Flink后的计算与存储模型

Flink

消息队列

上报

1. 降低了Influx DB的存储与计算压力

3. 使用Influx社区单机版前提下，更具弹性的高可用方案(消息队列)

数据采集

Server

集群

时序

数据库

写入

查询

通用的监控存储与计算模型

Flink

消息队列

上报

Grafana

Influx DB

ES(ElasticSearch)

Antd

三、未来规划

数据精细化展示

存在问题：

个别用户性能状况极差，造成性能数据波动。

后续改进：

Flink自定义聚合函数，将头尾5%极端数据剔除后求均值。

通过Lighthouse的组织内排名，我们可以比较直观了解到，自己开发页面的性能水平，与其他页面的差距等。

• 将组织内性能数据，建立性能分档，每个档位对应一个分数，计算出应用评分
• 将相同业务场景应用进行对比，如同样都是云音乐小程序、如同样都是SSR架构
• 基于业务场景，给出有针对性的优化建议

RUM性能对比

存在问题：

数据仍是以应用纬度孤立的，开发者其实比较难以知道，

自己的应用性能到底是处于什么水平，是好是差。

后续改进：

Influx-单机问题

浏览器SDK

Node JS

上报

Influx DB

写入

查询

聚合查询

Antd Pro

CQ计算

浏览器SDK

Node JS

Influx Proxy

写入

查询

聚合查询

饿了么 Influx Proxy

上报

Influx

DB

Influx

DB

可配置成数据双写, 做数据备份，以达到高可用

也可配置成数据分片，提高整个集群的存储计算能力

浏览器SDK

Node JS

写入

查询

聚合查询

杭研NTSDB

上报

真·Influx集群

总结

平台定位、已有功能

架构演进之路

后续规划

真实用户性能监控(RUM)

Lighthouse合成监控

监控技术栈

常见的难点与解决思路

精细化数据分析

应用性能对比

Influx集群

感谢

交流时间