无声的刺客最为致命，往往表面看似云淡风轻，实际早已危机重重，血雨腥风一触即发。这样的场面看似离我们很遥远，但每个开发运维人员实际都遇到过。

在全球数字经济大潮下，现代企业纷纷投身于业务数字化转型的浪潮。越来越多的行业演变成一个个互联网应用，以实时在线的数字化方式提供服务，摆脱了传统意义上物理位置和营业时间的束缚。此时在线服务的稳定性、可靠性和并发性能变得尤为重要，因为这些都会极大地影响用户体验和服务质量评价。

▲ 图源自网络，侵删

比如在刚过去的 2022 年，全国百姓的日常民生问题，都和一个小小的在线实时生成的二维码产生密切关联，若因服务质量不稳定会造成多严重的后果可想而知。如果此时系统内出现无声的刺客，他可能摧毁的不仅仅是一个系统，甚至关乎企业多年累积的客户信任与品牌形象，决定企业存亡。

如何去发现和识别这些未知的风险，提早做好预防和优化，是每个开发运维人员需要持续面对的问题。本文以系统性能瓶颈为例，展示如何通过系统全链路可观测，来识别和定位系统前端性能、链路性能、基础设施性能瓶颈以及高效分析系统日志。所涉及到的实现思路和工具会覆盖软件开发、测试、部署和运维各个环节。

前端性能瓶颈

表现行为

性能瓶颈一般是表现在用户体验方面：

比如用户反馈说：页面加载过慢，动画卡顿，交互延迟；
比如用户反馈说：你们这个页面怎么加载这么慢啊，好几秒才呈现；
比如 PM 反馈说：这个列表滑动的时候加载数据一卡一卡的。

总之前端的性能瓶颈往往都是有表现的，需要针对具体表现具体分析具体解决。

前端瓶颈介绍

前端性能瓶颈通常包括以下几个方面：

加载时间：页面的加载时间是一个重要的方面。当页面加载时间很长时，用户体验会受到明显的影响；
渲染时间：渲染时间是指浏览器将 HTML、CSS 和 JavaScript 代码转换成实际界面的时间；
CPU 占用率：使用大量的 JavaScript 代码可以导致 CPU 占用率过高，从而导致页面性能下降；
内存泄漏：内存泄漏是指未能释放已不需要的内存。当 JavaScript 代码不合理地使用内存时，页面的性能会受到影响。
图像质量和大小：图片文件的大小会影响页面的加载时间。
more...小编持续更新

面对瓶颈的排查思路

工欲善其事，必先利其器，前端排查思路一般有以下几种：

思路1：F12

可在浏览器的 devtool 里一项项排查，查看临近运行状态，跟进片段的脚本调用，一点点调试，如下图：

思路2：利用某网站测试性能平台思路

输入网址可以看到网站的性能测试结果，可以把所有性能相关指标（FCP、LCP、TBT、CLS）状态展示出来，但是仅仅代表点击测试之后的结果，偶现性能结果不代表所有测试结果，如下图：

思路3：可观测建设思路，性能指标等数据可视化

为什么要可视化？

收集到性能监控或者性能指标后，就需要将数据可视化展示出来，狭义上数据可视化是将性能的监控指标通过图表的形式展示出来，场景化能满足对数据观测的需求，其中就包含帮助发现数据中隐藏的内在规律。

接入观测云，将前端应用数据采集到后，可以通过「观测云控制台」查看应用性能分析，改善页面加载（LCP）、互动性（FID）和页面稳定性（CLS），提高用户体验。

先讲一下谷歌网站核心指标几个核心指标：LCP、FID、CLS，我们用这三个指标来衡量网站的载入速度、互动性和页面稳定性。

将我的一个网站接入 RUM 后，在 Web 应用的「性能分析」页面可以看到，例如统计 PV 数、页面加载时间、网站核心指标、最受关注页面会话数、页面长任务分析、XHR & Fetch 分析、资源分析等指标，如下图效果展示：

