建站
咨詢
售后
建站咨詢
新聞中心
1、背景
我們所在的效能團(tuán)隊(duì)，對這個(gè)需求最原始的來源是在一次“小項(xiàng)目”的評審中，增長的業(yè)務(wù)同學(xué)提出來的，目的在于保障前端頁面穩(wěn)定性的同時(shí)減少大量測試人力的回歸成本。
創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括元氏網(wǎng)站建設(shè)、元氏網(wǎng)站制作、元氏網(wǎng)頁制作以及元氏網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，元氏網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到元氏省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
頁面穩(wěn)定性提升，之前迭代遇見過一些C端的線上問題，比如頁面白屏、頁面報(bào)錯(cuò)等不同類型的問題，嚴(yán)重影響了用戶體驗(yàn)，需要針對這一專項(xiàng)進(jìn)行優(yōu)化，提高用戶體驗(yàn)。
回歸投入成本大，H5頁面巡檢在用戶穩(wěn)定性提升上具有較大意義，在每個(gè)迭代大概有近十萬個(gè)頁面需要巡檢（比如雙旦、情人節(jié)等大促活動期間則更多）。
本文中的部分技術(shù)調(diào)研、演示代碼塊、疑惑問題等，均由ChatGPT提供
2、建設(shè)
開局先放一張平臺完整的使用流程圖（跟著箭頭的順序）
部門內(nèi)以“小項(xiàng)目”的形式立項(xiàng)之后，我們就開始了巡檢平臺的建設(shè)。
首先是在業(yè)務(wù)目標(biāo)方面
增長的測試同學(xué)作為業(yè)務(wù)方，給我們這個(gè)項(xiàng)目定了“三高”目標(biāo)，大概可以概括為三高：“平臺使用效率高”、“巡檢執(zhí)行效率高”、“告警準(zhǔn)確性高”。同時(shí)也很貼心的給我們列舉了大概需要的功能模塊一期巡檢平臺功能設(shè)計(jì)PRD
其次是在技術(shù)實(shí)現(xiàn)方面
我們當(dāng)時(shí)備選的基礎(chǔ)語言語言有Python和Node，Python是我們比較熟悉的，在當(dāng)時(shí)項(xiàng)目時(shí)間比較緊張的背景下Python看來是一個(gè)比較不錯(cuò)的選擇；但考慮到要做的是前端巡檢，Node本身是一個(gè)基于Chrome V8引擎的JavaScript運(yùn)行時(shí)，可以讓JavaScript在服務(wù)器端運(yùn)行，在這個(gè)項(xiàng)目中的表現(xiàn)應(yīng)該會比Python更友好一些，于是最終選擇了Node。
自動化測試工具方面，我認(rèn)為仁者見仁智者見智，能為之所用的就是好工具，剩下的就是過程中“佛擋殺佛，鬼擋殺鬼”式地解決種種問題就是了。我挑選了幾個(gè)市面上常見的，問了下ChatGpt的意見，給大家參考。
2.1 性能
在原先回歸2000個(gè)頁面，要等1個(gè)多小時(shí)才知道結(jié)果，這顯然是不能滿足“巡檢執(zhí)行效率高”這個(gè)目標(biāo)的；于是我們從架構(gòu)上做了優(yōu)化，最終巡檢性能從0.4個(gè)頁面/秒提升到4個(gè)頁面/秒。
優(yōu)化前后的兩個(gè)方案對比流程圖如下
- 方案一的主要流程如下：
- 任務(wù)啟動模式：支持手動、定時(shí)兩種
- 下發(fā)任務(wù)：由巡檢后端調(diào)用巡檢器服務(wù)進(jìn)行任務(wù)執(zhí)行，負(fù)載模式有ingress內(nèi)部處理（輪詢）
- 日志上報(bào)：巡檢完成后上傳日志，后臺更新任務(wù)狀態(tài)
- 方案二的主要流程如下：
- 任務(wù)啟動模式：支持手動、定時(shí)兩種
- 任務(wù)拆解：將任務(wù)關(guān)聯(lián)的url按一定大小拆分為一批子任務(wù)。比如一個(gè)任務(wù)有1000個(gè)url，每個(gè)子任務(wù)分配50個(gè)url，則會拆分為20個(gè)子任務(wù)，插入到子任務(wù)表
- 巡檢器領(lǐng)取任務(wù)：每個(gè)pod循環(huán)調(diào)用領(lǐng)取任務(wù)接口，任務(wù)調(diào)度中心根據(jù)先進(jìn)先出、任務(wù)狀態(tài)等邏輯返回子任務(wù)，未領(lǐng)取到任務(wù)則進(jìn)入下一次循環(huán)
- 日志上報(bào)：巡檢完成后上傳日志，后臺更新子任務(wù)狀態(tài)，當(dāng)某個(gè)批次的子任務(wù)全部執(zhí)行完成后認(rèn)為當(dāng)次任務(wù)執(zhí)行完成
“方案二”相比于“方案一”，在以下4個(gè)方面帶來了改善
- 解決pod單點(diǎn)負(fù)載過高的問題
由于“方案一”是由后端直接發(fā)起的任務(wù)，這個(gè)任務(wù)具體會由哪個(gè)巡檢器處理是未知的，完全交給容器的ingress負(fù)載均衡策略，容易造成某個(gè)pod被分配多個(gè)任務(wù)導(dǎo)致CPU飆升，其余pod卻是空閑情況；改成執(zhí)行器主動獲取之后就可以把每個(gè)資源都利用起來
- 巡檢任務(wù)繁重時(shí)可動態(tài)擴(kuò)容
- 如果我們把壓力放到單個(gè)pod上面，就算增加再多的pod也是無效的，大概意思有點(diǎn)類似下圖
- 多消費(fèi)者模式加速任務(wù)執(zhí)行
理論上來說，只要我們多起幾個(gè)pod，就可以更快速地把任務(wù)隊(duì)列中的待巡檢URL執(zhí)行完成
- 巡檢異常支持“斷點(diǎn)續(xù)傳”
- 如下圖，如果因?yàn)檠矙z器故障、容器重新部署、網(wǎng)絡(luò)等原因?qū)е耂UB_TASK_4執(zhí)行異常之后，后臺會有重試邏輯允許該任務(wù)可以被其他pod再次消費(fèi)，已經(jīng)執(zhí)行的不會再次被執(zhí)行
這樣做了之后，從巡檢耗時(shí)、資源使用情況來看，都還算比較合理
2.2 穩(wěn)定性
我們想壓榨單個(gè)pod更大的資源進(jìn)行巡檢任務(wù)處理，于是使用了一個(gè)主進(jìn)程+多個(gè)子進(jìn)程的方式來做，這樣在必要的時(shí)候，就可以在單pod上并行處理。但是在過程中發(fā)現(xiàn)了2個(gè)問題：
- 子進(jìn)程異常退出導(dǎo)致任務(wù)“無疾而終”
因?yàn)槲覍ode.js并不是很熟悉，查閱了資料之后發(fā)現(xiàn)通過child_process起子進(jìn)程之后，主進(jìn)程是可以通過事件注冊捕獲異常的。通過這個(gè)方法我們捕獲到了70%的進(jìn)程異常退出事件，并將該事件上報(bào)給后端，做后續(xù)的處理
- 子進(jìn)程還是有30%的概率會異常退出
上面說到捕獲了70%的異常，剩下30%的異常退出更加隱蔽；表現(xiàn)就是毫無任何征兆的情況下，子進(jìn)程就是會異常掛掉，top看了服務(wù)器進(jìn)程也沒有發(fā)現(xiàn)zombie進(jìn)程之類的，/var/logs/message下也沒有任何異常日志
甚至想過要不要在父子進(jìn)程之間建立一個(gè)通信管道，或者加入supervisor進(jìn)行?；?。最終湊巧使用fork解決了這個(gè)問題
3、合作
3.1 巡檢組件
我們相信個(gè)人的能力是有局限性的，開源+合作才是正確的思路。所以在該項(xiàng)目中，我們除了提供平臺的架構(gòu)和基礎(chǔ)異常檢測服務(wù)，還和前端平臺合作，把巡檢器的巡檢能力做了豐富，比如會場抖動檢測、局部白屏等都是前端平臺貢獻(xiàn)的組件。
巡檢能力根據(jù)提供方，可分為2部分
- 平臺提供：由效能平臺提供常用的巡檢能力
- 三方提供：由前端平臺提供定制化巡檢能力，接入巡檢平臺的巡檢器中，目前已完成了6個(gè)巡檢組件的接入
巡檢能力Git demo、平臺適配及合作文檔巡檢功能拓展接入方案和demo
4、體驗(yàn)
4.1 接入成本
此處感謝我們的業(yè)務(wù)方（增長域的質(zhì)量同學(xué)），為我們的項(xiàng)目運(yùn)營和接入提供了很大的支持，梳理了規(guī)范的接入手冊和運(yùn)營機(jī)制，最終將一個(gè)新平臺的接入成本降低到很低。
由于B端頁面很多是需要登錄的，比如stark商家后臺、策略平臺、工單后臺等，為了B端巡檢的接入成本更低一下，我們還支持了在任務(wù)創(chuàng)建時(shí)使用SSO手機(jī)號的方式動態(tài)獲取登錄token，更復(fù)雜的登錄場景也支持設(shè)置“固定Token”，以此兼容所有場景
4.2 時(shí)間成本
迭代頁面回歸使用巡檢平臺解決，以往100個(gè)頁面需要60分鐘，現(xiàn)在僅需花10分鐘跟進(jìn)巡檢報(bào)告，主要的時(shí)間可以用于其他質(zhì)保工作。
4.3 排錯(cuò)成本
高頻錯(cuò)誤聚合，大大減少問題排查的時(shí)間，尤其是200+錯(cuò)誤聚合。
5、后續(xù)規(guī)劃
5.1 前端頁面100%覆蓋
因?yàn)檠矙z是一項(xiàng)低成本的質(zhì)保手段，當(dāng)前的巡檢器僅使用了20%左右的CPU資源。因此，我們有足夠的余地來執(zhí)行更多的巡檢任務(wù)。
考慮到生產(chǎn)環(huán)境中的頁面數(shù)量巨大，我們目前已經(jīng)單次回歸測試了超過數(shù)萬個(gè)H5頁面，還有許多B端頁面和渠道H5頁面，可以加入到巡檢中來。盡可能使用自動化的方式，為線上穩(wěn)定保駕護(hù)航。目前，我們已經(jīng)支持從監(jiān)控平臺拉取指定應(yīng)用的實(shí)時(shí)流量巡檢。
5.2 小程序巡檢
在和業(yè)務(wù)方的交流中，我們也關(guān)注到線上小程序的冒煙點(diǎn)也是一個(gè)重頭，所以Q2我們也會在小程序巡檢方面做一些嘗試。爭取通過低人力投入、自動化的方式前置發(fā)現(xiàn)一些問題。
6、總結(jié)
以下總結(jié)80%由ChatGPT完成
總的來說，我們致力于為用戶提供更加穩(wěn)定、高效的前端巡檢體驗(yàn)，減輕測試回歸成本帶來的負(fù)擔(dān)。在業(yè)務(wù)目標(biāo)方面朝著“三高”目標(biāo)持續(xù)迭代；巡檢性能從0.4個(gè)頁面/秒提升到4個(gè)頁面/秒，穩(wěn)定性方面也會持續(xù)關(guān)注。
該項(xiàng)目后續(xù)還會有一些工作需要完成，比如巡檢范圍的擴(kuò)大、小程序巡檢的實(shí)現(xiàn)、巡檢組件的繼續(xù)完善等等。希望在團(tuán)隊(duì)的共同努力下，為線上前端穩(wěn)定性和迭代回歸人效提升出一份力。
本文名稱：得物前端巡檢平臺的建設(shè)和應(yīng)用（建設(shè)篇）
文章出自：http://www.5511xx.com/article/cdciddc.html
