來源：京東技術

導讀

本文基於JDV平臺在大促中的各種業務場景，講解過程中使用情況和技術挑戰，透過採取相應的技術創新、技術保障確保系統穩定性，推動資料視覺化編排能力在大屏業務場景中發揮更大的價值。

01 

專案介紹

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

JDV（視覺化大屏）是京東內部搭建視覺化大屏的資料工具平臺，內建10+種模版特效，40+種風格各異的圖表、導航等元件。與集團其他資料工具打通，支援一站式、自助化、拖拽式搭建大屏，實現資料切換、聯動重新整理、大屏下鑽等呈現效果，便利高管、採銷、產研等全集團範圍內的資料視覺化訴求。在大促期間京東視界大屏專案，主要服務作戰指揮、慶功會、公關場景，實現在大促期間實時資料監控分析，並基於大屏資料進行決策和總結，同時在公關場景下實現對外部媒體、政府、外部企業領導參觀，協助公關部對外宣傳公司的良好形象。

02 

  

專案挑戰

  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

JDV作為視化大屏搭建平臺，平臺主要由視覺化編排和後端服務組成，由於大屏在頁面中渲染後會透過指定重新整理頻率主動獲取資料，每次在頁面中渲染後就是一個獨立執行例項，系統具體架構如下圖所示。

圖1.系統具體架構示意

• 基於視覺化大屏特點，為了解決大屏在使用過程中能夠滿足秒級更新、跨0點停數、指標資料快速調整、資料高穩定性、備用屏秒級切換等業務場景需要JDV平臺能夠足夠靈活，具體場景細節如下：
• 資料秒級更新：秒級資料重新整理對底層資料服務壓力較大，我們使用請求隔離、限流等技術手段對大屏請求實現高可用保障，實現全鏈路讀寫真實場景多次高保真壓測提前發現並解決鏈路效能問題，並針對QPS高峰等有足夠預案處理。
• 跨0點停數：針對週期累計的資料來講處於臨界點也是突變點，0點過後資料介面會重新開始新週期累計，我們必須在多服務多機房多容器存在系統時間偏差場景中精準停數。
• 資料快速調整：在大促期間經常需要根據業務看數需求緊急快速調整，當前基於我們PaaS大屏搭建方案，能保證90%以上需求調整能在分鐘內調整完並交付使用。
• 資料高穩定性：大屏一般會投放在高管作戰指揮室、各業務線指揮室等，我們要以高質量交付，方便業務基於實時資料調整，避免跳數、重新整理異常等問題影響業務看數，從而錯過最佳決策時間。
• 備用大屏切換：在搭建大屏過程需要考慮線上和線下大屏使用過程中出現的問題情況，所有在搭建大屏過程除了需要搭建預估場景下使用的大屏外，還需要搭建部分備用屏及拖底屏，確保在大促期間所有大屏的使用都萬無一失。

基於以上大屏在大促期間使用場景，本次618大促期間相關挑戰也是非常大，主要在大屏搭建量大、使用場景複雜多變、時間緊任務重等方面，具體如下：

• 大屏搭建量大：在大促期間需要搭建大屏資料較多，過程中還需要根據大促場景隨時增加大屏數量，大促期間共搭建了80+張大屏，搭建大屏過程中由於大屏涉及相關人員較多，在大促期間溝通成本巨大，從4月底開始陸續評審需求後，5月初就需要完成作戰指揮大屏配合全鏈路壓測，京東視界和公關屏逐步進行搭建，過程中大屏需求須隨時響應調整。
• 場景複雜多變：大促期間主要分為作戰指揮、慶功會、公關大屏3類大屏，每類大屏又涉及各種使用場景，在本次大促過程中開門紅後大屏還緊急支援了28H大屏跨0點停數、615高潮期累計、28H實時訂單累計、618晚宴等場景。

• 時間緊任務重：大屏搭建整體時間範圍在1個月左右，需要完成與業務方溝通確認細節、完成三方介面和三方屏人員質量把控以及完善平臺不同場景相關預案並確認預案操作人等事項，預案涉及跨0點停數、制定大屏限流、代理資料來源管控、雙流切換、線下斷網停數、裝置切換等不同場景下團隊聯動演練。

03 

  

技術創新

  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

