得物前端巡檢平臺的建設和應用實踐

　　 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個頁面/秒。

　　最佳化前後的兩個方案對比流程圖如下

　　方案一的主要流程如下：

　　任務啟動模式：支援手動、定時兩種

　　下發任務：由巡檢後端呼叫巡檢器服務進行任務執行，負載模式有ingress內部處理（輪詢）

　　日誌上報：巡檢完成後上傳日誌，後臺更新任務狀態　　

　　方案二的主要流程如下：

　　任務啟動模式：支援手動、定時兩種

　　任務拆解：將任務關聯的url按一定大小拆分為一批子任務。比如一個任務有1000個url，每個子任務分配50個url，則會拆分為20個子任務，插入到子任務表

　　巡檢器領取任務：每個pod迴圈呼叫領取任務介面，任務排程中心根據先進先出、任務狀態等邏輯返回子任務，未領取到任務則進入下一次迴圈

　　日誌上報：巡檢完成後上傳日誌，後臺更新子任務狀態，當某個批次的子任務全部執行完成後認為當次任務執行完成　　

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

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

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

　　巡檢任務繁重時可動態擴容

　　如果我們把壓力放到單個pod上面，就算增加再多的pod也是無效的，大概意思有點類似下圖　　

　　多消費者模式加速任務執行

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

　　巡檢異常支援“斷點續傳”

　　如下圖，如果因為巡檢器故障、容器重新部署、網路等原因導致SUB_TASK_4執行異常之後，後臺會有重試邏輯允許該任務可以被其他pod再次消費，已經執行的不會再次被執行　　

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

　　

　　2.2 穩定性

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

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

　　因為我對Node.js並不是很熟悉，查閱了資料之後發現透過child_process起子程式之後，主程式是可以透過事件註冊捕獲異常的。透過這個方法我們捕獲到了70%的程式異常退出事件，並將該事件上報給後端，做後續的處理　　

　　子程式還是有30%的機率會異常退出

　　上面說到捕獲了70%的異常，剩下30%的異常退出更加隱蔽；表現就是毫無任何徵兆的情況下，子程式就是會異常掛掉，top看了伺服器程式也沒有發現zombie程式之類的，/var/logs/message下也沒有任何異常日誌

　　甚至想過要不要在父子程式之間建立一個通訊管道，或者加入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個頁面/秒，穩定性方面也會持續關注。

　　該專案後續還會有一些工作需要完成，比如巡檢範圍的擴大、小程式巡檢的實現、巡檢元件的繼續完善等等。希望在團隊的共同努力下，為線上前端穩定性和迭代迴歸人效提升出一份力。