演讲场所: 网易-组内分享

演讲简介: 本次演讲介绍网易云音乐一站式研发平台 Febase 的工程设计与实现。

演讲时间: 2022-06-09

演讲逐字稿

0. 开场词​

大家好，我是 kkdev163，今天为大家带来的分享主题是《Febase 的工程设计与实现》。

大家在日常的开发过程中，或多或少都有使用过 Febase。那你是否对平台的技术实现有过好奇呢？

这次分享，我就为大家揭开 Febase 背后的技术实现，是怎样一个技术架构，驱动了 Febase 平台的 持续迭代 和 扩展。希望能为大家带来一些 启发、思考。

1. 大纲​

本次分享会分为 5 个部分..

一.引言 (Febase 产品简介)​

• Febase 是一站式的研发平台，覆盖了从工程初始化到线上监控的研发生命周期。
• 上线部署阶段，Febase 提供了一致性的部署体验，如今在一个平台，我们就可以完成 多应用类型的发布
• Febase 还提供了上线流程管控，帮助研发团队养成规范的代码上线流程。
• Febase 还通过 OpenApi 的方式，向第三方平台暴露 应用模型 与 全部底层能力。

二.Febase 的多应用类型部署​

由简化到复杂，抽象到具体，从一种 应用类型 到 多种应用类型 的部署

Febase 作为一个研发平台，最核心的功能点是 部署。我们首先来思考下，当我们设计一个部署平台时，最小可行产品(MVP) 是什么？

我的理解是: 这个产品可以将远程仓库代码 clone 下来，构建出线上产物，最后提供出该产物的可访问链接。

当从一个 MVP 扩展到一个 生产环境 可用的服务时，整体架构会有哪些不同？

我以静态部署平台 SDP 为例，展开介绍下:

• SDP 需要提供一个可视化的部署平台，方便开发者配置应用部署的元信息
• 如 应用名、Git 仓库、访问路由等
• 在开发者触发构建时，管理后台会调用 构建服务，触发构建流水线
• 在构建完成后，通知 产物托管服务 下载产物，并存储在 磁盘中。
• 在产物托管完成后，管理后台会通知网关 更新路由信息。
• 之后用户就可以通过 公网链接，请求到 网关
• 最后由 网关 解析路由，读取静态资源

虽然最小可行产品 MVP 很简洁，但我们看到 静态部署平台 需要分别起了 4 个服务，将静态资源托管这件事做到极致。这套架构支撑起了 云音乐庞大的 静态 Web 业务 和 RN 业务。

在 Febase 中，我们并没有重复造一套轮子，而是通过将 SDP 的部署能力下沉，提供出静态部署的原子能力。类似的 Alpaca 平台，提供了容器部署原子能力。这些部署能力，成为了我们打造 Febase 多应用类型部署的基础。

在接入 SDP、Alpaca，甚至未来更多的部署能力时，我们是如何确保整体架构的 可维护性 与 可扩展性的呢？

首先我们为部署能力，定义了一个统一的适配器抽象， 称其为 DeployProvider。在其上定义了公共的抽象方法。

在对接具体的应用类型时，适配器需要实现这个接口, 如静态 Web 类型，在实现时，会调用 sdpRpc 方法实现具体发布逻辑。 容器类型，在实现时，会调用 alpacaRpc 方法实现具体的发布逻辑。

有了这一层抽象和实现后，我们就可以为不同的应用类型部署，提供统一的 Service 和 Controller 接口。在接口内部，我们根据应用类型，选择对应的适配器做发布。

我再通过一个示意图来复述下:

• 在 Node 服务层的后端，抽象出了 DeployProvider 接口
• 针对不同的应用类型，实现适配器
• 对前端我们可以暴露，统一的部署方法。
• 通过这个方式，我们解决了不同应用类型的 部署能力实现差异的问题。
• 并且在未来，新增部署类型时，我们只需以插件的方式新增一个 xProvider，就可以引入该部署能力。

三. Febase 的流程管控设计​

• 在 Febase 中，我们希望能规范应用的上线步骤，规避多人开发场景下的分支冲突。
• 同时我们也需要为不同应用类型，提供上线步骤的定制能力。

为此我们在 Febase 中引入了 发布流程 的概念。

一个发布分支，需要走完 「开发」、「卡点」、「上线」等阶段的验证才能被合并入主干。

在引入发布流程时，我们首先要解决的是流程如何管理的问题:

1. 每个流程需要以一定的方式定义，并被计算机程序读取。
2. 流程当前所处的节点，需要被持久化存储。
3. 流程可以以 串行、并行 的方式 向前推进、也可以回退到前置的节点。

为了完成上述对流程的管理，最朴素的方式是，我们可以选择在业务代码中，手动处理流程状态，但是随着 业务复杂度 的提升，流程状态的管理 与 业务逻辑 相耦合，将会使得项目变得难以维护 和 扩展。

为了简化对流程的管理。业界沉淀了一套流程状态管理工具称为「流程引擎」。这套工具就好像前端的视图层框架，我们只需要专注于业务逻辑的编写，DOM 的操作更新就交由框架来处理。大大降低前端开发的复杂度，提升项目的可维护性。

在计划引入「流程引擎」时，我们调研了市面上==的开源产==品，最终选择了自研「流程引擎」，我们的「流程引擎」除了满足常规的流程状态管理外，还有以下几点特色:

1. JS 生态，对前端开发者友好。
2. 提供前端套件，流程状态管理可驱动前端视图变更。
3. 覆盖常见的编排需求，整体复杂度可控，最适合 Febase。

我们来看下自研的「流程引擎」 在 Febase 中的具体使用吧。

在 packages/server/app/workflow/definition 目录中，会定义不同应用类型的流程

