紅魔電競平板評測：大屏幕硬實力
前言：三年的疫情因為要上網(wǎng)課的原因激活了平板市場，如今網(wǎng)課的時代已經(jīng)過去，大家的生活都恢復(fù)到了正軌，這也就意味著，真正考驗平板電腦生存的環(huán)境來了。也就是面對著這種殘酷的
圖1：分層監(jiān)控
物理層監(jiān)控：對IaaS層硬件指標(biāo)進(jìn)行監(jiān)控，如CPU使用率、網(wǎng)絡(luò)IO、RAM使用量等Metrics類型的數(shù)據(jù)。主流做法是使用Agent程序采集硬件指標(biāo)，再將這些指標(biāo)數(shù)據(jù)存入時序數(shù)據(jù)庫，再定期檢索指標(biāo)數(shù)據(jù)，通過判斷閾值的方式觸發(fā)報警。
中間件監(jiān)控：對PaaS層中間件指標(biāo)進(jìn)行監(jiān)控，如Web Server吞吐、JVM內(nèi)存使用情況、RDMS QPS數(shù)等。實現(xiàn)方案與物理層類似，如Prometheus社區(qū)提供各種中間件的指標(biāo)收集程序(Exporter)，通過Service Mesh模式采集指標(biāo)。
應(yīng)用監(jiān)控：主要對應(yīng)用的運行日志進(jìn)行監(jiān)控，包括：程序日志、訪問日志、調(diào)用鏈日志等。程序日志一般在程序運行時上報，而訪問日志大多由Web Server自動收集，調(diào)用鏈日志由框架(如：Skywalking)自動采集，然后將這些離散數(shù)據(jù)存入分布式數(shù)據(jù)庫(如：ES)，監(jiān)控程序通過定期檢索日志進(jìn)行監(jiān)控。
業(yè)務(wù)流程監(jiān)控：監(jiān)測業(yè)務(wù)鏈路是否通暢，與上述幾種監(jiān)控方式不同，業(yè)務(wù)流程監(jiān)控通常不具備通用性。常見的做法有兩種：
(1)提供業(yè)務(wù)接口，該接口內(nèi)提供完整的業(yè)務(wù)操作和校驗流程，通過對接口返回內(nèi)容進(jìn)行解析，判斷業(yè)務(wù)是否正常。筆者支持的某個業(yè)務(wù)依賴第三方OCR識別駕照的服務(wù)，該服務(wù)經(jīng)常出現(xiàn)接口正常返回，但是圖片內(nèi)容無法識別的問題，為了及時發(fā)現(xiàn)服務(wù)異常，可以通過接口的形式，周期性將一張已知駕照圖片提交給接口，通過解析識別結(jié)果判斷服務(wù)是否正常。
(2)通過直接檢索業(yè)務(wù)數(shù)據(jù)庫，業(yè)務(wù)完整性，之家內(nèi)部的鷹眼系統(tǒng)提供了通過直接執(zhí)行sql進(jìn)行監(jiān)控的能力，通過解析ResultSet實現(xiàn)業(yè)務(wù)監(jiān)控的方案。如常見的留資業(yè)務(wù)，系統(tǒng)收到用戶的留資數(shù)據(jù)后，需要通過定時任務(wù)對線索信息進(jìn)行補(bǔ)齊，然后再執(zhí)行外呼清洗和推送流程。那么就可以通過檢索原始線索數(shù)據(jù)是否完整，清洗記錄表、推送記錄表是否存在關(guān)聯(lián)數(shù)據(jù)記錄，從而判斷流程完整性。
UI監(jiān)控：通過對頁面展示內(nèi)容、交互流程進(jìn)行監(jiān)控，確保頁面正常工作。UI離用戶最近，最能直接影響用戶體驗，同時，由于網(wǎng)絡(luò)環(huán)境復(fù)雜，設(shè)備版本差異，UI問題出現(xiàn)頻繁。常見的UI監(jiān)控包含插件監(jiān)控和UI自動化兩種，下面給大家詳細(xì)介紹一下。
插件監(jiān)控主要通過在H5中引入js腳本，通過JS收集頁面中的錯誤和性能數(shù)據(jù)，再將數(shù)據(jù)上報到ES集群中，通過檢測日志實現(xiàn)錯誤報警，比如之家內(nèi)部的ftwo系統(tǒng)。這種監(jiān)控方式存在不足：
1. 時效性低，只有在用戶訪問頁面時，監(jiān)控程序才會開始工作，因而無法早于用戶發(fā)現(xiàn)問題;
2. 網(wǎng)絡(luò)或機(jī)房故障類型錯誤無法檢測，頁面返回404或502，頁面未加載的情況下， 無法監(jiān)控異常;
3. 局限性：只能發(fā)現(xiàn)腳本、網(wǎng)絡(luò)等通用錯誤，無法對業(yè)務(wù)邏輯和頁面內(nèi)容進(jìn)行監(jiān)控。
使用pupputeer等無頭瀏覽器，通過Python、nodejs等腳本語言，構(gòu)建case，這種主動探測的監(jiān)控方式比較常見，檢測精度高，但是學(xué)習(xí)和維護(hù)成本高。
基于以上分析，需要實現(xiàn)完善的UI可用性監(jiān)控，使用UI自動化無疑是更好的選擇，但是其高昂的case維護(hù)成本，導(dǎo)致其在筆者所在的業(yè)務(wù)沒有被廣泛應(yīng)用。那么有沒有一種兼顧有效性和低成本UI監(jiān)控方案呢?
UI自動化的核心思路是通過腳本語言模擬一系列的人工操作，實現(xiàn)自動化人工頁面巡檢的操作，在這里，我們不妨抽象一下用戶巡檢的流程：
1. 打開F12，用于觀察是否存在腳本或網(wǎng)絡(luò)錯誤;
2. 輸入網(wǎng)址，觀察網(wǎng)頁是否正常打開;
3. 查看頁面內(nèi)容，確定內(nèi)容是否正確;
4. 與頁面交互(滑動、點擊、輸入)后，觀察頁面反饋是否正常;
webeye系統(tǒng)是一個基于用戶巡檢的核心思路，通過headless browser實現(xiàn)一套配置式的UI自動化的低代碼平臺。webeye中有兩個核心概念：“動作”及“校驗器”：
動作：模擬一系列用戶操作，如：打開頁面、鼠標(biāo)滾動、內(nèi)容查找、用戶點擊、用戶輸入等。
校驗器：通過監(jiān)測頁面運行中的頁面錯誤或非預(yù)期內(nèi)容，從而觸發(fā)報警。包括全局校驗器與動作校驗器。全局校驗器貫穿在整個頁面生命周期中，如圖片加載失敗，js錯誤等，動作校驗器是對某個具體用戶動作產(chǎn)生的結(jié)果進(jìn)行校驗，如打開頁面后，判斷可見DOM數(shù)量是否符合預(yù)期等。
動作與校驗器的關(guān)系如圖二所示：
圖2：用戶動作與校驗器
上文提到，webeye中存在動作和校驗器兩個核心概念：動作和校驗器。校驗器分為全局校驗器和動作校驗器，動作校驗器是對具體動作執(zhí)行后的結(jié)果進(jìn)行校驗，所以我們先介紹一下全局校驗器，后面介紹動作時，同時介紹關(guān)聯(lián)的動作校驗器。
?全局校驗器
http狀態(tài)碼校驗器(http_status_error)：捕捉頁面生命周期內(nèi)非200的http請求;
網(wǎng)絡(luò)請求錯誤(network_error)：監(jiān)聽生命周期內(nèi)全部失敗的http請求，它與http_status_error核心區(qū)別是http_status_error關(guān)注response中的狀態(tài)碼，network-error更加關(guān)注請求本身，如域名DNS解析錯誤、CORS請求失敗等;
API請求錯誤(api_error)：xhr接口內(nèi)容監(jiān)控，之家內(nèi)部使用的接口協(xié)議均包含returncode 字段，可以通過檢測 returncode 的值是否0從未判斷接口是否異常;
js錯誤(js_error)：頁面生命周期內(nèi)的js錯誤。
? 動作及動作校驗器
打開頁面(load)：通過puppeteer打開指定URL，并等待加載完成。動作校驗器有：可見dom數(shù)量(visible_dom_count)，即頁面加載完成后，檢測可見dom數(shù)量是否達(dá)到閾值。在SPA應(yīng)用中，經(jīng)常出現(xiàn)因CDN異常，后臺配置錯誤等導(dǎo)致頁面白屏或一直loading：
圖3：可見dom數(shù)量校驗報警
內(nèi)容查找(query_dom)：通過指定的選擇器選擇進(jìn)行dom查找，并將查找結(jié)果暫存供檢驗。query_dom有兩個動作校驗器：匹配元素數(shù)量(query_dom_count)及匹配內(nèi)容(query_dom_content_contains)。query_dom_count用來校驗匹配的元素數(shù)量，如某商品面，校驗SKU數(shù)量是否符合預(yù)期。query_dom_content_contains用來校驗查找結(jié)果中是否包含具體文本內(nèi)容，如某次業(yè)務(wù)上線，導(dǎo)致頁面?zhèn)€別模塊展示開關(guān)失效，該模塊直接消失：
圖4：內(nèi)容匹配失敗報警
鼠標(biāo)滾動(mouse_wheel)：在垂直方向上模擬鼠標(biāo)滾動指定距離。
用戶點擊(user_click)：模擬指定DOM元素的點擊。
用戶輸入(user_input)：模擬文本框內(nèi)容輸入。
如圖5所示，是一個典型的留資場景的業(yè)務(wù)，我們以它為例，看看配置一個UI監(jiān)控有多簡單。
圖5：留資業(yè)務(wù)頁面示意圖
動作1：執(zhí)行l(wèi)oad，地址為https://m.autohome.com.cn/some_query，校驗器：visible_dom_count閾值設(shè)置為10(根據(jù)頁面元素多少，動態(tài)設(shè)置)，該步驟可校驗頁面是否正常打開并正確顯示內(nèi)容;
動作2：執(zhí)行dom_query，選擇器為“span.series_name”，校驗器query_dom_content_contains校驗是否存在文本“沃爾沃CX60”;
動作3：執(zhí)行user_input，選擇器為“input.user_name”，內(nèi)容為“之家車友007”;
動作4：執(zhí)行user_input，選擇器為“input.mobile”，內(nèi)容為“18123456678”;
動作5：執(zhí)行user_click，選擇器為“button.btn-submit”;
動作6：執(zhí)行dom_query，選擇器為“span.success_tip”，校驗器query_dom_content_contains校驗是否存在文本“預(yù)約成功”;
使用低代碼配置界面，只需要簡單的幾步，就可以完成的校驗案例，除了監(jiān)控頁面中網(wǎng)絡(luò)、腳本、API異常外，還可以監(jiān)控整個留資業(yè)務(wù)流程，配置界面所下圖所示：
圖6：低代碼配置界面
最終生成如下的配置JSON:
圖7：留資業(yè)務(wù)監(jiān)控配置
最后給大家介紹一些webeye系統(tǒng)在落地過程中遇到的問題及解決方案。
webeye系統(tǒng)設(shè)計之初是為了滿足本業(yè)務(wù)常見的線上問題，所以支持的動作和校驗器數(shù)量不多，只包含了一些常見的功能。不過webeye在設(shè)計上就使用了類似模版方法的設(shè)計模式，實現(xiàn)新的動作和校驗器只需要簡單提供一個function，就可以直接通過名稱注冊時動作庫中。
webeye中很多動作需要指定DOM選擇器，如下圖所示，若需要點擊“活動專區(qū)”后的“查看更多”文字鏈，傳統(tǒng)的選擇器就無法準(zhǔn)確選擇目標(biāo)元素。這里我們就需要一種類似于XPath的增強(qiáng)選擇器(puppeteer原生支持XPath，但是考慮到使用成本，我們沒有直接使用)，webeye通過獨立的模塊對DOM選擇器做了增強(qiáng)，通過".more_message[0]"就可以輕松選擇到該元素。
圖8：一個頁面存在多個相同元素
webeye通過headless browser訪問頁面，不可避免的會產(chǎn)生訪問流量，從而影響實際的業(yè)務(wù)統(tǒng)計，我們的做法是通過黑名單機(jī)制對指定流量URL進(jìn)行屏蔽，實踐中，我們屏蔽了ftwo-receiver.autohome.com.cn以及al.autohome.com.cn兩個域名，分別對性能監(jiān)控和流量采集進(jìn)行屏蔽。
本文簡單介紹了筆者所理解的體系化監(jiān)控架構(gòu)，并詳細(xì)介紹了webeye UI自動化低代碼平臺的設(shè)計思路及使用方法。目前，平臺已覆蓋筆者所在業(yè)務(wù)90%以上核心C端頁面，單個頁面平均接入時間3分鐘。上線兩個月發(fā)現(xiàn)4個線上問題，占全部線上問題的50%，C端問題的80%。下一步我們將繼續(xù)豐富平臺能力及易用性。webeye系統(tǒng)本身并不復(fù)雜，更多的希望給各位讀者帶來一些UI自動化思路。
本文鏈接：http://www.www897cc.com/showinfo-26-6168-0.htmlUI自動化低代碼平臺webeye在數(shù)科業(yè)務(wù)的應(yīng)用
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 高并發(fā)場景下的性能優(yōu)化：解析RabbitMQ的性能調(diào)優(yōu)策略
下一篇： 利用 GetUserMedia 和 MediaRecorder API 玩轉(zhuǎn)音頻錄制、播放和下載
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號