1、背景

我們所在的效能團隊，對這個需求最原始的來源是在一次“小項目”的評審中，增長的業(yè)務同學提出來的，目的在于保障前端頁面穩(wěn)定性的同時減少大量測試人力的回歸成本。

頁面穩(wěn)定性提升，之前迭代遇見過一些C端的線上問題，比如頁面白屏、頁面報錯等不同類型的問題，嚴重影響了用戶體驗，需要針對這一專項進行優(yōu)化，提高用戶體驗。

回歸投入成本大，H5頁面巡檢在用戶穩(wěn)定性提升上具有較大意義，在每個迭代大概有近十萬個頁面需要巡檢（比如雙旦、情人節(jié)等大促活動期間則更多）。

本文中的部分技術調研、演示代碼塊、疑惑問題等，均由ChatGPT提供

2、建設

開局先放一張平臺完整的使用流程圖（跟著箭頭的順序）

部門內以“小項目”的形式立項之后，我們就開始了巡檢平臺的建設。

首先是在業(yè)務目標方面

增長的測試同學作為業(yè)務方，給我們這個項目定了“三高”目標，大概可以概括為三高：“平臺使用效率高”、“巡檢執(zhí)行效率高”、“告警準確性高”。同時也很貼心的給我們列舉了大概需要的功能模塊一期巡檢平臺功能設計PRD

其次是在技術實現(xiàn)方面

我們當時備選的基礎語言語言有Python和Node，Python是我們比較熟悉的，在當時項目時間比較緊張的背景下Python看來是一個比較不錯的選擇；但考慮到要做的是前端巡檢，Node本身是一個基于Chrome V8引擎的JavaScript運行時，可以讓JavaScript在服務器端運行，在這個項目中的表現(xiàn)應該會比Python更友好一些，于是最終選擇了Node。

自動化測試工具方面，我認為仁者見仁智者見智，能為之所用的就是好工具，剩下的就是過程中“佛擋殺佛，鬼擋殺鬼”式地解決種種問題就是了。我挑選了幾個市面上常見的，問了下ChatGpt的意見，給大家參考。

2.1  性能

在原先回歸2000個頁面，要等1個多小時才知道結果，這顯然是不能滿足“巡檢執(zhí)行效率高”這個目標的；于是我們從架構上做了優(yōu)化，最終巡檢性能從0.4個頁面/秒提升到4個頁面/秒。

優(yōu)化前后的兩個方案對比流程圖如下

• 方案一的主要流程如下：

1. 任務啟動模式：支持手動、定時兩種
2. 下發(fā)任務：由巡檢后端調用巡檢器服務進行任務執(zhí)行，負載模式有ingress內部處理（輪詢）
3. 日志上報：巡檢完成后上傳日志，后臺更新任務狀態(tài)

• 方案二的主要流程如下：

1. 任務啟動模式：支持手動、定時兩種
2. 任務拆解：將任務關聯(lián)的url按一定大小拆分為一批子任務。比如一個任務有1000個url，每個子任務分配50個url，則會拆分為20個子任務，插入到子任務表
3. 巡檢器領取任務：每個pod循環(huán)調用領取任務接口，任務調度中心根據(jù)先進先出、任務狀態(tài)等邏輯返回子任務，未領取到任務則進入下一次循環(huán)
4. 日志上報：巡檢完成后上傳日志，后臺更新子任務狀態(tài)，當某個批次的子任務全部執(zhí)行完成后認為當次任務執(zhí)行完成

“方案二”相比于“方案一”，在以下4個方面帶來了改善

1. 解決pod單點負載過高的問題

由于“方案一”是由后端直接發(fā)起的任務，這個任務具體會由哪個巡檢器處理是未知的，完全交給容器的ingress負載均衡策略，容易造成某個pod被分配多個任務導致CPU飆升，其余pod卻是空閑情況；改成執(zhí)行器主動獲取之后就可以把每個資源都利用起來

2. 巡檢任務繁重時可動態(tài)擴容
3. 如果我們把壓力放到單個pod上面，就算增加再多的pod也是無效的，大概意思有點類似下圖

3. 多消費者模式加速任務執(zhí)行

理論上來說，只要我們多起幾個pod，就可以更快速地把任務隊列中的待巡檢URL執(zhí)行完成

4. 巡檢異常支持“斷點續(xù)傳”
5. 如下圖，如果因為巡檢器故障、容器重新部署、網(wǎng)絡等原因導致SUB_TASK_4執(zhí)行異常之后，后臺會有重試邏輯允許該任務可以被其他pod再次消費，已經(jīng)執(zhí)行的不會再次被執(zhí)行

