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

圖1.系統具體架構示意

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

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

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

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

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

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

圖2.心跳上報流程

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

圖3.

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

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

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

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

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

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

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

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

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