关于前端:得物前端巡检平台的建设和应用

1. 背景

咱们所在的效力团队，对这个需要最原始的起源是在一次“小我的项目”的评审中，增长的业务同学提出来的，目标在于保障前端页面稳定性的同时缩小大量测试人力的回归老本。页面稳定性晋升 ，之前迭代遇见过一些 C 端的线上问题，比方页面白屏、页面报错等不同类型的问题，重大影响了用户体验，须要针对这一专项进行优化，进步用户体验。 回归投入老本大，H5 页面巡检在用户稳定性晋升上具备较大意义，在每个迭代大略有近十万个页面须要巡检（比方双旦、情人节等大促流动期间则更多）。

> 本文中的局部技术调研、演示代码块、纳闷问题等，均由 ChatGPT 提供

2. 建设

开局先放一张平台残缺的应用流程图（跟着箭头的程序）

部门内以“小我的项目”的模式立项之后，咱们就开始了巡检平台的建设。

首先是在业务指标方面

增长的测试同学作为业务方，给咱们这个我的项目定了“三高”指标，大略能够概括为三高：“平台应用效率高”、“巡检执行效率高”、“告警准确性高”。同时也很贴心的给咱们列举了大略须要的功能模块一期巡检平台功能设计 PRD

其次是在技术实现方面

咱们过后备选的根底语言语言有 Python 和 Node，Python 是咱们比拟相熟的，在过后我的项目工夫比拟缓和的背景下 Python 看来是一个比拟不错的抉择；但思考到要做的是前端巡检，Node 自身是一个基于 Chrome V8 引擎的 JavaScript 运行时，能够让 JavaScript 在服务器端运行，在这个我的项目中的体现应该会比 Python 更敌对一些，于是最终抉择了 Node。

自动化测试工具方面，我认为仁者见仁智者见智，能为之所用的就是好工具，剩下的就是过程中“佛挡杀佛，鬼挡杀鬼”式地解决种种问题就是了。我筛选了几个市面上常见的，问了下 ChatGpt 的意见，给大家参考。

2.1  性能

在原先回归 2000 个页面，要等 1 个多小时才晓得后果，这显然是不能满足“巡检执行效率高”这个指标的；于是咱们从架构上做了优化，最终巡检性能从 0.4 个页面 / 秒晋升到 4 个页面 / 秒。

优化前后的两个计划比照流程图如下

• 计划一的次要流程如下：

  1. 工作启动模式：反对手动、定时两种
  2. 下发工作：由巡检后端调用巡检器服务进行工作执行，负载模式有 ingress 外部解决（轮询）
  3. 日志上报：巡检实现后上传日志，后盾更新工作状态

• 计划二的次要流程如下：

  1. 工作启动模式：反对手动、定时两种
  2. 工作拆解：将工作关联的 url 按肯定大小拆分为一批子工作。比方一个工作有 1000 个 url，每个子任务分配 50 个 url，则会拆分为 20 个子工作，插入到子工作表
  3. 巡检器支付工作：每个 pod 循环调用支付工作接口，任务调度核心依据先进先出、工作状态等逻辑返回子工作，未支付到工作则进入下一次循环
  4. 日志上报：巡检实现后上传日志，后盾更新子工作状态，当某个批次的子工作全副执行实现后认为当次工作执行实现

“计划二”相比于“计划一”，在以下 4 个方面带来了改善

1. 解决 pod 单点负载过高的问题

   1. 因为“计划一”是由后端间接发动的工作，这个工作具体会由哪个巡检器解决是未知的，齐全交给容器的 ingress 负载平衡策略，容易造成某个 pod 被调配多个工作导致 CPU 飙升，其余 pod 却是闲暇状况；改成执行器被动获取之后就能够把每个资源都利用起来

2. 巡检工作沉重时可动静扩容

   1. 如果咱们把压力放到单个 pod 下面，就算减少再多的 pod 也是有效的，大略意思有点相似下图

3. 多消费者模式减速工作执行

   1. 实践上来说，只有咱们多起几个 pod，就能够更疾速地把工作队列中的待巡检 URL 执行实现

4. 巡检异样反对“断点续传”

   1. 如下图，如果因为巡检器故障、容器重新部署、网络等起因导致 SUB\_TASK\_4 执行异样之后，后盾会有重试逻辑容许该工作能够被其余 pod 再次生产，曾经执行的不会再次被执行

这样做了之后，从巡检耗时、资源应用状况来看，都还算比拟正当

2.2   稳定性

咱们想压迫单个 pod 更大的资源进行巡检工作解决，于是应用了一个主过程 + 多个子过程的形式来做，这样在必要的时候，就能够在单 pod 上并行处理。然而在过程中发现了 2 个问题：

