大厂都在做的前端稳定性到底是啥呢？

引言

在一次公司的前端无法访问的事故复盘后，我们调查了关于应用稳定性前端可以做些什么。对于前端稳定性其实在整个用户访问到页面到请求都需要全链路的监控与追踪，每一个环节都值得我们深入探究一下。本文就从应用服务器、静态资源、页面渲染、接口请求4大方面来各个击破，看看前端稳定性到底需要如何建设。

应用服务器

应用服务器在整个链路的最上游，从用户在地址栏输入域名访问后，流量通过网关（由于网关层的稳定性在大多数公司都不是由业务团队负责，本文暂略去这一部分，具体要做的和应用服务器相对也比较类似）进入到我们的应用服务器，如果我们应用服务器挂了，那么没有任何后续的稳定性可言了。

应用稳定性

应用稳定性指的是应用服务器运行的服务进程的稳定性。

对于普通的页面服务器来说，在应用稳定性层面上可以补充的是页面的访问日志（例如UA、IP等）。

而对于需要跑一个node服务的这种BFF的情形，应用稳定性可以做的事情就更多了，需要分等级的日志记录，异常抛出的监控，请求的响应速度的监控等，一般通过对应中间件进行处理与上报。

容器稳定性

目前云原生的环境下，应用服务器一般采用容器方式部署，部署平台一般会提供监控的基础设施，来监控容器的运行状态，如CPU、内存负载，内外网流量等。当这些数据出现异常值或者大幅波动时，就需要通过告警机制来通知到对应负责的同学，采取对应的措施，如重启、扩缩容等。

在部署应用时，一般我们可以跑多个容器来保证就算有一个容器挂了，用户还是可以访问到应用。如果将多个容器部署在不同的区域，可以规避例如断电、火灾等某个区域服务器集体宕机的风险，我们一般把这个措施叫做异地多活。

最后，我们的容器需要暴露端口从而让用户流量可以访问，那么我们就可以模拟用户的行为对服务器进行探活。如我们的容器就是作为一个页面服务器跑一个nginx，则定期轮询该nginx容器暴露的端口就可以探测我们的容器是否正在正常运行。

资源CDN加载

CDN容灾

美团在今年出了一套新的CDN容灾方案：Phoenix

在这套方案中，我们可以看到美团将CDN容灾分为5个部分：

1. 等效CDN服务
2. 端侧的重试和上报
3. 服务端侧通过上报信息动态计算CDN的优先级
4. 容灾监控平台
5. 容灾配置平台

美团将CDN的重试切流放在了端侧，因为端侧才是CDN真正的使用者，拥有CDN状态的第一手信息，服务端侧相对则更多负责对于端侧上报的数据进行汇总与动态调整的工作。

我们将美团端侧SDK的流程图贴在了下方，可以为我们做CDN容灾提供很多参考。

对于中小型的初创企业来说，建设一整套这样的全链路CDN容灾方案可能成本较高，能够快速入手的就是在端侧根据加载结果进行重试，重试失败进行告警，以及尽量选择稳定靠谱的CDN服务商。

画面渲染

错误收集

在画面渲染阶段，首先要做的是对JS的错误进行收集。目前通用的方案是采用sentry在JS抛出错误的时候进行上报。如果页面采用类似ErrorBoundary的形式拦截了错误，或catch了异常的话，需要在ErrorBoundary或catch块中人工进行上报。

同时，出于安全的考虑，在生产环境往往不会将sourcemap暴露给用户，而在生成的代码中直接进行问题定位溯源往往比较困难。解决方案是在构建时仍然先打出sourcemap，上传到sentry平台上，之后再将sourcemap删除。

需要注意的是，一些工具删除sourcemap的时候会将生成的代码中添加的sourcemap的引用也删除，这会导致代码变更，如果还在html的script标签采用integrity属性保证JS代码未被篡改的话integrity需要在sourcemap删除后计算。

错误处理

在上一part中，我们也提到了有ErrorBoundary这种来做错误处理的方式，让在有逻辑异常发生时用户的页面不至于白屏或者没有反应。在应用中，我们也可以做404的自定义页面，在用户发生这种情况时提供更友好的说明与返回路径。

接口

前端对于接口是消费方，如果只在后端进行接口问题日志的记录的话，会有幸存者偏差的可能。但是一般的超时或者500是不会触发sentry的上报机制的，所以我们可以在框架层面单独进行这些问题的告警，接口的报警的指定方可以设为后端同学。

而前端在请求不到后端的一些情况时来进行重试，是能提高用户体验的，类似超时或者服务器繁忙时，但是这需要前后端有良好的接口定义规范：

1. 遵循restful，post不是幂等，而get、put、delete等都为幂等，只对幂等请求进行重试
2. 错误码定义规范，规定什么类型的错误码可以重试，什么类型的不可以

报警

上述所有的监控措施最后能够被开发获知的途径就是通过报警。从一个角度来说，报警是本文中最容易的环节，对于研发侧来说只需要在报警平台上进行配置，用合适的方式将合适的错误通知到合适的开发/运维人员。然而，这一步其实又是最复杂的环节，需要各个应用根据自己的成熟度进行分析，对这三个“最合适”需要自己的度量。如果报警过于疏松，就可能会漏掉关键的错误导致线上问题未被发现；而如果报警过于密集，有许多误报，又会导致负责人看到报警变得松懈，达不到报警的目的。

以上就是我们总结的前端稳定性建设需要关注的各个方面以及对应需要采取的手段。前端稳定性是一个需要长期建设的环节，愿大家的应用都能够线上无bug，安稳每一天。