性能指标等数据可视化，快速定位

总之，前端技术栈的性能调优需要从多个方面入手，并综合使用多种方法来提高页面的加载速度和用户体验。

在思路3中，我们已经介绍了用的是观测云可视化出来性能指标，可视化后，有了依据这样就可以有针对性进行解决，以下实战中快速定位了多个维度的优化点，分别从长任务、Image、XHR、JS、CSS、Document、Font 方面展示。

实战1：快速定位长任务卡顿页面

TopN 长耗时页面，通过饼图方式，将长任务耗时和页面关联，直观地看到是因为 xxx 页面导致的卡顿。

实战2：快速定位优化的优先级

长耗时任务在不同页面的时序分布，可以针对页面进行优化排等级，如 /statics 页面出现的长耗时任务较多，可能需要优化的优先级就可能会靠前，或者对应的前端负责人员设定绩效考核点，让绩效直接跟性能挂钩。

实战3：快速定位出 Top 资源消耗

按照耗时来排序，找出耗时最长或者排名靠前的一个资源，定向进行优化，Image、XHR、JS、CSS、Document、Font，定位之后，明确性能优化方向，快速解决问题。

性能调优建议

综上瓶颈所述，对前端性能瓶颈的优化措施需要从多个方面着手，包括加载时间、渲染时间、CPU占用率、内存泄漏和图像质量和大小等，总体来讲总结一下：

压缩文件大小：通过压缩文件大小可以减少页面资源的下载时间。可以使用 Gzip 或 Brotli 等压缩算法来压缩 CSS、JavaScript 和 HTML 文件。
使用 CDN：使用内容分发网络（CDN）可以将页面资源缓存在多个服务器上，从而加快资源加载速度。
延迟加载：延迟加载可以将页面上的资源加载推迟到页面加载完成之后，从而减少页面的加载时间。可以使用 lazyload.js 等工具来实现延迟加载。
优化图片：图片通常是页面资源中最大的部分。可以通过压缩和合并图片、使用响应式图片、使用 WebP 等方法来优化图片。
使用缓存：使用缓存可以减少页面资源的下载时间。可以使用浏览器缓存、HTTP 缓存和应用程序缓存来缓存页面资源。
避免重排和重绘：当页面元素发生变化时，浏览器需要重新计算布局和重绘页面。这些操作会消耗大量的 CPU 时间。可以使用 CSS 动画、将页面元素缩减到最少等方法来避免重排和重绘。
代码优化：通过优化 JavaScript 代码可以减少页面的加载时间。可以使用代码压缩工具、将脚本放在页面底部、使用异步脚本等方法来优化代码。另外，可以使用性能分析工具（如Chrome DevTools）来识别潜在的性能问题并进行优化。
优化HTTP请求。

链路性能瓶颈

表现行为

延迟增加：应用链路可能会因为不同的原因导致延迟增加。当应用链路中的某个服务出现问题时，它可能会影响其他服务的响应速度，从而导致整个系统的延迟增加。
错误增加：应用链路问题可能会引起服务之间的错误传递。一开始错误可能只是在一个服务中出现，但是如果未能及时发现，它可能会在整个应用链路中传递并引起其他服务的错误。
服务不可用：如果某个服务因为某些原因无法使用，整个应用链路可能无法正常工作。服务不可用的原因可能是计划内的维护、不可预测的故障或者运行环境的更改。
重试增多：应用链路中的某些服务可能无法正常工作，这会导致其他服务频繁重试。如果服务重试次数越来越多，可能会导致整个应用链路崩溃。
资源消耗增加：应用链路中的某个服务可能未能及时释放资源，导致资源消耗增加。如果未能及时发现和修复，可能会导致其他服务的资源消耗增加。
服务版本不一致：应用链路中使用的各种服务可能有不同的版本。如果不同版本之间没有正确协调，可能会导致不兼容的问题，甚至可能会导致整个应用链路崩溃。
数据一致性问题：应用链路可能包含多个服务，每个服务都有自己的数据库。如果多个服务处理同一数据，但是数据的一致性没有得到保证，就可能导致应用链路中出现数据一致性问题。