1. 子过程异样退出导致工作“无疾而终”
2. 1. 因为我对 Node.js 并不是很相熟，查阅了材料之后发现通过 child_process 起子过程之后，主过程是能够通过事件注册捕捉异样的。通过这个办法咱们捕捉到了 70% 的过程异样退出事件，并将该事件上报给后端，做后续的解决

2. 子过程还是有 30% 的概率会异样退出

   1. 下面说到捕捉了 70% 的异样，剩下 30% 的异样退出更加荫蔽；体现就是毫无任何征兆的状况下，子过程就是会异样挂掉，top看了服务器过程也没有发现 zombie 过程之类的，/var/logs/message下也没有任何异样日志
   2. 甚至想过要不要在父子过程之间建设一个通信管道，或者退出 supervisor 进行保活。最终凑巧应用 fork 解决了这个问题

3. 单干

3.1  巡检组件

咱们置信集体的能力是有局限性的，开源 + 单干才是正确的思路。所以在该我的项目中，咱们除了提供平台的架构和根底异样检测服务，还和前端平台单干，把巡检器的巡检能力做了丰盛，比方会场抖动检测、部分白屏等都是前端平台奉献的组件。

巡检能力依据提供方，可分为 2 局部

• 平台提供：由效力平台提供罕用的巡检能力
• 三方提供：由前端平台提供定制化巡检能力，接入巡检平台的巡检器中，目前已实现了 6 个巡检组件的接入

巡检能力 Git demo、平台适配及单干文档巡检性能拓展接入计划和 demo

4. 体验

4.1  接入老本

此处感激咱们的业务方（增长域的品质同学），为咱们的我的项目经营和接入提供了很大的反对，梳理了标准的接入手册和经营机制，最终将一个新平台的接入老本升高到很低。

因为 B 端页面很多是须要登录的，比方 stark 商家后盾、策略平台、工单后盾等，为了 B 端巡检的接入老本更低一下，咱们还反对了在工作创立时应用 SSO 手机号的形式动静获取登录 token，更简单的登录场景也反对设置“固定 Token”，以此兼容所有场景

4.2  工夫老本

迭代页面回归应用巡检平台解决，以往 100 个页面须要 60 分钟，当初仅需花 10 分钟跟进巡检报告，次要的工夫能够用于其余质保工作。

4.3  排错老本

高频谬误聚合，大大减少问题排查的工夫，尤其是 200+ 谬误聚合。

5. 后续布局

5.1  前端页面 100% 笼罩

因为巡检是一项低成本的质保伎俩，以后的巡检器仅应用了 20% 左右的 CPU 资源。因而，咱们有足够的余地来执行更多的巡检工作。

思考到生产环境中的页面数量微小，咱们目前曾经单次回归测试了超过数万个 H5 页面，还有许多 B 端页面和渠道 H5 页面，能够退出到巡检中来。尽可能应用自动化的形式，为线上稳固保驾护航。目前，咱们曾经反对从监控平台拉取指定利用的实时流量巡检。

5.2  小程序巡检

在和业务方的交换中，咱们也关注到线上小程序的冒烟点也是一个重头，所以 Q2 咱们也会在小程序巡检方面做一些尝试。争取通过低人力投入、自动化的形式前置发现一些问题。

6. 总结

> 以下总结 80% 由 ChatGPT 实现

> 总的来说，咱们致力于为用户提供更加稳固、高效的前端巡检体验，加重测试回归老本带来的累赘。在业务指标方面朝着“三高”指标继续迭代；巡检性能从 0.4 个页面 / 秒晋升到 4 个页面 / 秒，稳定性方面也会继续关注。

> 该我的项目后续还会有一些工作须要实现，比方巡检范畴的扩充、小程序巡检的实现、巡检组件的持续欠缺等等。心愿在团队的共同努力下，为线上前端稳定性和迭代回归人效晋升出一份力。

文：卢克

线下流动举荐：

工夫： 2023 年 6 月 10 日（周六）14:00-18:00主题： 得物技术沙龙总第 18 期 - 无线技术第 4 期 地点： 杭州·西湖区学院路 77 号得物杭州研发核心 12 楼培训教室（地铁 10 号线 &19 号线文三路站 G 口出）

流动亮点： 本次无线沙龙聚焦于最新的技术趋势和实际，将在杭州 / 线上为你带来四个令人期待的演讲话题，包含：《抖音创作工具 -iOS 功耗监控与优化》、《得物隐衷合规平台建设实际》、《网易云音乐 - 客户端大流量流动的日常化保障计划实际》、《得物 Android 编译优化》。置信这些话题将对你的工作和学习有所帮忙，咱们期待着与你独特探讨这些令人兴奋的技术内容！

点击报名： 无线沙龙报名

本文属得物技术原创，来源于：得物技术官网

未经得物技术许可严禁转载，否则依法追究法律责任！