28 | 设计性能守卫系统：完善 CI/CD 流程

前端基础建设与架构 - 前百度资深前端开发工程师 - 拉勾教育

性能始终是宏大的话题，前面几讲我们或多或少都有涉及性能优化的各种方案。其实，除了传统的性能优化手段以外，我们还需要对性能进行把关，目的是在性能恶化时有所感知、有所防控。那么，一个性能守卫系统即性能监控系统究竟应该如何设计呢？

借助 Node.js 的能力，这一讲我们就下钻到 CI/CD 流程，设计一个性能守卫系统。希望通过这一讲的学习，你可以认识到：Node.js 除了同构直出、数据聚合以外，还能做一些重要的，且有趣的服务。

性能守卫理论基础

性能守卫的含义是：对每次上线进行性能把关，对性能恶化做到提前预警。它包含了一个性能监控平台，同时也需要给出更多的性能建议和指标建设。

那么我们如何感知到性能的好坏呢？我们对于 Load/DOMContentLoaded 事件、FP/FCP 指标已经耳熟能详了，下面我们再扩充几个更加现代化的指标。

• LCP（Largest Contentful Paint）

衡量页面的加载体验，它表示视口内可见的最大内容元素的渲染时间。相比 FCP，这个指标可以更加真实地反映具体内容加载速度。比如，如果页面渲染前有一个 loading 动画，那么 FCP 可能会以 loading 动画出现的时间为准，而 LCP 定义了 loading 动画加载后，真实渲染出内容的时间。

• FID（First Input Delay）

衡量可交互性，它表示用户和页面进行首次交互操作所花费的时间。它比 TTI（Time to Interact）更加提前，这个阶段虽然页面已经显示出部分内容，但并不能完全具备可交互性，对于用户的响应可能会有较大的延迟。

• CLS（Cumulative Layout Shift）

衡量视觉稳定性，表示页面的整个生命周期中，发生的每个意外的样式移动的所有单独布局更改得分的总和。所以这个分数当然越小越好。

以上是几个重要的、现代化的性能指标。结合我们传统的 FP/FCP/FMP 时间等，我们可以构建出一个相对完备的指标系统。这里我们就不再一一分析如何获取和收集这些性能指标了，相关内容社区上有不少文章。我们把目光放到更高层面，请你思考一下：如何从这些指标中，得到监控素材？

业界公认的监控素材主要由两方面提供：

• 真实用户监控（Real User Monitoring，RUM）
• 合成监控（Synthetic Monitoring，SYN）

真实用户监控是基于用户真实访问应用情况，在应用生命周期内计算产出性能指标，并进行上报。开发者拉取日志服务器上的指标数据，进行清洗加工，最终生成真实的访问监控报告。

真实用户监控一般搭配稳定的 SDK，会在一定程度上影响用户的访问性能，也给用户带来了额外的流量消耗。

合成监控是一种实验室数据，它指的是在某一个模拟场景中，通过工具，搭配规则和性能审计条目，得到一个合成的监控报告。

合成监控的优点比较明显，它的实现比较简单，有现成成熟的解决方案；如果搭配丰富的场景和规则，得到的数据类型也会较多。但它的缺点是数据量相对较小，且模拟条件配置相对复杂，无法完全反映真实场景。

而在 CI/CD pipeline 上，我们需要设计的性能守卫方案就是一种合成监控方案。在方案设计上，我们需要做到扬长避短。

Lighthouse 原理介绍

前文提到，合成监控有成熟的方案，比如 Lighthouse。我们的方案也基于 Lighthouse 进行，这里对 Lighthouse 原理进行介绍。

Lighthouse 是一个开源的自动化工具，它提供了四种使用方式，分别是：

• Chrome DevTools
• Chrome 插件
• Node cli
• Node module

我们先通过 Chrome DevTools 来迅速体验一下 Lighthouse。在 Audits 面板下，进行相关测试，可以得到一个网址的相关测试报告，内容如下图：

这个报告是如何得出的呢？我们先来看 Lighthouse 的架构图：

Lighthouse 架构图

图中的一些关键名词：

• Driver（驱动器），根据Chrome Debugging Protocol协议与浏览器交互的对象；
• Gatherers（采集器），调用 Driver 运行浏览器命令后得到的网页基础信息，每个采集器都会收集自己的目标信息，并生成中间产物（Artifacts）；
• Artifacts（中间产物），一系列 Gatherers 的集合，会被 Audits 使用，并计算得分；
• Audits（审计项），以 Artifacts 作为输入，进行性能测试并评估分数后得到的 LHAR（LightHouse Audit Result Object）标准数据对象。

我们结合上述名词，对 Lighthouse 架构原理进行分析：

• 首先，Lighthouse 驱动 Driver，底层通过 Chrome DevTool Protocol 调用浏览器进行应用的加载和渲染；
• 然后通过 Gatherers 模块集合，获取收集到的 Artifacts 信息；
• Artifacts 信息在 Auditing 阶段，通过对自定义指标的审计，得到 Audits 结果，并生成相关文件。