基於JDV平臺在大促期間的重要性及上面提到的各種挑戰，在大促前期3月底就已梳理規劃對平臺進行大促技改事項，主要目的是提升大屏在複用性、實時監控、請求鏈路合理性、QPS管控等方向能力建設，下面將重點介紹平臺在請求狀態控制和實時監控方向的思考及技術方案。

3.1  請求狀態管控

    

背景：定時重新整理和資料秒級更新是大屏的一個重要能力，大屏編排過程中能夠靈活指定資料重新整理間隔，當開屏的數量增加都會提升底層資料服務QPS壓力，考慮到大屏定時傳送請求的特殊性，可以透過控制頁面資料請求輪詢機制，來避免使用者未看大屏情況下定時請求問題。

方案：在該場景下需要透過實現大屏狀態識別能力來控制大屏是否定時傳送請求，當頁面不在當前視窗、頁面隱藏、視窗最小化等非活躍狀態時，識別頁面渲染例項狀態動態控制對服務端傳送請求機制，透過該方案在一定程度上降低大屏對資料服務QPS壓力。

3.2  大屏例項監控

    

背景：JDV平臺是基於編排能力搭建大屏，在系統監控上除了需要接入各種泰山平臺監控功能外，同時也要解決降低相同大屏請求QPS、確保不同使用者在相同時刻訪問的資料一致。為了解決該場景，JDV後端服務採用代理資料來源獲取資料方式，為了確保資料請求準確無誤需要對大屏渲染例項進行實時監控，實時瞭解使用者使用大屏情況、不同使用者同時開啟大屏數量、對資料服務QPS請求壓力等資料的呈現，基於大屏實時使用情況決定是否需要採取預案處理。

圖2.心跳上報流程

方案：基於以上大屏使用場景，對大屏渲染例項的實時監控將是非常非常重要功能，為了方便基於大屏實時監控進行異常預案決策，在本次618大促前我們已增加了大屏實時監控能力，該功能也被團隊內部認為是監控能力細化的升級版。具體方案流程如“心跳上報流程”圖所示，對例項監控的思路主要是基於socket長連線心跳機制（它像心跳一樣每隔固定時間傳送一次，以此來告訴伺服器當前客戶端還活著）的借鑑，基於socket心跳上報機制和JDV大屏專案的使用場景透過在頁面前端收集使用者賬號、版本號、IP地址、大屏ID編碼、大屏例項ID、大屏互動引數、訪問端標識等資訊，大屏前端元件將相應心跳上報引數統一進行維護，在指定的上報時間後將會進行心跳上報，同時服務端接收到心跳資訊後與代理資料來源任務進行關聯實時維護任務的存活狀態。

圖3.

基於心跳上報資料為基礎，將心跳上報日誌資訊進行分析彙總實時掌握每張大屏當前的開屏使用者數、開屏例項數、開屏例項數與預估峰值佔比、任務建立等資訊，具體效果如“實時監控與預案聯動效果”圖所示，並基於每張大屏異常情況決策是否需要進行預案聯動處理。

04 

  技術保障  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

JDV平臺為了應對各種業務場景，除了上面提到的技術創新方面來保障系統質量外，還在大屏影片錄製、編排輔助工具、跳數停止更新、跨0點精準停數、代理資料來源任務等方面分別輔助編排提效以及系統質量保障，具體細節如下：

4.1  大屏影片錄製

    

背景：JDV 京東視界場景中跨0點停數及倒數計時功能線上下場景使用，即便我們已經進行了相對完備的解決方案，但還需要每次等到凌晨進行功能驗證，將極大消耗團隊成員時間和精力。

方案：為更好的對停數和倒數計時功能進行驗證，透過指定大屏訪問連結和時間建立錄製任務，設計出 JDV 錄屏功能。當任務到達指定時間後將進行大屏錄製，並將錄製的影片儲存儲到OSS，這樣就可以實現對指定時間的大屏進行錄製。在這套錄製系統的配置下，我們透過影片回放進行功能測試和驗證，確保了大屏停數和倒數計時功能準確性，極大減少了成員時間和精力的消耗，保障了618慶功宴停數場景的順利完成。

4.2  編排輔助工具

    