這樣做了之后，從巡檢耗時、資源使用情況來看，都還算比較合理

2.2   穩(wěn)定性

我們想壓榨單個pod更大的資源進行巡檢任務處理，于是使用了一個主進程+多個子進程的方式來做，這樣在必要的時候，就可以在單pod上并行處理。但是在過程中發(fā)現(xiàn)了2個問題：

1. 子進程異常退出導致任務“無疾而終”

因為我對Node.js并不是很熟悉，查閱了資料之后發(fā)現(xiàn)通過child_process起子進程之后，主進程是可以通過事件注冊捕獲異常的。通過這個方法我們捕獲到了70%的進程異常退出事件，并將該事件上報給后端，做后續(xù)的處理

2. 子進程還是有30%的概率會異常退出

上面說到捕獲了70%的異常，剩下30%的異常退出更加隱蔽；表現(xiàn)就是毫無任何征兆的情況下，子進程就是會異常掛掉，top看了服務器進程也沒有發(fā)現(xiàn)zombie進程之類的，/var/logs/message下也沒有任何異常日志

甚至想過要不要在父子進程之間建立一個通信管道，或者加入supervisor進行?；?。最終湊巧使用fork解決了這個問題

3、合作

3.1  巡檢組件

我們相信個人的能力是有局限性的，開源+合作才是正確的思路。所以在該項目中，我們除了提供平臺的架構和基礎異常檢測服務，還和前端平臺合作，把巡檢器的巡檢能力做了豐富，比如會場抖動檢測、局部白屏等都是前端平臺貢獻的組件。

巡檢能力根據(jù)提供方，可分為2部分

• 平臺提供：由效能平臺提供常用的巡檢能力
• 三方提供：由前端平臺提供定制化巡檢能力，接入巡檢平臺的巡檢器中，目前已完成了6個巡檢組件的接入

巡檢能力Git demo、平臺適配及合作文檔巡檢功能拓展接入方案和demo

4、體驗

4.1  接入成本

此處感謝我們的業(yè)務方（增長域的質量同學），為我們的項目運營和接入提供了很大的支持，梳理了規(guī)范的接入手冊和運營機制，最終將一個新平臺的接入成本降低到很低。

由于B端頁面很多是需要登錄的，比如stark商家后臺、策略平臺、工單后臺等，為了B端巡檢的接入成本更低一下，我們還支持了在任務創(chuàng)建時使用SSO手機號的方式動態(tài)獲取登錄token，更復雜的登錄場景也支持設置“固定Token”，以此兼容所有場景

4.2  時間成本

迭代頁面回歸使用巡檢平臺解決，以往100個頁面需要60分鐘，現(xiàn)在僅需花10分鐘跟進巡檢報告，主要的時間可以用于其他質保工作。

4.3  排錯成本

高頻錯誤聚合，大大減少問題排查的時間，尤其是200+錯誤聚合。

5、后續(xù)規(guī)劃

5.1  前端頁面100%覆蓋

因為巡檢是一項低成本的質保手段，當前的巡檢器僅使用了20%左右的CPU資源。因此，我們有足夠的余地來執(zhí)行更多的巡檢任務。

考慮到生產(chǎn)環(huán)境中的頁面數(shù)量巨大，我們目前已經(jīng)單次回歸測試了超過數(shù)萬個H5頁面，還有許多B端頁面和渠道H5頁面，可以加入到巡檢中來。盡可能使用自動化的方式，為線上穩(wěn)定保駕護航。目前，我們已經(jīng)支持從監(jiān)控平臺拉取指定應用的實時流量巡檢。

5.2  小程序巡檢

在和業(yè)務方的交流中，我們也關注到線上小程序的冒煙點也是一個重頭，所以Q2我們也會在小程序巡檢方面做一些嘗試。爭取通過低人力投入、自動化的方式前置發(fā)現(xiàn)一些問題。

6、總結

以下總結80%由ChatGPT完成

總的來說，我們致力于為用戶提供更加穩(wěn)定、高效的前端巡檢體驗，減輕測試回歸成本帶來的負擔。在業(yè)務目標方面朝著“三高”目標持續(xù)迭代；巡檢性能從0.4個頁面/秒提升到4個頁面/秒，穩(wěn)定性方面也會持續(xù)關注。

該項目后續(xù)還會有一些工作需要完成，比如巡檢范圍的擴大、小程序巡檢的實現(xiàn)、巡檢組件的繼續(xù)完善等等。希望在團隊的共同努力下，為線上前端穩(wěn)定性和迭代回歸人效提升出一份力。