└── definition
    ├── caas-0.0.1
    │   ├── fn
    │   └── index.ts
    ├── graphql-0.0.1
    │   ├── fn
    │   └── index.ts
    ├── graphql-0.0.2
    │   ├── fn
    │   └── index.ts
    ├── node-0.0.1
    │   ├── fn
    │   └── index.ts
    ├── node-0.0.2
    │   ├── fn
    │   └── index.ts
    ├── react-native-0.0.1
    │   ├── fn
    │   └── index.ts
    ├── react-native-0.0.2
    │   ├── fn
    │   └── index.ts
    ├── web-0.0.1
    │   ├── fn
    │   └── index.ts
    └── web-0.0.2
        ├── fn
        └── index.ts

打开 web-0.0.2/index.ts

endpoint 指明在流程推进到该节点时需要执行的函数。我们可以在该函数中执行该节点初始化对应的业务逻辑 并根据业务逻辑执行结果 返回相应的 节点流程状态。

以 review 节点为例，在节点初始化时...

我们再来看 complete 节点...

不同应用类型的流程编排和相应的业务处理逻辑，我们是在后端中定义。我们再来看下前端视图部分的映射。

packages/web/src/workflow/definition 中定义不同应用类型的流程视图映射

引擎会为绑定的 Overview 组件 和 节点组件 传入流程状态信息，供渲染使用，并为组件暴露触发流程状态变更的 dispatch 函数，供前端视图层调用。

通过声明式的代码，我们将 流程编排好了 并对视图做了绑定。 在发布详情页，我们只需使用 useWorkflow 方法传入 流程 ID，引擎就会为我们提供出对应的流程组件，并在流程状态变化时，驱动对应节点视图的渲染。

通过自研的流程引擎，我们将 流程状态管理 与 具体的业务逻辑 解耦，并通过 流程引擎 驱动前端视图的变更，以此降低了业务逻辑开发的复杂度，且在未来引入新应用类型时具有良好的扩展性。

四. OpenAPI 网关的设计​

Febase 的后端，不仅需要面向 Febase 管理后台前端提供接口。 同时还要向 第三方平台，如 Overmind、低代码平台 还有 CLI 工具，如 Mug 等提供开放接口。 过去我们搭建公技产品时的做法是，面向管理后台前端使用 Cookie 登录认证。 对第三方平台，使用特殊请求头。 通过白名单的方式，来指定开放接口 然后在每个业务逻辑实现中，根据 请求来源，单独地做 权限校验。 过去这种 职责不单一、面向过程式的鉴权方式，将会导致 难以维护 和 扩展，无法承载 Febase 开放平台的全部底层能力的目标。

我们的做法是抽取出了 单独的 OpenAPI 网关层。

在后端的接口中，用声明式的方式，描述接口所需的 最低权限。 在应用启动时，会收集全部的路由+权限声明，并存入数据库中。 并将 路由与权限信息注册至网关。 由于路由与权限信息都做了入库，所以也可以在管理后台中，对接口的权限做配置管理。 对于多消费场景，统一使用 Febase 派发的 用户 Token 进行认证和鉴权。 只有满足权限要求的请求，才会打到 Febase 后端。 这么做的好处是

• 声明式的鉴权配置
• 多消费场景的统一认证机制
• 与 业务逻辑层的职责单一

以此达到架构的可扩展和易维护。

介绍完多个模块的设计实现后，我们再来看下 Febase 的主体架构​

介绍完主体的架构后，我们介绍下 Febase 引入 GraphQL 应用类型的步骤。

由于可扩展性的架构设计，Febase 工程引入 GraphQL 部署流程，就像增加一个新插件一样，不会污染已有应用的业务逻辑，也不会增加整体工程的复杂度，使得整体架构保持良好的可维护性。

四.未来展望​

介绍未来将 Febase 向集团内推广，我们需要做哪些努力？ 如底层部署的 租户隔离 、 域名定制 等

自动创建 曙光 埋点应用

演讲场所: 网易-组内分享

演讲简介: 介绍了微信聊天机器人, 包括

• 什么是聊天机器人
• Wechaty Demo 、API
• PadLocal 实现初探

演讲时间: 2021-12-06

演讲场所: 网易-音乐事业部-技术沙龙

演讲简介: 刚刚过去的 GMTC 大会，是技术界的一次盛宴，大前端技术部派出代表北上取经。本次演讲介绍业界公司在前端线上质量保障方向的探索与实践。

演讲时间: 2021-07-13

演讲逐字稿

前言​

大家好，我是 kkdev163，今天为大家带来的分享是 GMTC 前端质量保障专题。

本次分享的议题基于 「快手-前端监控体系建设」、「蚂蚁-前端灰度监控与变更防御」

这里加个免责声明：本分享的全部素材取自以上议题。

一.快手​

首先我们来看 「快手的前端体系建设」，原分享主要分为三块：

• 1 监控指标定义
• 2 快速分析定位原因
• 3 监控平台的搭建和稳定性保障

由于时间的关系，第三部分我们不作展开。

1.1 监控指标定义​

首先来看快手的 页面性能监控指标定义。

从页面请求开始 到 页面加载完毕的时间线上，有多个关键的时间节点。。快手提出 如果我们只能用一个指标来代表前端页面性能，应该用哪个呢？

快手排除了

• Load, 由于他在长页面下 不能很好地反应用户体感
• First Paint，骨架屏下，他无法体现页面核心内容渲染时间
• FMP，他没有标准的实现
• LCP, 最大元素不一定是最重要的元素，并且该指标的浏览器兼容性还不太高。

最终快手给出的方案是 自定义 FMP, 快手对该指标的定义是在 API 数据渲染到 DOM 后的时间。

在分享中，讲师提到 自定义 FMP 指标的采集 有 SDK 自动采集 和 开发人员手动上报 两种途径，但目前 SDK 自动采集的 算法有效性还有待验证，所以目前快手主要还是依赖开发人员的手动埋点。