背景：JDV京東視界場景中需求變化頻繁，需要對大屏內容進行相應的調整，而且需要保證極快的響應，在極端場景下還需要對大屏佈局進行重構，由於大量編排配置調整後需要快速進行交付使用，所以需要解決需求修改後能高效確認配置的正確性，避免修改錯誤影響正常使用。

方案：為減少重複工作提高響應效率，我們開發出一些工具提高在大屏編排過程中的工作效率，具體如下：

1.JDV-Relay 瀏覽器外掛，實現一鍵複製 Relay 元素尺寸、位置、樣式、屬性等配置資訊，可以直接將其貼上到大屏中，可以一鍵貼上完成配置，將之前10多項的配置節省到一次複製貼上中，極大減少了配置的時間，提高了搭屏的效率。

2.JDV 批次元件修改功能，可以搜尋大屏中匹配的元件，並進行統一的修改，可一次修改批次同步操作相關元件需求變更。

3.JDV DIFF工具，在大屏搭建過程中為保障配置的正確性，建立了更改通知機制，一旦釋出後的大屏需要修改，將採用DIFF工具對新舊版本的配置進行比對，並針對改動內容標記凸顯出來，快速識別其中改動內容確保改動的正確性。

4.3  跳數停止更新

    

背景：因為大屏資料秒級重新整理，在當前使用場景和分散式微服務場景下，任何跨時間週期、服務或網路抖動等問題在大屏上都能被使用者感知影響系統穩定性，造成使用者體驗差資料不準確等問題。

方案：JDV採用未獲取新資料不更新資料機制，利用該機制解決偶發性抖動造成跳數問題，確保JDV大促依賴的10多個團隊幾十個資料介面整個鏈路服務返回統一狀態碼，透過對錯誤或異常狀態返回狀態碼進行區分，實現對資料是否更新準確控制。

4.4  跨0點精準停數

    

背景：大屏展示某個累計週期統計資料，線上下慶功會場景需要在週期結束最後一秒進行停數。大屏涉及零售、科技、物流等集團多業務線幾十資料介面方，介面實現邏輯、介面協議、部署方式等都不統一，並且系統時間理論上不能保證百分之百無差異，如果不能精確停數會導致資料變小、跳0等突變情況，如果停數異常將造成重大事故。

方案：停數問題核心就是精準和穩定平衡關係，精準主要指資料是否能無限接近獲取最後一秒真實值，穩定是指能不能100%停到下個累計週期開始之前。因為最後一秒是臨界點也是突變點，我們透過監控系統時間偏差和各介面TP99，經過多次演練和測試驗證，最終設定一個毫秒級兼顧精準和停數穩定的時間點。

4.5  代理資料來源任務

    

背景：大屏秒級重新整理機制，是前端元件定時固定間隔發起批次資料請求，這個機制情況下會隨著開屏數量增加，對底層資料服務請求QPS線性增長。

方案：透過分析發現大多數大屏請求具有共性，不同人開啟同一個屏，看到往往是同一份資料。基於這個特性，實現了代理資料來源功能，對不同人開屏請求進行合併，在後臺生成一個查詢任務定時獲取資料，將資料寫入快取，大屏直接查詢快取中的資料，從而避免多個相同請求對DB或底層資料服務造成查詢壓力。

05 

  總結&反思  

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目

基於本次618大促JDV平臺支援大促過程中的表現，共從大促總結、能力沉澱、待提升項3個方向也進行了相應總結和反思。

5.1  大促總結

    

針對這次大屏在大促期間能快速響應完美支援大促場景，透過提前識別大促技改、系統多場景預案、技術方案上的創新、ISV人員介入、真實場景演練以及底層PaaS化和配置化能力快速響應緊急需求等密切相關。在大促前能提前規劃和識別出根本問題，遇到難點能夠透過採用創新方案，精準識別出技改功能點，在系統保障機制等方面起到了非常關鍵的作用。具體細節如下：