总之，应用链路问题可能会表现出不同的表现特征。监测和定位这些问题需要使用一些工具和技术，如观测云的应用性能监测、分布式跟踪、日志管理和异常告警监控。只有及时发现和解决应用链路问题，才能确保整个应用能够正常运行。

排查思路

观测云的应用性能分析功能，是一种用于定位应用性能瓶颈的强大工具。它可以帮助追踪应用程序的各个部分，并找出哪些部分需要优化。

在使用观测云性能时，我们可以采取以下步骤来定位应用程序的性能瓶颈：

1.定义关键业务指标和性能指标

首先，需要在应用程序中定义关键业务指标和性能指标。这些指标将有助于了解应用程序的性能和行为。需要确定哪些指标对业务最为关键，并将其作为性能监控的重点。

2.跟踪应用程序的各个部分

需要使用APM工具来跟踪应用程序的各个部分。这些部分可能包括数据库、网络、前端和后端等。需要了解每个部分的性能状况，并找出性能瓶颈所在的具体部分。

3.分析数据

一旦我们收集了足够的数据，需要对数据进行分析。可以使用火焰图来查看应用程序的各个部分，并确定哪些部分需要优化。我们可以查看响应时间、吞吐量和错误率等指标，以确定性能瓶颈所在的具体部分。

4.优化性能

最后，我们需要根据分析的结果来优化应用程序的性能。这可能包括对代码进行更改、优化数据库查询、增加缓存等。需要对性能瓶颈所在的具体部分进行优化，以提高应用程序的整体性能。

还想再次强调一点：在使用应用性能工具时，需要关注应用程序的整体性能和行为。需要搭配观测云的指标、日志、巡检等功能，及时发现和解决性能问题。这是确保应用程序高效运行的关键。

实际链路数据分析

1.登录观测云工作空间，查看「应用性能监测」模块的服务列表，从服务页面已经可以看出 browser 服务的 P90 响应时间是比较长的。

2.点击 browser 服务名称，查看该服务的概览分析视图，可以看出影响当前服务响应时间的最关键的资源是 dept 这个接口，因为这个接口是观测云的一个数据查询接口，所以接下来我们看下这个接口在查询过程当中，到底是因为什么导致耗时较长。

3.点击「资源名称」，跳转到「查看器」，通过点击「持续时间」倒序查看响应时间的最大值。

4.点击「Span」数据，查看分析当前 Span 在整个链路里面的执行性能和其他相关信息。

点击右上角「全屏]」模式按钮，放大查看火焰图相关信息。结合整体链路查看，可以看出 ruoyi-system 服务在整个链路中的执行时间占比高达 65.12%，从「Span 列表」也可以得出此结论。

根据「火焰图」的占比和对应的链路详情信息，我们可以总和得出 browser 的这个 query_data Span 在整个执行过程中 resource_first_byte（资源加载首包时间）耗时 2.07 秒；再结合查看 province 的地理位置定位非杭州，而我们的站点部署在杭州节点，则可以得出是因为地理位置问题导致数据传输的时间变长从而影响了整个的耗时。

基础设施资源占用

通过观测基础设施资源消耗情况，往往可以发现系统的性能瓶颈。

CPU 使用

1.CPU 使用率和负载区别

CPU 使用率和负载都是用来描述 CPU 性能的指标，但两者之间还是有一定区别的。CPU 负载反映的是进程排队的情况，即有几个进程在等待 CPU 资源；而 CPU 使用率反映的是 CPU 当前处理的进程的占用情况，即当前 CPU 正忙的程度。

CPU 利用率：CPU 使用率是指 CPU 资源被当前运行进程使用的时间占总时间的比例。

CPU 负载：一段时间内系统中运行或等待运行的进程数量。

2.CPU 使用率和负载分析