除了页面加载耗时，快手也针对其核心的业务场景，视频播放、视频直播，设计了专门的监控指标。如：

• 播放失败率
• 启播耗时
• 百秒卡顿率

同时快手也提出，作为前端开发者，我们也需要去关注 H5 容器的监控数据。。讲师举了个案例，有用户反馈一个页面很慢，然后开发者把 页面完全加载时间从 6.5 秒 降低至 4.5 秒，有了很大的提升，但用户的实际感受，还是很慢。。为什么呢？

分析下来后发现，原来从 点击 H5 入口 到真正开始加载 H5 页面，中间有一个 5.9 的秒的 Webview 启动时间。如果把 Webview 加载过程放大，会发现有

创建 Webview、注入 JS 桥、注入 Cookie 等环节。。所以如果我们只关注纯前端部分，而忽略 H5 容器的开销，我们监控到的性能其实是与 用户感受有较大偏差的。

所以快手针对容器，也设计了一系列完善的监控指标。

1.2 快速定位问题​

在完善了监控指标的采集以后，快手又是如何帮助开发者快速定位问题？

快手提出了 数据归因 诊断能力

简单来说，快手会先建立指标的 依赖树，比如 自定义 FMP, 他可能会受

• tcp 建连时间
• 网络传输时间
• api 加载耗时

等等 原子指标 的影响。

在 FMP 波动了 10% 的情况下，会根据每个 原子指标 的波动率，进行归因，计算每个波动因子的贡献度，最后选出 Top3 的贡献因子。

这张截图展示了，在 FMP 波动后，给出的智能归因。

除了数据归因诊断能力，快手也做了 访问级别 的请求还原，给到一个 userId，就能查出 详细的 访问情况，接到客诉的时候，就能快速排查出，他为什么慢。

1.3 总结​

• 快手建立了以 FMP 为主的 前端度量指标体系
• 并且通过智能数据归因、访问级别的请求还原，来帮助开发者快速定位问题。

二.蚂蚁​

接着我们来看蚂蚁的灰度监控与变更防御。内容主要分为两块：

• 建立前端灰度监控体系
• 基于灰度监控的发布变更防御

2.1 灰度监控​

这里的关键词是 灰度监控，我们先来看下什么是 灰度发布。

蓝绿发布简单来说，就是在 新版本 准备完成后，一次性将流量全部切换至新版本。

而灰度发布简单来说，可以选择为 部分的用户 提供 新版本 进行线上灰度验证，待验证无误后，逐步扩大灰度比例，直至 100%。

对于不同的应用类型，实现灰度发布的方案都有不同的区别。

以 支付宝官方小程序 的灰度为例。

当用户访问支付宝客户端时，根据灰度决策，会判断 当前用户是否进入 灰度池子，如果是的话，就拉取灰度小程序包，没有的话，就拉取 正式包。

这样的灰度发布看起来很完美啊，那支付宝遇到了什么问题呢？

讲师提到，在灰度变更的过程中，线上和灰度数据混在一起，监控无法感知应用当前正在灰度。。开发者想象中，在迭代发布后，会有明显的指标变动趋势，但实际的指标变化却是这样。

所以 开发者并不知道，灰度过程中，到底发生了什么，同时也不知道，这个版本对比线上正式包，情况到底如何。

也就让这个发布过程没有安全感，同事变更相关的故障率极高。

为了解决这个问题，支付宝建立了 前端灰度监控体系。。从流程上来看，在构建阶段，自动注入 此次迭代的标识，在用户访问时，使用 迭代标识 去 初始化监控，最后在监控数据上报时，携带上 迭代标识。

在数据做 清洗 的时候，把 迭代标识 作为顶层的维度进行聚合。这样就可以得出不同迭代版本的 数据。

在平台上就可以精确地区分出 此处迭代 引起的数据变化。

• 不同灰度版本 的流量占比
• 以及不同版本下的错误数

2.2 基于灰度监控的发布变更防御​

当蚂蚁建立起 灰度监控 后，蚂蚁进一步又做了发布变更防御。

我们来看下整体的流程：

在进入灰度前，会有一个前置的校验卡点，如果没有通过会直接终止发布，通过后，会开始向客户端下发灰度策略 比如 5%，在灰度策略下发后，会有一个灰度后置校验，如果验证成功，会进一步扩大灰度比例，如果失败，就立即终止发布。

我们可以看到，这里的关键节点是 灰度后置校验。我们来看下蚂蚁到底

• 要进行哪些验证？
• 又要对哪些指标做验证？
• 这些验证又是如何保障灰度发布的？

进行哪些验证​

平台希望用户去关心

• 灰度有没有充分
• 有没有把应用、页面、小程序搞挂
• 有没有引入新的异常
• 异常相比于线上有没有增多

为此建立了

• 灰度流量
• 新增异常
• 异常率等指标

有了这些验证 和 指标，又是如何保障灰度发布的呢？

• 1. 当设置 5 % 的灰度比例，为了保证充分灰度，则要求当前迭代标识的流量必须接近全量的 5% 才能进入下一个灰度梯度。
• 2. 在每个异常出现时，系统会记录 该异常的首次出现时间、首次出现迭代，若判断出，该异常是此次迭代中引入，则拦截此次发布。
• 3. 计算出 此处灰度的 异常率，若明显高于基线版本，则触发拦截。

总结下:

• 蚂蚁通过 监控数据 与 发布流程结合，建立起了 发布变更防御体系。为用户带来了发布安全感、也让监控数据发挥出更大的价值。

演讲场所: 网易-集团前端沙龙

演讲简介: 本次分享主要围绕谷歌最新提出的谷歌体验度量指标集-Web Vitals, 包含:

• 该指标集提出的背景、含义、计算原理，并对围绕该指标集的谷歌系产品做简要介绍。
• 最后会介绍当前云音乐前端监控平台对该指标集的跟进情况和用户最佳实践等。

演讲时间: 2020-10-21

演讲逐字稿

主题介绍​

大家好，我是来自云音乐的 kkdev163，在云音乐主要从事前端监控平台建设相关的工作。本次分享为大家带来的主题是《谷歌体验度量指标集 Web Vitals》。

本次主要分为四个部分：...

背景​

云音乐在 19 年的时候上线了前端监控平台，我们通过部署平台自动接入 SDK， 采集用户端的一些性能数据，并在平台上做可视化展示。

同时我们也基于 Lighthouse 搭建了一套实验室环境的性能度量体系。

结合二者，我们做了一个体验基线，在全体同事的努力下，云音乐整体的评分和通过率有了一些提升。

但在运作的过程中，我们也收到了一些反馈：

1. 实验室环境指标项很多，开发者有一定的认知成本
2. 实验室环境指标 与 真实用户侧指标 不一致，在做优化时，难以对齐。
3. 真实用户侧指标 domReady、load 等 虽然可以评估页面加载的快慢，但与用户肉眼所见的页面渲染，并不能直接关联。

谷歌在今年提出了 Web Vitals，云音乐及时做了跟进和落地，他在一定程度上解决了我们的痛点，那么我们来看下， Web Vitals 是什么，他为什么能解决我们的问题？

概要​

Web Vitals 是谷歌提出的一组用来衡量 用户体验 的 度量指标集。

它包含了左侧,与用户体验直接关联的核心指标，以及右侧的一些辅助指标。

绿色核心指标是我们今天要重点展开介绍的。

核心指标集主要用来度量用户体验中的三个方面：

• 1. 加载时性能
• 2. 可交互性
• 3. 视觉稳定性

分别用 LCP、FID、CLS 三个指标来衡量，并且谷歌也基于 Chrome 的用户数据，将每个指标划分为三档：

• 较好
• 有待提高
• 较差

核心指标集将页面的健康程度最终只落到于这三项指标上，聚焦于这三项指标展开优化，就能在很大程度上解决体验问题。

接来下，我们来详细的介绍这三个指标项：

LCP​

LCP 指标的含义​

LCP 最大内容渲染时间，是指当前视窗(viewport)中的最大内容元素的渲染时间。

在用户体验中，他被用来衡量页面的加载时性能。通常来说，视窗中最大的内容区块，是网页设计者最希望为用户传递的内容，而这部分关键内容的加载快慢，直接影响了用户的体验。

衡量的标准​

谷歌给出的建议是 LCP 需要控制在 2.5 秒 内，如果超出了 4 秒，对于用户来说，体检就会较差。

为了我们后续更好地展开优化，我们来了解下 LCP 的判定规则。首先我们来看下哪些元素的渲染可能会被判定为 LCP。

哪些元素会包含在内​

• <img> 图片元素
• <svg> 中的 <image> 元素
• <video> 元素中的 poster image
• background-image: url() 使用背景图的元素
• 包含文字节点的块级(block-level)元素

如何判定元素大小​

对 LCP 来说，一个元素的大小，仅仅只包含，当前视窗内可见的部分。如果一个元素，有部分内容超出了当前视窗或者是有不可见的 overflow, 只会计算可见部分的大小。

对于图片元素的判定，是结合图片自身的大小与屏幕上渲染的大小，取二者中较小的值。

对于包含文字的块级节点，只计算包裹所有文字节点的最小矩形面积。

Demo 演示​

介绍完了 LCP 的计算原理后，我们来看一个 Demo 演示，在页面加载过程中，在 2000ms 时页面加载了骨架屏，由于不包含我们上面提到的元素，所以没有 LCP 产生；在 2400 毫秒时，加载出了文字节点，此时浏览器会抛出一个 Performance 信息对象，包含当前的 LCP 元素 和 渲染时间。随着加载的继续，在 3000 ms 和 4500 ms 分别会抛出新的 信息对象。

随着页面的加载，浏览器会持续抛出 LCP 对象，直到用户开始交互(点击、滚动、按键等)为止。该页面最终的 LCP 值是 4500ms。

由于超出了 4 秒，所以是属于较差的 LCP

哪些因素会影响 LCP​

• 请求 html 时的服务器响应时间
• 阻塞渲染的 CSS、JavaScript
• 资源加载时间
• 客户端渲染 (Client-side rending)

LCP 虽然只是衡量了最大内容元素的渲染时间，但是该元素的渲染却与整个页面的请求加载链路有关，所以优化 LCP 需要综合地从以上 4 个影响方面出发。

FID​

FID 用户首次输入的延迟。

我们经常会看到一些页面，在加载初期，对于用户的交互，有些响应延迟。这主要是由于页面在加载初期，虽然渲染出了部分元素，但主线程仍然处于繁忙状态，无法及时地响应事件处理器，从而让用户感知到明显的延迟。

根据谷歌的建议，这个延时如果能控制在 100 毫秒 内，会有比较好的可交互体验，如果超出了 300 毫秒，用户的可交互体验就会较差。

FID 计算演示​

我们通过一个例子来更好的理解 FID。

页面加载初期，屏幕上渲染出了按钮，并且正在努力地计算骨架区块内容，浏览器的主线程处于繁忙状态。

如果在这个时候用户点击了按钮，浏览器是没有办法马上响应的。

它需要等到骨架区块计算渲染完成，处于空闲状态后，才会去响应点击事件的处理器，并产生一些 UI 变更。

在整个过程中 FID 计算的是，从用户点击到主线程首次空闲，有能力去处理事件响应器的时间。

而事件处理器本身的执行耗时，和由此可能产生的 UI 变更并不会记录在 FID 内。

