億級流量下，京東 H5 應用的可觀測性是如何建設的？

本文根據演講者在 GOPS 2023 · 深圳站演講整理而成，如有圖文不妥，請以視頻爲準。更多精彩，請關注高效運維公衆號。

一、京東 H5 觀測體系的背景

目前主流移動端開發模式已經成爲 Native+H5 來進行 Hybrid APP 開發。

H5 有其優勢，如跨平臺開發效率高、更新迭代方便；但同時也有劣勢，比如用戶體驗不如原生頁面、H5 工程質量難以把控等。

京東在落地 H5 業務過程中發現一些問題：

綜上所述，線上用戶體驗問題如果發現和處理不及時，都會造成用戶流失。

京東是如何解決的

基於上面的背景，京東自建了一套 UEM 觀測平臺，分三個階段。

二、深度主動觀測

主動觀測基建

主動觀測其實並不複雜，主要是做好三方面基建。

  1. 是從用戶頁面 Js 探針收集指標，建設成衡量標準；

  2. 是上報到日誌服務端；

  3. 是通過數據清洗、流轉、加工，存儲到存儲介質，最落到觀測平臺實現看板及價值的體現。

H5 探針指標建設

我們經常碰到就是指標建設是基於什麼來實現的？我認爲指標建設應該服務於度量標準，應該先將度量標準確定下來，然後根據標準相關的指標因子進行採集。

京東的用戶體驗指標分爲兩塊：綜合性能評分和異常率。

如圖所示，評分依託性能指標點，然後向上提煉出來綜合評分體系。另一塊是 H5 體現出來異常率指標。

綜合性能評分算法

綜合性能評分算法借鑑了谷歌的 lighthouse 評分算法並它進行擴展提煉。

右圖上每個性能指標可進行可配置項，配置權重和性能良好閾值和較差閾值，通過左邊的單指標評分算法進行入參輸入，輸出單指標分數，結合權重計算總分。

這個標準在於實際推的過程中也發現一些問題，H5 涉及的場景比較多，京東的做法是結合專家經驗及實際現狀設計對應評分標準，在前端通道里面推廣。前面提到爲什麼採集這些指標，跟標準有關；我們採集這些指標更能代表真實的用戶體驗。

H5 探針質量保障

真實落地時階段我們也做了質量保障，輸出兩個 S、兩個 O。

日誌服務端架構

觀測平臺在大促期間需重點發力，一方面需要防止大促期間服務被打穿，另一方面是存儲端的設計與容災，還需要滿足不同人羣的查詢統計需求。

因此我們設計了上面右圖這套架構，從上往下從移動端請求流轉到服務端，再通過 NSQ 消息隊列解耦轉發給各服務。

其中也涉及一些業務配置，比如京東自研 DUCC、觀測平臺自身 API 服務。

存儲層根據不同查詢需求做了分類，比如原始日誌存到 ES，通過冷熱數據節點降低成本、擴充數據體量。MySQL 主要用於結果集，Clickhouse 用大規模聚合查詢，大促期間全量數據存到 CK 裏方便後續業務發展。

在這個過程中發現業務方會經常關注我們的排障能力，所以我們設計了一套 Sourcemap 堆棧反解析方案，通過自研 Webpack/rollup 打包插件。業務研發通過在本地 CICD 打包過程中，會把 Sourcemap 產物上傳到雲對象存儲 OSS 上，業務研發排障過程中就會請求 Node.js 反解析服務，去拉對應版本文件進行反解析。

如果不這樣做，業務研發每次發版會走一遍觀測平臺上傳對應 Sourcemap 文件，再去反解析，因此在這裏做了一些提效工作。

說到觀測，不得不提到異常告警。因爲 H5 發版頻繁，發佈新版本以後可能產生新的異常信息，因爲我們做了首次異常告警，提示用戶進行檢查，是不是因爲新版本發佈導致異常。