• 識別大促技改：主要在大促前期研發已經識別出歷來大促過程中的痛點，透過對大屏元件升級、QPS請求管控、代理資料來源任務實時管控等功能上的最佳化調整，全面提升大屏搭建效率和降低對底層的訪問壓力，提升系統健壯性及擴充套件能力。
• 多場景預案：為保障大屏滿足各場景下都能穩定執行，基於使用者訪問限制、跨0點停數、資料雙流切換、斷網停數、大屏管控切換、視界硬體裝置切換等都有相應操作預案，並針對作戰指揮、京東視界、公關大屏場景進行停數和預案演練，同時在跨0點特殊場景下，藉助錄屏工具定時執行實現對跨夜節點場景上對人力資源的釋放，提升開發及備戰效率。
• 技術創新方向：過去大屏只有系統層級上的監控能力，對使用者實時訪問大屏情況不能及時進行監控，考慮到大屏專案的重要性及配置化的特殊性，本次大促對大屏設計了心跳上報的能力，透過大屏心跳檢測實時掌握使用者訪問大屏情況以及系統壓力，並結合相關預案出現異常情況快速進行操作。
• 高效響應需求：大屏搭建前提前識別大屏搭建工作量巨大而公關屏數量佔了一半以上，為解決大量公關屏搭建工作本次公關屏透過資料脫敏組織人員培訓引入3個ISV人員主導進行公關屏的搭建，高效解決大屏搭建效率。同時大促過程中藉助大屏強大的配置化和底層PaaS化搭建大屏能力，每次有緊急需求都能快速支援，過程中共支援了28H大屏跨0點停數、615高潮期累計、28H實時訂單累計、618晚宴等場景需求，為公司高層在大促期間快速決策起到保駕護航的作用。

5.2  能力沉澱

    

基於本次大促過程遇到的問題共性及能力複用的思考，JDV平臺專案中相關功能也能進行復用，以下功能將實現專案賦能提升其他專案的開發效率。

• 例項實時監控：本次大促增加的心跳上報和基於上報日誌搭建大屏實時監控功能，剛好可以補齊目前我們系統中更精細化的實時監控能力，透過沉澱為可統一複用能力後方便我們基於使用者實時監控進行異常預案聯動確保大促穩定性保障。
• 代理資料來源：對相同使用者請求進行合併，在後臺生成查詢任務，以降低對依賴資料服務層的請求壓力，從而避免由於使用者量增加造成對資料服務和DB查詢壓力，避免觸發底層限流等場景使用。
• 錄屏任務服務：當系統需要跨0點停數、倒數計時功能驗證時，為確保在跨0點場景做到真實驗證而又無需人員每次等到指定時間點，透過指定時間段自動錄屏後續進行回放驗證等方式，避免大促期間人員經常凌晨驗證釋放人員精力提升工作效率。
• 編排配置DIFF：隨著開發提效的逐步實踐各系統的編排配置能力也將逐步提升，在頻繁的配置修改過程中，為保障配置的正確性，各自系統也將越來越需要配置變更通知機制，將配置DIFF工具能力形成複用，對新舊版本的配置進行 DIFF 比對，提升功能修改的高效驗證也將變得越來越重要。

5.3  待提升項

    

同時在本次大促中JDV平臺也存在不足需要在後續工作中逐步進行提升，主要體現在溝通成本高、標準規範統一等方面上，後續也將基於本次大促過程中遇到的問題逐步完成專案在更多方向的數字化能力建設。

• 溝通成本高：由於大促期間涉及各方向人員主要有業務方、產研測以及三方介面及三方大屏對應的產研等人員，期間大屏共涉及86張各團隊配合過程中各種大小事都需要及時溝通確認，出現這些問題的原因都是由於需求變更調整沒有統一在JDV平臺資料化造成的，需要先收集到文件再由大屏搭建人員調整編排引發的，在這樣的情況下需求調整越多溝通成本也就越高。後續將逐步規劃抽取需求變更共性，當修改文案、數字等配置內容時相關業務方或產品能直接在JDV平臺進行錄入調整，調整後又能立馬檢視效果實現大屏編排中期也能可見即可得能力。
• 標準規範統一：為降低大屏搭建過程中出問題機率和提升溝通效率，涉及各方依賴項在效能要求、壓測文件、停數控制、資訊收集反饋等方向上都需要更加的規範，目前各方介面人輸出結果時間及要求讓JDV大屏多團隊協作方向上也能沉澱出一套完整模版，甚至在每次大促過程中各介面人和研發等角色都能收到各自需要完成事項的XBP流程，按照流程標準輸出待辦事項等。

最後平臺發展也希望有更多的建議，大家如果在系統編排等方向上有更好的思路和建議，也可以聯絡作者讓JDV發揮更大的價值！