从这个例子，我们也可以看出，FID 的值与用户在什么时候进行交互有很大关系，如果用户是等到浏览器完全空闲后在交互，那 FID 就会很小。。所以在数据呈现上，我们会使用分布图，来查看用户 FID 的分布。

有哪些事件会被记录为 FID ？​

FID 主要发生于用户输入的独立事件 如 点击、键盘输入等

滚动、缩放等连续事件，不会记录在内。

如果没有绑定事件处理器？​

FID 记录的是 收到用户输入事件 到 下一次浏览器处于空闲状态的 时间差。所以即使没有绑定事件处理器，FID 也能够被准确测量出来。

这样设计的目的，也是因为有些交互元素并不直接依赖于事件处理器，但是需要主线程处于空闲状态才能正常地响应，如：

• Checkboxes, radio buttons，and Text fields(<input>, <textarea>)
• 选择器的下拉菜单(<select>)
• 链接 <a>

影响 FID 的主要因素​

导致 FID 的主要原因是 页面加载过程中 解析和执行了太重的 JavaScript, 导致主线程繁忙。

优化的思路有：

1. 减小 JS 文件体积（Code-splitting、延迟加载）
2. 减少主线程执行开销 (拆分 Long Tasks、异步执行、web worker)

CLS​

我们最后来介绍 CLS ，累计布局偏移。 我们经常会发现一些页面，存在视觉抖动的情况，主要的原因是发生了布局的偏移。

该指标，可以用来衡量用户体验中的视觉稳定性。

谷歌给出的评估标准是 < 0.1，与之前指标不一样，他是一个分数，我们需要来看下，它是如何计算的？这样才能更好地帮助我们理解，布局偏移在我们页面上产生的影响面。

首先他的计算公式是 影响面积分数 * 距离分数

• 影响面积分数指的是，布局移动前后求并集的面积占整个视窗的比例，在这个的例子中，是 1/2
• 距离分数指的是，这次偏移的最大距离 占 整个视窗长边的比例，在这个例子中，是 1/4

所以在这个例子中，布局位移评分为 0.5 * 0.25 = 0.125。

参考这个例子，了解了计算方式后，相信大家对 0.1 的布局偏移能产生多大的影响面，应该是有了直观的感受。

CLS 影响因素​

1. 图片 size 属性
2. 不要在已渲染的元素上方插入新元素
3. 使用 trasmform 动画

谷歌系工具简介​

在了解完了核心指标的定义、计算原理 常见的影响因素后，我们来看下，在日常的开发过程种，如何去使用这三个指标，帮助我们优化用户体验。

展开介绍本地端工具...

这几个工具是我们在开发阶段，可以本地使用的，那有没有办法采集用户端的数据呢？谷歌提供了用户体验报告 API，和可视化的产品。。

展开介绍用户端分析工具...

以上的用户端数据，依赖于 Chrome 的数据采集，并且维度也比较单一，我们只能查到像 music.163.com 主域名的数据，对于更细分的页面，往往是查不到数据的。

所以为了支持更精细化的数据采集，谷歌也为我们提供了 web-vitals npm 包，通过这个包，我们可以方便地采集用户端的数据。

云音乐实践​

在云音乐，我们将 npm 包整合到了现有的 sdk 中，采集并呈现了核心指标的视图。

对于核心指标，我们是根据谷歌的建议，将 75% 的用户 是否通过好的标准，设为达标线。以 LCP 为例，好的标准是 2.5 秒，该页面在 2.5 秒内的用户占比只有 74%，所以 LCP 指标未达标。

通过这个看板，我们能直观地了解到，我们的页面在用户端的真实体验占比如何。

由于这几个指标是依赖于 Chrome 浏览器的 API, 相信也有不少同学，会担心指标的的兼容性如何？

我们通过一段时间的数据采集，发现随着用户设备的更新，我们采集的覆盖率也在逐步的上升，云音乐的某个应用已经达到了 39% 的用户覆盖率。

同时在实验室侧，我们也将 Lighthouse 升级到了 6.0 版本，在 6.0 下会提供 核心指标值，并提供针对核心指标的优化建议。

通过这次平台的升级更新，解决了我们一开始提到的痛点。。

• 我们的开发者只需要重点关注 核心指标集
• 用户侧 与 实验室侧 有了相同的指标进行验证性能
• 用户侧的性能，可以使用与用户体验直接相关的指标体现，我们是站在用户视角，评估最终肉眼所见的渲染快慢，与中间使用到的前端技术方案无关。

通过这次升级，我们也发现了一些新的问题，比如在使用 核心指标 的评估体系下，我们整体的平均分，有了大幅的下降。。这说明，我们的页面可以在新的评估标准下，有进一步优化的空间。

比如我们的某个页面，此前长期霸榜，但在新的评估体系下，在真实用户侧 和 实验室侧都暴露出了新的体验问题。如存在 LCP 值过大，存在 CLS 等。

在平台更新了 WebVitals 后，我们现在推荐的使用方式是这样的：念 PPT

这里打个小广告，WAPM 平台是支持 网易集团内部应用接入的，如果有其他事业部的同学想使用 的话，也可以加下 POPO 交流群。

最后我作个简短的总结：

这次分享，我们介绍了 云音乐引入 WebVitals 的背景，并且介绍了 3 个 核心指标集的定义和计算原理等，并介绍了平时在开发过程中可以使用到的谷歌工具。

最后我们给出了当前云音乐落地情况 和 带来的一些问题。

我们相信随着 WebVitals 指标的进一步普及 还有 开发者的及时更进，我们可以给用户带来的更好的用户体验。 Make The Web More Awesome!

我的分享结束了，谢谢大家。

演讲场所: 网易-集团前端沙龙

演讲简介: 介绍了云音乐前端性能监控平台。主要包括:

• 1、平台定位、功能模块介绍。
• 2、平台架构设计与搭建之路。
• 3、平台存在的问题与后续的改进规划。

演讲时间: 2019-06-13

演讲逐字稿

前言​

大家好，我是 kkdev163，来自云音乐前端技术组，今天带来的主题是云音乐 WebAPM 平台。

本次分享会分为三个部分，第一部分将介绍平台的定位及已有的功能模块。希望能让大家了解到平台的功能为何这样设计，了解这个平台可以解决什么问题，对大家的工作可以有哪些帮助等。

第二部分将介绍平台的架构演进之路。

希望能帮助大家掌握搭建通用监控系统所需的技术栈、了解其中的难点与解决思路。为后续解决相似的架构问题，提供参考。

第三部分将介绍平台后续的规划

会点出平台当前存在的不足与后续的改进思路，希望能引起大家的共同思考，帮助平台持续改进。

第一部分​

我们开始第一部分，平台的定位及已有功能模块的介绍。

• APM 是应用性能监控的简称。
• 它应该帮助开发者提升应用性能质量。
• 它应该提供一种衡量标准，能够证明我们产出的应用具有良好的性能与用户体验。
• 它的终极目标是 Make the web more awesome.

如果从监控手段来分区，平台的功能大致可以分为两个方向。

• 真实用户性能监控，它需要在页面上安装 SDK, 在用户访问页面时，采集上报用户真实的性能数据。

• 实验室合成测试监控，业界常见的性能测试有 Lighthouse、WebpageTest 等。它通过持续地测试来达成监控目的。

真实用户性能监控​

我们首先来看下真实用户性能监控。 开发者安装 sdk 后，可以看到应用的访问量数据、页面加载时性能、页面运行时性能、并且可以通过数据分析模块，来进行多维度的数据分析。

访问量数据​

访问量数据包含 PV/UV、访问量 Top10 页面、用户浏览器占比、操作系统占比等。

通过这一部分数据，可以让我们对使用我们应用的用户更加了解，可以支撑我们做一些决策，如不再支持某款浏览器、或是性能测试需要覆盖到某个系统版本以上。

加载时性能​

APM 会给出不同页面的加载时性能数据，这一部分的数据源是通过 W3C 性能工作组产出的 Navigation API 采集到的。

APM 会计算出页面加载时，关键时间节点的走势，如首次渲染时间、页面完全加载时间等。

除了走势，我们还计算出一段时间内，页面加载过程中各阶段耗时的瀑布流。可以较清晰的看到，页面加载过程中，在哪些阶段有较高的时间开销。。

同时我们也基于 IP 分析出各地区用户的加载性能情况。

并给出了性能样本的分布，如果需要验证应用的秒开率，95%分位数等可以在这里验证。

应用的加载时性能数据是这几块。其中有些部分我们可以有主动优化的能力，如 DOM 解析、资源加载耗时等。

有些部分我们不能做什么，如 TCP 连接、CDN 的地区网络状况等。。但是有了这部分数据，有了与其他应用的对比后，我们也可以尝试去推动上下游进行优化。

页运行时性能​

页面运行时性能我们主要通过 W3C 性能工作组产出的 Longtask API 采集页面运行过程中的长耗时任务。

并给出了长耗时任务的走势及持续时长的分布情况。。

那什么是长耗时任务 Longtask 呢？ 我们打开 Chrome 的 Performance.

主线程的工作是由这样一个一个的 Task 组成，当一个 Task 的执行超过 50ms 时，就可能会影响一帧的渲染，造成页面的卡顿。。

Longtask 可以用来帮助侦测页面运行时的卡顿率。

数据分析模块​

前面的模块都是按照页面整体维度，给出一个性能指标。。

而在数据分析模块中，我们可以选择不同的维度进行分析。。

比如我们这里选择了操作系统维度，来看一看 Android 与 iOS 设备的页面加载性能走势。。可以看到 Android 要比 iOS 高出一秒左右。

内置的事件有

• 页面访问量
• 加载时性能
• 运行时性能

可选的分析维度有

• 页面地址
• 浏览器版本
• 操作系统版本 等。。

除了这些系统预设的指标之外呢，我们还提供了自定义埋点 API。

可以在数据分析模块，查看到我们开发侧关心的一些埋点事件。可以应对大部分的自定义埋点需求。甚至是 Node JS 服务端的一些埋点，也可以打到 WebAPM 平台中。。

实验室合成监控​

APM 平台底层采用的是谷歌的 Lighthouse。

在这个页面,我们只需输入一个 url 地址，就可以发起一次 Lighthouse 测试。

等待数秒后，会展示测试的结果。

我们提供了原始的测试报告供下载。

并从测试报告中提炼了一些关键的指标，这些指标有 FCP、FMP、Speed Index、First CPU Idle、TTI 等。

需要说明的是, 这些指标不是从浏览器的 API 中采集的，他是对页面加载过程中逐帧进行截屏，根据图像算法，来计算出以上的几个指标。所以他会更接近用户的直观感受，会比 RUM 中的指标更会准确。

我们从分析的结果中，还提炼了页面首屏的加载资源，引导开发者去尽量减少关键渲染路径中的资源大小与数量。。

其实谷歌的 Chrome 中已经内置了 Lighthouse 的测试功能，那么我们为什么还要在 APM 平台上来测试呢，有什么区别吗？

我们先来铺垫一个细节，Lighthouse Performance 的分数是根据这五项的指标，按照权重计算出来的

• first-contentful-paint 3
• first-meaningful-paint 1
• speed-index 4
• interactive 5
• first-cpu-idle 2
• estimated-input-latency 0

