前端可用性保证实践

本文基于Infoq上发表的文章“美团出纳机前端可用性保证的实践”.

一般可用性是指后端服务的可用性. 他们都说我们的服务可用性达到了9个，很少有人将可用性放在首位. 实际上，对于具有UI交互过程的任何业务，都会有前端服务可用性，而后端可用性无论多么高. 如果在前端编写的按钮有问题，则单击而不起作用也将导致用户无法完成该过程.

前端服务的可用性包括三个部分:

从业务后台服务到用户界面，一切都是前端服务，用户可能遇到的所有问题都属于前端可用性.

这就是我们认为的前端可用性. 收银机的可用性构建围绕这三个部分.

前端服务的可用性度量与后端服务的度量方法相似. 它不考虑影响范围的大小，仅考虑发生故障的时间，并最大化可用性. 可用性指数不是通过复杂的算法来减少事故对可用性计算的影响，而是要激励我们在可观察范围内没有问题，越好越好. 影响用户数量，订单数量和GMV影响的指标更多地用于事故评分.

前端代码可用性:

静态资源服务可用性:

网络链接稳定性:

最大的问题是上述问题. 细节问题没有一一列出，那么我们该如何解决呢？

请记住，当我刚负责支付业务时，老板经常问一个问题: “如何保证收银机的稳定性？”我以为这很简单，只不过是过程保证，测试保证等，但这不是老板想要听到的，否则他不会总是问我，显然他没有回答他想要的答案. 现在，将其视为“太年轻太简单，有时会天真”.

在美团，收银机是一项横向业务基础服务，是所有业务的闭环链接. 所有业务交易的最终链接由收银机完成. 它的重要性不言而喻. 对于收银机，需要保证三点. 这三点是可用性，经验和安全性. 它们全都充当一个指标，即“付款成功率”. 其中，对支付成功率影响最大的是可用性.

可用性对付款成功率有多大影响？

即使发现一个小错误并及时回滚，它也可能造成数亿营业额的损失，这对于整个团队来说都是无法接受的. 因此，对于收银机，确保可用性是第一要务.

与此同时，作为特殊业务的支付对可用性有其独特的要求，就可用性保证而言，任何业务肯定都不会使用旧的东西. 老板想听到的是对稳定性保证，可重现性方法以及可用性保证的理论基础的独特见解，以便将来负责此业务的任何人都可以遵循处方并确保其稳定性. 前端服务.

总而言之，可用性保证分为三个阶段: *活动之前*活动期间*活动之后

保障措施分为三类: *软*硬*扎根

“软”是指受“人员”保护的部分: *工艺保证*标准保证*测试保证......

“硬”是指受“工程工具”保护的部分: *静态代码检查*单个测试* Web自动化测试*持续集成*前端异常监视*业务异常监视*前端服务异常监视*网络异常监控

“根”是整个可用性保证的核心，这意味着通过“技术选择”，系统将更加强大. 有两个核心要点.

需要避免基于可伸缩性的任何复杂且不可控制的技术解决方案. 对于核心链接上的所有代码，团队必须具有维护能力并减少外部依赖性.

这里有一个关键选择概念，即“场景匹配”. 技术选择不是您愿意使用的，不是您熟悉的，而是在此业务场景和团队规模中需要使用的技术.

例如，收银机是单页应用程序. 之所以将其设计为单页应用程序，是因为它涉及过多的视图跳转和数据传输. 单页应用程序具有优于多页的优势. 然后，在选择模型时，我们拥有诸如React，Angular，Ember等一线SPA框架，但最终我们自己制作了一个简单的视图生命周期管理工具. 为什么？

在收银机的SPA方案中，我们仅需要视图生命周期管理功能. 因此，我们参考Cocoa View Controller的生命周期设计来实现一个简单的单页视图工具“ Cyra”，该工具仅负责视图生命周期的管理，简单，可扩展性高，可以维护和维护源代码. 没有外部依赖性.

例如，有三种常见的方法可以优化网页第一帧的渲染: *手动预渲染*编译预渲染*服务器预渲染（SSR）

其优化的核心内容是在对第一个请求（即主文档请求）的响应中提供第一帧渲染所需的尽可能多的信息，以便用户可以尽快看到内容.

就优化效果而言，SSR效果最佳. 它可以通过第一个响应一起返回除JavaScript（以下称为“ JS”），CSS，HTML之外的动态数据.

但是，最终我们选择了编译和预渲染，为什么？

首先谈谈SSR. 这个概念是新提出的，但是原理已经存在很长时间了. 早期，诸如JSP和ASP之类的技术一直是SSR. 该页面在服务器端组装，并传递到客户端. 就像佛陀生活的三个境界一样，在禅宗中沉思之后，我又回过头来，就像当前的前端服务化难以达到Microsoft ASP.NET Web窗体的水平一样.

后来，前端产业发展迅速，发生了两个主要变化:

这时，使用SSR. 通常的做法是在服务器端添加一个Node层来缝合第一个屏幕内容，包括静态数据，这可以确保第一个帧渲染不仅快速，而且还包含第一个屏幕所需的数据. 其结构如下:

可以看出，节点层位于接口所请求的核心链接上. Node本身的可用性比上游和下游服务差很多. 它自身的稳定性需要许多其他工具来保证. 对于此业务，Node层已成为“核心链路上的可用性缺陷”，因此，即使其背后的各种后端系统的可用性很好，只要Node层挂起，也会导致用户无法进入.