从该流程中我们可以得到的关键信息：

• Lighthouse 会与浏览器建立连接，并通过 CDP 与浏览器进行交互；
• 通过 Lighthouse，我们可以自定义审计项并得到审计结果。

在我们的性能守卫系统中，是采用 Lighthouse 的后两种使用方式（Node.js cli/ Node.js 模块）进行性能跑分的，下面代码给出一个基本的使用方式：

const fs = require('fs');
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');
(async () => {
const chrome = await chromeLauncher.launch({chromeFlags: ['--headless']});
const options = {logLevel: 'info', output: 'html', onlyCategories: ['performance'], port: chrome.port};
const runnerResult = await lighthouse('https://example.com', options);
const reportHtml = runnerResult.report;
  fs.writeFileSync('lhreport.html', reportHtml);
  console.log('Report is done for', runnerResult.lhr.finalUrl);
  console.log('Performance score was', runnerResult.lhr.categories.performance.score * 100);
  await chrome.kill();
})();

上面的代码描述了一个简单的 Node.js 环境使用 Lighthouse 的场景。其中提到了 lighthous-ci，这是官方给出的 CI/CD 过程接入 Lighthouse 的方案。但一般在企业中，CI/CD 过程相对敏感，我们的性能守卫系统就需要在私有前提下，介入 CI/CD 流程，本质上来说是实现一个专有的 lighthous-ci。

性能守卫系统：Perf-patronus

我们暂且给性能守卫系统起名为 Perf-patronus，寓意为性能 - 护卫神。

预计 Perf-patronus 会默认监控以下性能指标：

• FCP
• Total Blocking Time
• First CPU Idle
• TTI
• Speed Index
• LCP

其工作架构和流程如下图所示：

Perf-patronus 工作架构及流程图

• 特定环境完成 MR 部署后，开始进行性能体检服务。
• 性能体检服务由消息队列 worker 消费完成。
• 每一次性能体检产出体检数据，根据数据内容是否达标，进行后续消息提醒；体检数据内容同时被性能守卫系统平台所消费，展现相关页面的性能情况。
• 性能数据由 Redis 存储。
• 性能体检相关富媒体资源（页面截图等）可以由容器持久化目录存储，或上传到 OSS 服务

预计平台使用情况，如下图所示：

技术架构流程相对清晰，但我们需要思考一个重要的问题：如何真实反映用户情况？并以此为出发点，完善性能守卫系统的相关设计。

如何真实反映用户情况？

真实用户访问页面的情况千变万化，即便我们的代码没有变化，其他可变因素也会大量存在。因此我们应该统一共识一个相对稳定可靠的性能评判标准，其中关键一环是分析可能出现的可变因素，对每一类可变因素进行不同针对性设计，保证每次性能服务产出结果的说服力和稳定性。

常见不确定和波动因素

• 页面不确定性

比如 A/B 实验情况。这种情况性能体检服务无法进行处理，需要接入者保证页面性能的可对比性。

• 用户侧网络情况不确定性

针对这种情况，性能体检服务应该设计有可靠的 Throttling 机制，以及较合理的请求等待时间。

• 终端设备不确定性

性能体检服务应该设计有可靠的 CPU Simulating 能力，并统一 CPU 能力测试范围标准。

• 页面服务器不稳定性
  这方面因素影响较小，应该不用过多考虑。对于服务挂掉的情况，反映出性能异常即可。
• 性能体检服务的稳定性

在同一台机器上，如果不确定有其他应用服务，会影响性能体检服务的稳定性和一致性。不过预计该影响因素不大，可以通过模拟网络环境和 CPU 能力，来保障性能体检服务的稳定性和一致性。

在对性能服务的跑分设计时，都需要考虑上述可变因素，大体上我们可以通过以下手段，最大化地磨平差异：

• 保证性能体检服务的硬件 / 容器能力；
• 需要接入者清楚代码或页面变动对页面性能可能产生的影响，并做好相应接入侧处理；
• 自动化重复多次跑性能服务，取平均值；
• 模拟多种网络 / 终端情况，设计得分权重。

如何解决有 “用户态” 页面的鉴权问题？

对于有登录状态的页面，我们提供以下几种方案进行登录状态的性能服务：

• 通过Puppeteer page.cookie，测试时通过 script 实现登录态；
• 通过请求服务时，传递参数解决登录态问题。

整体流程

下面我们通过代码来串联整个流程。入口任务：

async run(runOptions: RunOptions) {
const results = {};
const context = await this.createPuppeteer(runOptions);
try {
    await this.Login(context);
    await this.before(context);
    await this.getLighthouseResult(context);
    await this.after(context, results);
return await this.collectArtifact(context, results);
  } catch (error) {
throw error;
  } finally {
    await this.disposeDriver(context);
  }
}

