前端很多时候是不会接触到后端的工作，不过我们公司由于历史原因，维护了大量的 Node.js 服务。   所以也积累了一些后端优化的经验，主要分两块 Node.js 和数据库。 ## 一、Node.js   Node.js 的监控没有从 0 开始，业务逻辑的日志直接记录在阿里云中，性能监控部署的是阿里云提供的系统。   业务逻辑包括自定义的埋点，以及数据库的增删改查操作，还有内部接口访问的日志信息等。   在性能监控中，可以导出内存快照，方便排查内存泄漏的问题。 **1）服务**   Node.js 提供了定时任务、SSR、压缩图像、消息队列等服务。   定时任务可以将一些比较费时的计算按指定的间隔执行，以免直接访问造成接口的慢响应。   SSR 就是服务端渲染，是一种常见的页面优化手段，[qwik](https://qwik.builder.io/)是一款语法接近 React 的前端 SSR 框架。   其目标是延迟加载所有的代码，例如一个按钮在没有点击它之前，就不会去加载点击的逻辑，甚至不会去加载 React 相关的代码。   理念很好，但是 qwik 还不够稳定，应该会有比较多的坑。   消息队列是一种限流削峰的有效手段，一般由于瞬时访问量过大，导致流量暴增，系统无法处理请求甚至发生崩溃。   而在加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲，极大地减少了业务处理的压力。 **2）接口**   在业务迭代和人员流动的过程中，就会出现一些冗余接口，而这些接口的访问量还可能比较大。   在对业务进行分析后，可以将其合并到另一个接口中，或者就是将接口响应直接写到前端脚本中，直接减少一次通信。   比较影响接口查询时间的是与数据库的交互，可以减少交互次数，例如增加一层缓存，无必要就不去查询。   或者要查询多条记录时，用一条 SQL 语句完成，可以在 SQL 使用 in 语法，例如 select \* from user where id in (1,2,3)。   对于提交到服务器的数据，需要进行安全测试，即排除潜在隐患，防止刷接口，例如增加身份验证。   当代码出现异常时（例如调的内部接口没有响应），得避免接口奔溃，一直加载中，可以给到统一的响应。   在统一响应的 JSON 格式后（例如 { code:0, data: {}, msg: "xxx"}），就可以比较方便的统计接口异常和规范前端代码。   规定 code 为 0 是正常响应，非 0 为异常后，就能统计各种异常响应的数量以及占比，进行针对性的优化。   诸如监控、埋点等非业务且量比较大的接口，推荐单独分离出来（可根据请求路径进行服务转发），以免出现错误时，影响线上业务， **3）版本升级**   公司之前所有的 Node 项目，其环境都是 8.9.4 版本，发布于 2018 年的一个比较古老的版本。   老版本有两个比较明显的问题： 1. Node 高版本的特性和方法都无法使用。 2. 有些第三方新版本的包无法安装和升级，该包可能依赖比较高的 Node 版本。   之前在开发项目时就遇到第三方包自身的问题，必须升级或换个包才能解决，但因为 Node 版本的原因，无法替换，只能用其他方式来修补漏洞。   2022 年的 7 月份，才有机会将版本升级到 16.15，总共有 4 个 Node 环境需要升级。   在 4 个待升级的项目中，有 3 个是对外的项目，有 1 个是对内的项目。   那么先升级对内项目的 Node 版本，这样有两个好处： 1. 即使出问题了，影响范围也能最小。 2. 响应也能最及时，因为有问题的话，在公司内部能马上反馈到我们组。   我们每个项目都会有 3 套运行环境：测试、预发和生产。   首先将测试环境升级，测试环境都是开发人员使用，影响最小，反馈最快。   观察一段时间后，再升级预发，预发环境与生产环境最为接近，数据库采用的也是一套。   最后才是生产，给真实用户使用，再获取反馈。从开始升级到全部项目升级完成，前前后后操作了 20 多天。 **4）框架**   Node.js 的框架众多，公司使用的是 KOA2，它非常轻量，诸如路由、模板等功能默认都不提供，需要自己引入相关的中间件。   洋葱模型的中间件非常强大，我们将异常响应、身份验证、发送站内信等各类操作都交由中间件处理。   各类框架都有其自身的特点和适用场景，选择最合适自己团队的框架才是正解。   在公司的仓库中，发现之前有用基于 next.js 建立的一个 SSR 项目，不过后面没人维护，再之后就被运维释放掉了。   如果选择了某一框架，那还是要尽量维护起来，投入到实际生产中，发挥其作用。 ## 二、数据库   数据库被分为关系型和非关系型数据库，公司用的 MySQL 就属于前者，而 Redis、MongoDB、ElasticSearch 等数据库就属于后者。   线上数据库也需要有个监控平台运行着，了解数据库的 CPU，定位慢查询等。 **1）MySQL**   在某张表的数据量上去后，性能瓶颈就会浮现出来。   常见的优化包括创建索引、缩小查询范围等，利用执行计划，可以观察索引创建前后影响的行数。   每次索引创建后，都能提高几百、甚至几万倍的查询速度，当然，创建索引也是有讲究的，也不是随便创建的。   之前就遇到创建太长的索引，被拒绝了。   另一种优化手段是将数据归档，就是将比较旧或不用的数据迁移至别处，另一个数据库或直接下载到本地。   当然，将数据存储在云服务中，是会产生经济成本的，所以还有种办法就是直接删除，这类通常是冗余数据，不会用到。   对于非业务的数据表，也是像接口那样需要分离，以免出现容量上限、慢查询等问题而拖垮线上服务。 **2）MongoDB**   自研的前端监控系统中的表字段有很多是 JSON 格式，这类数据其实很适合存储在 MongoDB 中。   因为 MySQL 需要先将对象进行字符串序列化，然后再存储，而此时若需要以对象中的某个属性作为查询条件，MySQL 就难以实现了。   不过，最终并没有将数据存储在 MongoDB 中，因为云服务只提供了 MySQL 的可视化操作界面和监控平台。   为了便于自己排查异常，还是选择了 MySQL 作为存储媒介，但公司有许多遗留业务都存储在 MongoDB 中，日常还需要维护。   所以后期自研了 MongoDB 可视化查询工具，在后台可以查询线上的 MongoDB，省得每次都登录服务器查看。 **3）ElasticSearch**   当需要全文检索一张千万级的表时，在 MySQL 中实现就比较困难，很容易将数据库挂起，并且在 5.7.6 之前的 MySQL 还不支持中文检索。   此时可用[ElasticSearch](https://www.kancloud.cn/pwstrick/fe-questions/3210563)替代，这是一款基于 Lucene 的分布式、可扩展、RESTful 风格的全文检索和数据分析引擎，擅长实时处理 PB 级别的数据。   前端监控数据每日会增加 70W 条记录，在 ES 中用关键字检索这批数据会非常快。   若数据中有比较大的字段，那么生成的倒排索引也会比较巨大，当时我存储了接口的响应，结果整个容量直接膨胀了 3 倍。   若要联立好几张表的 MySQL 数据，那么也比较适合存到 ES 中。   例如用户发布的日志，分成了 100 张表存储在 MySQL 中，现在需要关键字检索，就可以将这 100 张表合并到 ES 中。 **4）Redis**   Redis 是一种支持 key-value 等多种数据结构的存储系统，基于内存，可持久化，用于缓存、消息队列、集群等场景。   Redis 之所以快，一方面是因为大部分操作在内存中完成，以及采用高效的数据结构，例如哈希表、跳表等。   另一方面，就是 Redis 采用了多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，实现高吞吐率。   而 Redis 的并发处理能力（每秒处理请求数）能达到万级别，甚至更高。   前面也讲到过，在接口中增加一层缓存，可加速接口响应，这也是缓存的常规用途，但是要注意，当缓存被穿透时，数据要能自动恢复。   也就是说，缓存不保障数据的一致性，不能因为缓存的异常，而影响线上业务，将错误信息存储到数据库中。   适当的将小部分特定的数据提前存入到 Redis 中，可起到预热的作用，增加体验。 ***** > 原文出处： [博客园-前端体验优化](https://www.cnblogs.com/strick/category/2360021.html) [知乎专栏-前端性能精进](https://www.zhihu.com/column/c_1610941255021780992) 已建立一个微信前端交流群，如要进群，请先加微信号freedom20180706或扫描下面的二维码，请求中需注明“看云加群”，在通过请求后就会把你拉进来。还搜集整理了一套[面试资料](https://github.com/pwstrick/daily)，欢迎阅读。  推荐一款前端监控脚本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不仅能监控前端的错误、通信、打印等行为，还能计算各类性能参数，包括 FMP、LCP、FP 等。