对于目标系统是否处于高负载状态，需要综合考虑这两个指标。当 CPU 负载较高时，不一定会导致 CPU 使用率也很高，因为等待 CPU 资源的进程可能只是在等待 IO 等其他资源；但是如果 CPU 使用率也较高，系统表明 CPU 资源正在被占满，需要进一步优化系统资源分配和调整任务优先级等。

3.CPU 理想值

一般情况下，单核 CPU 负载 0.5~0.8 之间算是一种理想状态，如果是双核主机，那就是 0.8*2=1.6 左右。而 CPU 使用率单核 80% 以下，超过这个值就说明存在性能瓶颈，可能会影响应用，需要进行扩容或者优化资源。

内存使用

内存作为一种重要的计算机硬件，对计算机系统的性能起着至关重要的作用。然而，内存的性能也可能成为计算机系统性能的瓶颈之一。

1.内存带宽

内存带宽是指内存的数据传输速率，如果内存的数据传输速率比其他硬件或其他组件的传输速率慢，就会影响性能。

2.内存延迟

内存延迟是指获取内存数据所需的时间。当计算机 CPU 需要使用内存数据时，如果内存延迟过高，则 CPU 需要等待太长时间，这将导致 CPU 效率严重低下。

3.内存容量

如果计算机的任务需要更多的内存，但计算机内存容量不足，那么内存容量就会成为系统性能的瓶颈。

磁盘读写

通常情况下，磁盘是计算机中速度最慢的一个子系统，因此很多情况中，磁盘 I/O 会成为系统的瓶颈。

1.磁盘指标性能

使用率：是指磁盘处理 I/O 的时间百分比。一般超过 80% 就意味着磁盘性能瓶颈了。
饱和度：是指磁盘处理 I/O 的繁忙程度。当饱和度为100% 时，磁盘无法再接受新的 I/O 请求。
IOPS ：每秒的 I/O 请求数。
吞吐量：每秒的 I/O 请求大小。

2.磁盘读写分析

一般在数据库，大量小文件等这种随机读写比较多的场景，IOPS 可以更好反映出系统的整体性能。而多媒体等顺序读写较多的场景中，吞吐量才是重点。

网络流量

很多时候大家都容易忽略网络对系统的影响，实际上网络带宽在一些情况下也会成为系统的瓶颈。

1.流量与频率

应用程序处理的网络流量和频率，可以帮助您更准确地分析。例如平时流量不高，突然发生激增，可能由于大量请求或者后端服务器堵塞导致。

2.网络拓扑

可以通过应用程序的网络拓扑，包括所有网络设备、路由器和交换机，是否存在潜在的瓶颈。

检索异常日志信息

日常工作中需要不断地检索服务器、应用程序和设备的各种日志，以便了解其运作情况以及排除异常。其中，检索日志中的异常是一项非常重要也非常具有挑战性的任务。

确定日志范围

对于一个大型复杂的系统而言，会涉及到很多不同的日志文件，其文件格式和存储位置也可能各不相同。因此，正确的确定要检索哪些日志，需要综合考虑系统的结构和用途，以及具体的异常类型。常见的日志文件包括系统日志、应用程序日志、数据库日志、网络设备日志等。

日志分析工具

选择一个合适的日志分析工具是关键的一步。通常情况下，日志文件很大，要手动查找异常是非常困难的。而日志分析工具可以大大简化这个过程，它们可以根据我们设置的条件和规则，快速地搜索、过滤、分析和可视化日志信息，从而帮助我们快速地找到异常。

检索关键字

在使用日志分析工具前，我们需要准确地定义检索关键字，以确保能够查找到异常信息。这些关键字需要根据具体系统和异常类型进行设置。

Too many open files：句柄数限制，系统的默认值较小，可以适当调整，另外也要注意程序存在打开句柄却在某些情况下没有关闭的情况。
Out of memory：常见的内存溢出，应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存，此时程序就运行不了。
Connection refused：连接拒绝，一般是连接数限制不能承担当前的压力或者没有相关权限导致。