我們將異常信息字段進行關聯，綜合製成 Event id。如果新增 Event id 出發告警，通知業務方去看一下是不是因爲新版本迭代導致新的異常。

第二塊告警是我們建立的一套分鐘級閾值告警配置，支持各維度，以及告警指標裏面涉及異常量、異常用戶數等進行閾值告警，推送給告警接收人，同時生成一系列工單，我們去追蹤。

觀測平臺建設誤區

回到觀測平臺，大家經常有一些建設誤區，比如以下幾種：

分享一個我們認爲較爲正確的思路。我們在建設平臺初期拉通了兩端，前端委員會以及 QA 共同設立內部用戶體驗標準，建立指標體系。目標建設成統一自循環可觀測平臺體系。

用戶反饋平臺進行半自動化生成工單、體驗工單，後續根據工單推進業務研發，與 QA 協同起來解決工單問題。這方面是漸進式，最終還是要落地到業務，在過程中碰到業務問題，根據業務計劃完善平臺，最終目標是深入到業務，主動輔助業務排障，做技改優化，實現最終價值，提高工單解決率和推動技改落地數。

工單案例

給大家介紹一些工單案例。

618 期間用戶反饋頁面加載慢，拉齊 QA、業務研發一起協同治理加載慢的問題，最終通過指標模型發現綜合評分比較差。看了一下指標，發現有幾個指標非常差，經過社區及業界優化方案進行單指標優化，比如骨架屏提升，渲染提升單指標值。

這是優化效果，實際用戶體驗提升。左邊這張圖是 Plus 頁面一開始的狀態，首屏進來再也不是白屏，右邊通過性能友好，把首屏加載時間從 1.98 秒提升到 1.68 秒。

第二個案例是觀測平臺賦能技改項目，打通 CMS 搭建過程中，發現有些項目 CDN 節點異常，觸發告警，拉其運維、研發協同治理 CDN 資源容災，增加重試機制，重試之後進行結果上報，彙總到觀測平臺進行數據收集。這也是體現業務技改產出的效果。

通過觀測輔助他們度量城市成功率達到 70% 以下，整體成功率提升 0.3%，原始值已經比較高了，達到 99%。這個案例體現觀測平臺三個價值，觀測平臺發現問題能力，協助業務技改項目的能力，度量技改優化效果能力。

三、自動化被動觀測帶來的降本提效

做完主動觀測發現還是有些問題沒有解決，比如業務研發反饋侵入式探針接入成本比較高，線上非異常業務問題感知不到，比如運營配置頁面突然下線導致 404，這種情況導致探針都沒有加載到，通過主動觀測方式觀測不出來。

因此設計了一套被動觀測體系去做延伸，增強觀測覆蓋面積，提升測試人效。

落地方案是先調研了檢測引擎，目前定下來 Puppeteer、Lighthouse，通過 Node.js 在服務端進行檢測，能獲取到用戶性能數據。

第二個步驟是我們沒有立即去做平臺可配置化落地，我們回顧主動觀測，進行數據及配置上的打通，比如業務標識、頁面資源池，不需要讓業務研發進行多餘配置，直接在探針上報池子裏面去找就行了。

被動觀測的核心能力

被動觀測核心能力目前覆蓋 50 項，一是功能問題檢測，一是性能問題檢測。

功能問題檢測主要覆蓋一些場景，活動已經過期，404 找不到，通過 Puppeteer 的爬蟲能力清楚知道是不是 404 出發告警，通知業務方整改。

性能問題也可以通過 Puppeteer 去做一些頁面打開，資源監控。看是否超過閾值，或者資源傳輸沒有通過壓縮，這些都可以檢測出來。

檢測效率保障

如何保障檢測效率，現狀大概 10 臺 8C12G 容器承載每天差不多 10 萬 + URL 檢測任務。

第一通過多 chrome 進程戶用、多 Page 架構，讓單機腳本機承載頁面更多。