其中，创建一个 Puppeteer 无头浏览器的逻辑，如下代码：

async createPuppeteer (runOptions: RunOptions) {
const launchOptions: puppeteer.LaunchOptions = {
    headless: true, 
    defaultViewport: { width: 1440, height: 960 }, 
    args: ['--no-sandbox', '--disable-dev-shm-usage'],
    executablePath: 'xxx',
  };
const browser = await puppeteer.launch(launchOptions);
const page = (await browser.pages())[0];
return { browser, page };
}

打开相关页面，并执行 Lighthouse 模块，如下代码所示：

async getLighthouseResult(context: Context) {
const { browser, url } = context;
const { artifacts, lhr } = await lighthouse(url, {
    port: new URL(browser.wsEndpoint()).port,
    output: 'json',
    logLevel: 'info',
    emulatedFormFactor: 'desktop',
    throttling: {
      rttMs: 40,
      throughputKbps: 10 * 1024,
      cpuSlowdownMultiplier: 1,
      requestLatencyMs: 0, 
      downloadThroughputKbps: 0,
      uploadThroughputKbps: 0,
    },
    disableDeviceEmulation: true,
    onlyCategories: ['performance'],
  });
  context.lhr = lhr;
  context.artifacts = artifacts;
}

上述流程都是常规启用 Lighthouse 模块，在 Node.js 环境中对相关页面执行 Lighthouse 的逻辑。

我们自定义的逻辑往往可以通过 Lighthouse 插件实现，一个 Lighthouse 插件就是一个 Node.js 模块，在插件中我们可以定义 Lighthouse 的检查项，并在产出报告中以一个新的 category 呈现。

举个例子，我们想要实现 “检查页面中是否含有大小超过 5MB 的 GIF 图片” 的任务，如以下代码：

module.exports = {
  audits: [{
    path: 'lighthouse-plugin-cinememe/audits/cinememe.js',
  }],
  category: {
    title: 'Obligatory Cinememes',
    description: 'Modern webapps should have cinememes to ensure a positive ' +
'user experience.',
    auditRefs: [
      {id: 'cinememe', weight: 1},
    ],
  },
};

对应自定义 Audits，如下代码：

'use strict';
const Audit = require('lighthouse').Audit;
class CinememeAudit extends Audit {
static get meta() {
return {
      id: 'cinememe',
      title: 'Has cinememes',
      failureTitle: 'Does not have cinememes',
      description: 'This page should have a cinememe in order to be a modern ' +
'webapp.',
      requiredArtifacts: ['ImageElements'],
    };
  }
static audit(artifacts) {
    let hasCinememe = false;
const results = [];
    artifacts.ImageElements.filter(image => {
return !image.isCss &&
        image.mimeType &&
        image.mimeType !== 'image/svg+xml' &&
        image.naturalHeight > 5 &&
        image.naturalWidth > 5 &&
        image.displayedWidth &&
        image.displayedHeight;
    }).forEach(image => {
if (image.mimeType === 'image/gif' && image.resourceSize >= 5000000) {
        hasCinememe = true;
      } else {
        results.push(image);
      }
    });
const headings = [
      {key: 'src', itemType: 'thumbnail', text: ''},
      {key: 'src', itemType: 'url', text: 'url'},
      {key: 'mimeType', itemType: 'text', text: 'MIME type'},
      {key: 'resourceSize', itemType: 'text', text: 'Resource Size'},
    ];
return {
      score: hasCinememe > 0 ? 1 : 0,
      details: Audit.makeTableDetails(headings, results),
    };
  }
}
module.exports = CinememeAudit;

通过上面插件，我们就可以在 Node.js 环境中，结合 CI/CD 流程，找出页面中大小超过 5MB 的 GIF 图片了。

由插件原理可知，一个性能守卫系统，是通过常规插件和自定义插件集合而成的，具有良好的扩展性。

总结

这一讲我们通过一个性能守卫系统，拓宽了 Node.js 的应用场景。我们需要对性能话题有一个更现代化的理论认知：传统的性能指标数据依然重要，但是现代化的性能指标数据也在很大程度上反映了用户体验。我们也应该通过学习，了解 Lighthouse 架构及其原理，并能通过 Lighthouse 插件进行自定义扩展，实现我们自主的性能指标考量。

本讲内容总结如下：

一方面，性能知识把基于 Lighthouse 的 Node.js 相关模块搬上 CI/CD 系统，这样一来我们能够守卫每一次上线，分析每一次上线对性能产生的影响——这是非常重要的实践。任何能力和扩展如果只是在本地，或通过 Chrome 插件的形式尝鲜显然是不够的，借助于 Node.js，我们能做到更多。

下一讲，我们将深入讲解 Node.js 另外一个重要的应用场景：企业级 BFF 网关。网关这个话题可以和微服务、Serverless 等概念相结合，想象空间无限大；同时我们又要深入到网关实现代码，抽丝剥茧，请你做好准备。