这几项结果与测试浏览器所在的宿主机的网速、CPU 等都是相关的。所以在不同的宿主环境下测试，结果会存在波动，说直白点就是领导说你的 Lighthouse 分数很低啊，你说我电脑上是好的，这没有说服力。。

了解了这个细节后，我们来回到为什么使用 APM 平台来测试会更好？

首先 APM 的 Lighthouse 测试是在服务端的 Docker 容器内，使用无头浏览器进行测试，所有的页面会在一个相对稳定与一致的宿主浏览器环境下进行测试。。优势一就是测试的宿主环境相对一致。

第二点，我们可以把这个页面加入到定时测试任务中。APM 平台会以 10 分钟一次的频率对页面进行测试，对多次的测试结果求均值。。优势二是降低了减少了单次测试的不稳定性。

第三点，我们将一次次孤立的测试结果，关联上了时间维度，形成了页面性能的走势，对页面的性能优化，可以很明显的体现在走势上，更加地有说服力。。

第四点，我们将孤立的一个页面测试，与组织内的其他页面形成了关联，开发者除了得到一些性能数据以外，也可以更为直观的了解到，自己的页面在组织内到底处于哪个阶段。

我们可以向着组织内的标杆看齐，在此向古典专区的开发者杨老师致敬，我们需要有榜样的力量。。

除了上面的优势外，我们还做尝试与 H5 搭建工具合作。 在页面制作完发布上线时，会将 url 与运营人员的邮箱发送的 WebAPM 平台，平台会将页面加入到定时测试中，并将页面的这一次测试结果与组织内的排名发送给运营人员。。

邮件内会包含上线建议，比如优化超标的图片资源等。。

一部分总结​

介绍完 WebAPM 的功能后，我们通过对比做一个总结。。

Lighthouse 的优势是

• 无需接入 SDK, 一个 URL 即可测试。
• FCP FMP 等性能指标更贴近用户直观感受。
• 性能的评分较为的可信。。

Lighthouse 的短板是：

• 如果依赖手工录入 url，页面可能覆盖不全
• 需要模拟页面的前置依赖，如登录等。
• 测试的机型较为单一。

真实用户性能监控的优势是：

• 页面覆盖全
• 无需模拟，用户正常访问就可以采集到页面性能数据
• 机型覆盖广、数据样本量大

真实用户性能监控的短板是：

• 需要接入 SDK, 数据上报存在开销
• 性能指标依赖于浏览器的实现
• 性能指标与用户的感知存在一定的偏差

其实 WebAPM 就是一个数据平台，我们可以利用这些数据，参与需求的决策、主动地发起性能优化、推动上下游优化、优化的成果可以成为我们述职、CPP 的材料。。

第二部分 平台的架构演进之路​

我们先介绍一个监控系统的简化模型。。

首先需要有一个数据采集端，他可是一个 sdk，日志采集器，也可以是一个传感器。

数据采集后会上报到服务端，服务端对数据做部分的清洗和加工后，写入到时序数据库中。

当前台需要可视化展示时，服务端会发送聚合查询到数据库，然后加工成可视化数据后，返回给前台做展示。

在 WebAPM 中，数据采集端就是浏览器 SDK, 服务器就是 Node JS，时序数据库是 Influx DB, 可视化展示是 Antd。

这个模型中，大家可能对 Influx 最不熟悉了。。

在介绍后续的架构演进之前，我们首先来介绍下，什么是时序数据库？

我们以 Influx DB 为例展开介绍。。

从这个表中，我们可以看到每条记录都包含时间字段，这是时序数据库的特点，并且时序数据库中内置了大量的基于时间的聚合函数。。

比如求一段时间内均值的 Mean 函数。

这段 SQL 就是计算过去 5 分钟时间内，tcp 和 load 指标的平均值。。

我们执行这条 SQL 后，就得到了两个指标的均值。。

事实上 WebAPM 的加载瀑布图正是通过这条 SQL 来实现的。

基于上一条 SQL，我们加上 GROUP BY time()，他就可以计算出过去 5 分钟内，每一分钟的平均值。诶，这个就是关联上时间维度的走势啦。。

事实上，WebAPM 的加载耗时的走势就是通过这条 SQL 来实现的。。

每次，我们已经掌握了时序数据库的基本用法。。

OK, 这个监控架构我们也掌握了。。

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

比如当我们从过去 5 分钟，变为计算 7 天的平均值，并且假设我们要统计的是一个大量流量应用，且 7 天有 1000 万条用户数据记录。。

我们是否可以简单粗暴的把 5m 改成 7d 呢？来，我们试一下。。

不好意思，我们真这么做的话，哨兵马上就要报警了，告诉我们内存吃紧了，CPU 要耗尽了。。

那我们怎么来计算这 1000 万条记录，对他们求均值呢？？

其中一个解决思路是，把计算均摊到每分钟。。

原来我们要直接计算 7 天 1000 万个数据点。。

现在我们不这么做了。。

我们在收到数据的时候，就定时的，每一分钟，去计算这一分钟的数据聚合结果并把它保存起来。。

那么这样持续的计算，7 天就会有 10080 个计算结果。。

当我们需要去计算 7 天的均值时，我们不需要再从 1000 万个原始数据中求均值，我们只要在 10080 个数据中计算即可。。

数据的规模量大大降低，当然我们还可以再降，比如一小时计算一次，我们不展开讲。。

那么现在的问题就是如何定时做每分钟的计算呢？？

实际上 Influx 已经提供了这样的能力，叫做 Continue Query，我们简称 CQ 吧。。

创建一个 CQ 很简单，就跟查询是一样的。。

他会定时的，把原始数据，做聚合计算，然后把计算的结果写入到 CQ 表中。。

现在我们回到刚刚的需求，我们只需要稍作变更，从 CQ 表中请均值即可。。。

那么引入 CQ 后，我们的存储与计算模型就长这样了。。

