前端可用性

前端可用性

前端服务的可用性分为三个部分

• 前端代码可用性(测试质量，线上异常)
• 静态资源服务可用性
• 网络链路可用性 即从业务后台服务网上，一直到用户界面，一切都是前端服务。

如何衡量前端服务可用性

前端服务的可用性衡量和后端衡量方法类似，只考虑存在故障的时长。可用性指标不是为了让我们通过复杂算法来计算影响，而是为了激励我们再可观测范围内做到没有问题。影响用户数，影响订单数，影响GMV(Gross Merchandise Volume，订单总额)等指标更多的是用于事故定级。

哪里容易出问题

• 前端代码可用性：1.空指针问题。2.业务逻辑覆盖率，在复杂的业务项目中，逻辑混乱交错，逻辑环境难以模拟，进而容易在逻辑处理上产生疏忽。3.兼容性问题，要面临的环境很多，包括平台、系统版本、浏览器版本、webview版本，Hybrid桥版本等。
• 静态资源服务可用性：1. 前端静态资源服务链的稳定性，例如Nginx，Node等。2.CDN并不是任何时候都可以正常提供服务，可能会遇到SSL证书链问题等。
• 网络链路可用性：DNS劫持是一个麻烦问题，大部分运营商为了节省跨省流量结算费用而进行DNS劫持，走内部的缓存。

解决方案

• 技术选型要简单稳健，核心链路上的代码要减少外部依赖。举个例子，当一个应用涉及的视图跳转和数据传递太多时，单页应用比多页更具优势。而在SPA选型的时候，React，ng等一线框架可以选，但如果这个SPA应用中单个视图中的复杂度并不高，可以遇到的性能瓶颈并不多的时候，并不需要像React、ng这样更适合复杂大型单页应用的框架。如果使用自己封装的框架，我们就拥有更强的源码维护能力，这对于核心业务是非常必须的。
• 前端工程化的兴起导致大家会把所有文件打包到一个js文件中，HTML中只有js的引用，这样就导致HTML下载之后还是白屏。这时就用到了SSR(服务端渲染)，通用做法是增加一个Node层，在服务器端做首屏内容的拼接。或者使用预编译渲染，在编译期间把首屏结构全部拼装好。
• 空指针部分只能从语言本身解决，比如使用TypeScript,在编码过程中过滤掉空指针问题。
• 兼容性问题主要通过平台搭建，做到快速在多机型上进行核心流程回归测试。
• 解决DNS劫持只能通过使用HTTPS，并且要保证该域名不能被HTTP访问以免运营商进行DNS劫持。(使用HTTPS之后，如果运营商的缓存服务器没有SSL证书将会请求失败)