因此反复出现您当前的网络存在链路层劫持，基于“避免在核心链接上使用的缺点”的考虑，我们转向“编译预渲染”，并在编译过程中组装了第一个屏幕结构，从而获得了可用性. 保证.

关于Node在服务器端的应用，我认为在大多数情况下，使用起来并不难. 有关此方面的一些想法，请参阅后续文章“为什么不能在服务器端使用节点”.

有了理论，我们该怎么做？

“软”过程规范部分将不予讨论，团队相似，但是完美与不完美之间的区别. 接下来，让我们谈谈“困难”部分.

如上所述，“硬”保证主要是指工程工具的保证手段. 有很多工程工具. 在这里，我们将根据上一篇文章中主要问题的顺序来讨论我们的解决方案.

前端代码的可用性部分具有三个容易出现问题的要点: 空指针，业务逻辑覆盖范围和兼容性.

“空指针”部分的解决方案只能从语言本身解决. JS本身是一种弱类型的动态语言，无法推断出在开发和编译过程中可能出现问题的地方. 为此，我们从2015年开始练习TypeScript（以下简称“ TS”）. 那时，我们还研究了Facebook的Flow，但当时Flow还不够成熟，因此没有被使用.

在引入TS之后，我们将弱类型语言更改为强类型语言. 从编码过程中，我们可以帮助滤除大部分空指针问题. TS强大的类型推导系统可以帮助我们分析系统中的null. 指针隐藏的麻烦，然后可以解决99％的空指针问题. 当然，TS还有许多其他好处，所以在这里我不会对其进行扩展.

这里将不再重复“业务逻辑覆盖率”问题的背景. 由于收银机的高度复杂性和很多情况，在复杂情况下很难模拟后端状态，因此只能使用自动化工具来解决. 参与了“ Web自动化过程测试”.

在这种情况下，除了验证案例的正确性之外，Web自动化过程测试的最重要功能是拥有一个异常强大的案例管理模块. 当前业界没有理想的工具来支持我们的方案.

在美团，有一个我们参与的Web自动化过程测试工具“ Freekite”. 基于案例验证功能，它具有功能强大的可视化案例管理模块，支持复杂的案例细分. 除了接口操作的细分之外，您还可以响应完整的Mock或部分Mock后端数据，并根据响应拆分不同的case分支. 此外，它还包括一个智能的自动断言功能，该功能基本上不需要人工干预.

有人可能会问，如果在记录这种情况后遇到界面的修订，该怎么办？没关系，尽管具有强大的相似性匹配功能，但Freekite还支持单个节点的重新记录反复出现您当前的网络存在链路层劫持，从而完美解决了案例维护问题，大大减少了工作量并提高了效率. 然后，我们将Freekite持续集成添加到项目中，并在项目的每个阶段对流程执行自动回归验证，从而基本解决了业务逻辑覆盖问题. 下图显示了Freekite可视化案例管理.

“兼容性”问题公司拥有一个云测试平台，该平台可以在多种真实机器模型上快速返回到主流程，并且可以通过云测试平台覆盖超过95％的各种模型. 但是，兼容性也相同. 您需要从根本上选择一个可靠的模型，以避免在处理兼容性问题时拆开东墙和修复西墙的尴尬情况. 兼容性问题主要出现在移动终端上的两种操作类型中: 布局和单击.

上述自主开发的单页视图工具以最简单的div隐藏显示模式处理视图切换，因此所有元素均处于正常文档流中，并且单击处理还通过分层降级来最大化平衡体验. 和兼容性，从而确保了整个项目的兼容性.

静态资源服务的可用性主要是NGINX层运行状况检查和CDN背对源的监视. 目前，该公司的SRE具有强大的系统支持（有关美团SRE的做法，请参阅上一篇博客文章），因此在此我就不再赘述. 也是.

DNS劫持是网络可用性中最成问题的问题. 如上所述，除恶意劫持外，DNS劫持主要涉及运营商执行DNS劫持，目的是节省跨省的流量结算费用. 当操作员系统发现HTTP访问的域名时，它将在该区域的服务器中缓存资源. 当后续用户再次请求时，域名解析将解析为运营商的服务器. 运营商的服务器将直接返回内容.

处理此问题的唯一方法是使用HTTPS，但它不仅像在原始域名HTTP的基础上切换HTTPS一样简单，而且还需要确保此域名不支持HTTP访问和尚未被HTTP大范围访问. 如果不这样做，将会出现问题. 操作员不知道在DNS解析过程中访问哪种协议的域名. 当记录到域名支持HTTP访问时，无论是否为HTTPS访问都将执行该域名. DNS劫持. 如果此时使用HTTPS访问，则无法建立请求，因为操作员的缓存服务器没有相应的SSL证书，并且请求失败. 服务之前切换到HTTPS时遇到此问题. 请求成功率从99.96％降低到96％. 解决问题花费了很多时间. 仅在切换到全新域名后，此问题才能解决.

事后看来，除了强大的支付后台业务系统监控之外，该公司还拥有一个全面的通用监控系统. 例如，异常监视系统可以分阶段和分批报告前端JS错误和自定义异常，而性能监视系统的Performance可以理解对前端访问情况执行性能分析. 网络监控系统CAT可以快速定位网络层性能状态和区域DNS劫持状态.

美团的前端技术专家Yuulin负责金融钱包和支付前端团队.

最后，我们正在招募人员. 美团金融服务平台正在招聘网络前端研发工程师. 我们欢迎希望越来越多的人加入，并将简历发送到chenyulin [at] outlook.com.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-271089-1.html