没错，我们已经掌握了时序数据库的高级用法了。

但是随着应用接入越来越多，存入的原始数据就越来越多。。

Influx 会对存入的数据建立内存索引，索引的规模可以用 Series 这个指标来衡量，通过官方文档的图片，我们可以看到，Series 数量级与内存开销的关系图。。

我们当前 Series 的数量级已经达到了 200 万，云主机上的内存压力是蛮大的。。

我们如何来缓解这个问题呢？

其实我们可以在写入数据库前就将原始的数据做聚合，只存入聚合后的数据，那么就可以缓解 DB 的压力。。

现在的问题变成，如何在存入数据数据库前做数据的聚合。。

我们可以直接在 Node JS 上做聚合计算吗？

如果我们的 Node JS 是单机部署的话，只要在 Node JS 上做一个 1 分钟的数据窗口，将聚合后的数据写入数据库，这样的模型看起来好像也是挺合理的。。

但是如果我们的 NodeJS 是集群部署。。

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

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

如果有一个做聚合计算的中间件就好了。。Flink 就是干这件事的。。Flink 很牛，但是在这里，我们先简单把他理解成做聚合计算的中间件。。

我们来看下引入 Flink 后的数据流。。

首先 SDK 将数据上报到 NodeJS, NodeJS 对数据做清理和加工后，发布到消息队列的原始数据队列里。。Flink 订阅了这个数据，会从队列里不断地取出数据，并根据配置的时间窗口做集合计算，然后将计算后的结果写到计算结果队列中，NodeJS 订阅了这个队列，在收到数据后，将聚合的结果写入到 InfluxDB。

后续前台需要查询数据，仍然是从 InfluxDB 中读取。。

Flink 很牛，那我们应该怎么玩呢？是要自己搭吗？不用，我们现在已经有这样的基础设施。。其他部门可能也都有。。

云音乐 Flink 计算平台-Magina, 在上面我们可以配置一个计算任务的数据输入源，数据输出源，和对数据的操作。。

输入与输出我们这边就是消息队列了。

操作可以通过写 SQL 或者开发一个 Java JAR 包的方式。。

我们这里演示的是 SQL。

我们只要知道这个平台可以做聚合计算、并且操作很便捷就可以。。具体的语法可以后面再了解。。

那引入 Flink 后有哪些优势呢？

首先我们降低了 Influx DB 的存储与计算压力。。 那可能有同学会疑问，你自己的压力小了，别人的压力大了啊，你这是甩锅。。

不是这样的，人家 Flink 平台，肯定是可以动态扩缩容的，可以动态变更算力，我们把计算统一到他这里管理，我们的 Influx 就不需要那么高的配置，对于整个组织来说，是节约资源。。

第二个优势是 Flink 可以通过配置自定义聚合函数，那么我们对数据的加工能力将不受限于 Influx DB 内置的聚合函数。。

第三个优势是 在使用 Influx 社区单机版的前提下，我们整个系统的架构更具有弹性的高可用方案。 有了消息队列以后，我们不需要为了应对峰时的流量而无限提高 Influx 的配置，而且 Influx 挂掉后，数据依然是在聚合并写到消息队列中。。等 Influx 恢复后，数据可以继续写入，挂掉这段时间的数据不会丢失。。

OK, 这就是为大家介绍的通用的监控架构。。我们的时序数据库可以是 Influx DB 也可以换成 ES。 前端展示我们可以自己开发，也可以使用开源的可视化 Grafana，无需开发，只要通过配置就可以做可视化展示。。

这个监控架构有什么用呢？？ 其实后端提供的中间件、微服务，都会对服务做监控，以保障服务的可靠性。。那么随着 Node JS 的大力发展，我们前端后续可能也会提供出一些微服务，那么这些服务的保障就需要监控。。如果我们部门的基础设施，无法满足我们的需求。。那么我们就可以自己搭一个监控。。

未来规划​

最后我们聊一聊未来的规划，

数据精细化展示​

我们当前的真实用户数据展示中，会有数据的波动，其中有一部分原因可能是极端性能状况引起。

后续我们引入 Flink 后，可以通过自定义的聚合函数，将头尾 5%的极端数据剔除后请均值。。

性能对比​

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

但是真实用户性能这块，我们应用的数据仍然是比较孤立的，开发者其实比较难以知道，自己的应用性能到底处于什么水平，是好是差。。

• 后续会考虑将组织内的性能数据，建立性能分档，每个档位对应一个分数，计算出应用的评分。。

• 将相同业务场景的应用进行对比，如同样都是云音乐小程序、同样都是 SSR 的架构

• 并且基于业务场景，给出针对性的优化建议。。

Influx 单机版问题。​

实际上，我们当前在用的是饿了么的 Influx Proxy 方案，可以通过配置成数据双写，来做数据的备份，以达到高可用的目的。。

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

但这个还不是最完美的。。杭研的 NTSDB 是真 Influx 集群，后续我们可能会迁移到 NTSDB 来。。

另外也借着这个机会，感谢 NTSDB 的作者，范欣欣同事，他对 WebAPM 的架构改进提供了指导。。

总结​

首先我介绍了平台的定位及已有的功能，按照监控手段划分，平台可以分为 2 个方向。

其次我介绍了平台的架构演进，为大家介绍了通用的监控系统技术栈和其中的难点与解决思路。。。

最后我介绍了平台后续的规划，包括精细化数据分析、应用性能对比和 Influx 集群迁移。

感谢大家的耐心聆听，本次分享就到这里。。最后是交流时间。。

演讲场所: 网易-组内分享

演讲简介: 介绍了页面渲染性能优化基础, 包括

• 浏览器渲染 HTML 流程
• 浏览器渲染一帧流程
• Longtask API 及 APM 介绍
• Chrome Devtools-Performance

演讲时间: 2019-03-07