第二減少無用進程數，減少 IPC 通信消耗，有些進程其實不需要拉起，通過調參優化，通過 Websocket 進行 chrome 進行串聯。

第三是精細化調控方向，比如業務問題檢測其實用不到比較高規格的機器，就用低規格機器形成腳本機農場。性能問題檢測涉及 CPU 敏感，我們需要服務端模擬終端機型，我們用到中規格機器。大促期間如何重保高頻業務檢測需求，需要通過資源傾斜、Serverless 自動擴縮容進行橫向拓展。

業務問題檢測案例

接下來分享一個真實的檢測案例。

某次活動現場，從 APP 分享 H5 頁面到微信小程序的量級過大導致小程序卡片被封，但問題是從用戶側反饋得知的。

事後覆盤確定兩個方向：1、事前監控，通過加上 APP 端分享點擊埋點，按照分享總量進行閾值告警通知，如果達到業務預警值會推動業務進行切量，從微信小程序轉到 H5。

2、事後監控通過被動觀測、線上定製巡檢，模擬用戶使用場景，通過 OCR 文字識別進行掃描告警。

性能問題檢測案例

第二個案例是性能檢測案例，被動觀測和主動觀測進行對齊，統一出一個標準，度量頁面性能健康度。通過注入探針 JS 獲取用戶體驗的基礎值，根據標準算出總分。

既然觸發了告警，就要告訴他們如何優化建議。我們結合 Lighthouse 性能分析能力，獲取優化建議。比如右下角這張圖，可以看到圖片大小有問題，可以幫助業務方進行整改。

四、全鏈路觀測及質量保證實踐與思考

京東內部 H5 貫徹體系全鏈路主要針對客戶端場景，做了單用戶單會話維度，通過鏈路各維度數據進行開素排障分析；包括客戶端基礎信息、用戶反饋、崩潰、網絡等進行數據串聯，通過時間線維度觀測發生異常前後用戶客戶端的路徑及現場情況，這個功能在公司用的比較多，排障時會比較方便。

另外我們做了延伸，針對用戶體驗性能優化，以性能優化爲導向，我們做了全鏈路觀測，按照業務發佈流程，一方面發佈前如何做質量門禁，另外一方面是在線上如何做埋點檢測以及自動化掃描。

我們羅列了 4 個環節，都涉及質量體系，Webview、CDN 加載情況，可以輸入看一下在哪個環節還缺少，進行查缺補漏。沒有接入 Hybrid 離線包，性能比較差的情況下，推動他們接入離線包能力，提升性能。

H5 全鏈路質量保障能力分爲兩個，即上線前質量門禁檢測和上線後的日常巡檢。

上線前的質量門禁檢測，主要是通過被動觀測能力，包括性能檢測、合規檢測、安全檢測等進行能力輸出，輸出給前端發佈系統、jenkins 流水線原子能力形式集成到發佈前檢測。

業務上線後要做的事情就是日常巡檢，比如我們在進行檢測和埋點數據結合，前面提到量變進行打通，檢測可以直接配置埋點監控頁面，通過統一標準體系進行檢測。這是一塊比較普遍的能力。題外話，還有一塊能力，這個平臺影響力，我們還做了一些事情，在大促 618 期間做質量綜合日報，輸出平臺能力，增加影響力，推動業務方每日進行問題整改。

簡單總結，根據之前提到的這些環節，我們先做了主動觀測，更進一步實現被動觀測提效，結合共識，統一標準輔助業務，以全鏈路觀測爲目標，最終實現 H5 應用質量保障。

本次分享到此結束，謝謝！

作者簡介：

沈亞，京東資深技術專家，負責京東客戶端及跨端技術的可觀測平臺建設與實踐，主導設計並完成 Hybrid/H5 監控能力從 0 到 1 的落地，經歷多次 618, 雙 11 以及春晚核心活動億級別流量的考驗。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/EhVw9-58IbtMcXeMM1_gYA

猜你喜歡