基于大數據的網運前臺系統架構設計與優化

高智衡

基于大數據的網運前臺系統架構設計與優化

高智衡

（中國電信股份有限公司廣州研究院，廣東 廣州 510630）

根據業務應用特性，提出了基于大數據的電信網絡運營前臺系統的技術架構設計。隨著所承載的應用越來越多，從減少頁面加載時間、提升查詢性能、提高代碼復用率等角度考慮，在單頁面應用架構、查詢模板化、查詢緩存、業務功能組件化、查詢服務高可用等方面對系統進行了優化，為類似系統的建設提供了參考。

大數據 網絡運營 前臺系統 技術架構

1 電信網絡運營前臺系統概述

電信網絡運營系統以提高網絡運行質量，提升用戶的業務使用體驗為核心目標，主要涉及兩個方面的數據：一是網絡/設備運行信息，包括反映設備/端口/鏈路的速率、帶寬、抖動、延時等硬件運行情況的信息以及反映網絡情況的業務統計信息，一般通過網管系統進行監控和采集；二是用戶使用業務信息，包括用戶的實時位置、正在使用的業務類型、業務內容、APP名稱、終端型號版本、業務使用感知（時延、成功率、速率）等刻畫用戶行為、反映用戶實時業務體驗的動態信息，一般采用探針、鏡像抓包等方式捕獲[1]。

上述數據由現網實時產生、實時采集，數據量大，類型復雜，具備通常所說的大數據3V特性[2]，因此系統采用了基于Hadoop的大數據技術進行數據處理和展示。整個系統可以劃分為兩部分，一部分負責對數據進行采集、ETL預處理、分析/匯總/挖掘等一系列處理，提供數據共享平臺，主要面向系統運營維護管理人員，稱為后臺系統；另一部分負責結合實際業務需求，以圖表、地圖等方式呈現數據，基于業務經驗和分析挖掘結果提供指導生產的結論，并在必要時回寫數據，主要面向最終用戶使用，稱為前臺系統。本文探討后者的技術架構設計及優化。

2 電信網絡運營前臺系統技術架構設計

該系統的業務關鍵特性在于：應用以數據查詢展示為主，輔以少量的回寫業務；屬于企業內部應用，僅供內部員工使用；用戶層面廣泛，應用場景復雜，涉及高層領導關注的宏觀匯總數據、基層操作人員關注的細粒度數據以及中層分析人員靈活多變的即席數據查詢。

基于上述業務特性，系統技術架構設計如圖1所示：

圖1 基于大數據的電信網運前臺系統技術架構

系統采用了基于Web的BS架構，具備跨平臺、客戶端零維護等優勢[3]。然而BS架構在系統響應方面有所不足，而系統用戶要求絕大部分交互在3 s內完成，因此根據不同的應用場景需采用不同的數據存儲策略和查詢引擎。面向清單級別的查詢使用高度可擴展、數據按Rowkey排序、可快速檢索指定范圍內Rowkey數據的Hbase[4]，匯總數據查詢和數據回寫使用Mysql，靈活多樣的即席查詢采用高效率的大量數據并行處理（Massively Parallel Porvessing，MPP）查詢引擎Impala[5]，涉及空間分析則采用支持地理空間數據管理的PostgrepSQL[6]等。查詢引擎的多樣化使前臺系統需要面對多種查詢引擎，增加了技術復雜度，所以在后端模塊中設計了通用數據查詢組件，統一封裝各種查詢引擎，提供標準SQL或類SQL的查詢命令支持，有效地把技術復雜度局限在小范圍內。

圖1中的每一個應用，對應著一個業務主題，包括以下三個模塊：在后端運行的Action服務，負責接收前端請求并調用查詢組件訪問數據；在前端運行的應用視圖模塊，負責頁面內容的樣式和布局；在前端運行的應用邏輯控制模塊，負責收集用戶的輸入，向后端提交數據查詢請求，并根據返回結果刷新界面。三個模塊使每個應用自身構成了一個標準的MVC子架構[7]。

所有應用由單頁面應用（SPA）模塊整合，采用靜態資源預加載，動態資源按需異步加載的策略，有效地降低了頁面內容加載和刷新時給用戶帶來的停滯等待感。

3 前臺系統的優化

上面所介紹的前臺系統，結合了Mysql、Postgrep SQL等傳統關系型數據庫系統和Hadoop大數據處理平臺的技術優勢，基本可滿足各種復雜應用場景下的需求。但是，隨著應用的不斷深化和擴展，也導致了一些問題的出現，下面總結了相關的優化。

3.1 整體單頁面架構轉變為按應用的單頁面架構，解決了控件版本沖突問題，提升了頁面運行性能

SPA架構中，客戶端與服務端的所有數據交互僅在同一頁面內進行，用戶體驗類似于桌面應用，其優點在于無需重新加載整個頁面，內容刷新快，用戶體驗好[8]。

然而，當應用數量從初期十多個膨脹到一百多個后，情況就不一樣了。首先，不同應用間的控件版本如果存在沖突，只能選用其中之一。比如某應用使用的是echarts2.0，而另一個應用由于一些新的需求希望使用echarts3.0，由于3.0非后向兼容，所以此時要么統一升級到3.0，要么統一繼續使用2.0。其次，統一加載的靜態資源文件過多，用戶登錄后頁面加載時間過長。再次，當用戶打開很多應用時，由于DOM過于龐大導致頁面元素檢索偏慢。為此，把SPA架構下沉到每個應用內部，即單個應用內還是SPA，每個應用占用一個瀏覽器標簽，而原來的SPA模塊則調整為應用目錄展示模塊，在每個應用窗口的左側展示應用目錄，利用HTML5的本地存儲功能（LocalStorage）[9]記錄當前用戶已打開的所有應用，在任意一個窗口的目錄上點擊打開某個應用時，以此為基礎判斷是新建標簽頁還是激活已打開的標簽頁。經此改造，每個應用可以自由選擇其所需要的控件。

3.2 數據查詢模板化，實現前后端開發分離

每個應用的前端視圖、邏輯控制模塊都與應用需求緊密相關，差異較大，但后端Action模塊的主要功能是接收前端請求并根據請求中的參數構建查詢命令，調用查詢組件獲得相關數據并把數據返回。因此，所有應用的Action服務被整合為一個通用的Action服務，與數據查詢組件合并，形成數據查詢服務。合并的關鍵點在于把每個應用的查詢命令模板化，統一放入一個可配置的查詢模板庫中。

圖2是某模板示例，前端只需把唯一標識模板的id值及模板中的變量名（模板中帶有#字符的花括號標識的部分）、變量值放入請求即可。數據查詢組件根據id調取出模板，然后把變量名替換為變量值完成模板實例化，最后調用數據查詢組件，把查詢結果以統一格式返回給前端。模板內容配置在XML模板庫文件中，而模板庫在Web服務啟動時即加載到內存，以加快模板檢索速度。

Javascript查詢組件以Ajax異步請求[7]的方式把相關參數提交到數據查詢服務，并在數據結果返回后調用指定的回調函數進行后續處理。前端開發者只需調用該組件，傳入模板id和變量參數以及回調函數等，在回調函數中實現界面數據的刷新即可完成所需的業務功能。而后端開發人員則專注于根據數據需求創建查詢模板，并持續地優化查詢服務，從而實現了前后端開發分離，避免了原來多個Action狀態下的大量代碼重復出現的問題。而且，當需要核查數據時，執行模板實例，即可快速定位出問題是在于后臺系統的數據處理，還是前臺系統的數據展示。可見，查詢模板化，前后端分離，不僅提高了開發人員的開發效率，也方便了測試人員的數據核查工作。

3.3 創建查詢緩存，提升熱數據的查詢響應效率

數據查詢服務在個別情況下，尤其是涉及數據量較大時或用戶并發度較高時，響應還是不夠理想。經分析，前臺查詢基本存在著按月、周、天或者小時的時間周期特點，不同的用戶使用相同的功能，實際上查詢引擎執行了完全一樣的操作。雖然部分查詢引擎具備緩存功能，但后臺系統運行繁忙，緩存效果并不顯著，因此，添加了基于Redis的查詢緩存模塊。Redis是適用多種場景，可支持多種數據類型的內存數據庫，基于Key-Value類型的設計可實現快速高效的緩存管理[10]。

圖2 查詢模板代碼片段

圖3 是同步型查詢的緩存流程圖。以查詢命令的MD5值作為查詢的唯一標識（Key）。如果該Key存在于緩存庫，則說明查詢結果已被緩存，直接從緩存庫讀取該Key值對應的值（Value），返回給調用方即可。如果Key不存在，則說明未緩存，此時先調用查詢引擎，在返回查詢結果的同時，把該Key和查詢結果（即Value）一起寫入緩存庫備用。為了使緩存寫入工作對該次查詢的影響降到最低，查詢結果被深度克隆后，即返回查詢結果給調用方，而另開線程處理緩存庫的寫入。異步型查詢因為涉及進度的輪詢，需多次調用，緩存流程稍顯復雜，但基本思路與同步型一致，篇幅所限這里不再贅述。

加入緩存模塊后，當緩存命中時，不論原查詢消耗多少時間，基本上0.2 s內可返回結果，查詢效率的提升十分顯著，而關鍵點在于如何提高緩存命中率。通過對系統日常運行查詢情況進行統計，可以得到一些較常用的查詢，然后根據數據生成周期，在系統閑時對查詢進行預觸發，可有效提升命中率。當然，緩存模塊的引入增加了系統的管理成本，需要仔細分析業務模式，以決定是否啟用緩存，并結合數據生成周期配置每個模板的數據緩存有效期，避免過度緩存而導致最新數據變更未能及時取得。

3.4 抽取常用的前端功能模塊進行組件化，提升系統開發和維護效率

系統應用不斷增加，而相當部分的功能在不同的應用中是類似的甚至相同的，這種情況下，直接復制代碼雖然可以快速解決問題，但是當后期需求有所變更時，則不得不翻查每一處的代碼進行修訂，這顯然不是一個長久有效的辦法。因此，對所有應用專題進行了分析，梳理出一些常用業務功能，構建了前端公共組件庫。這里所說的前端組件，是指具備相對獨立的業務功能，提供固定的API接口，可直接引入和調用的Javascript模塊，以下是組件庫中幾個組件的實例。

（1）查詢組件——負責以Ajax異步請求的方式把相關參數發送給數據查詢服務，并在數據結果返回后調用指定的回調函數進行后續處理，前面的查詢模板化部分已有深入介紹。

（2）復雜表格組件——負責生成那些具有復合表頭、行列鎖定、按列排序、后端分頁加載、事件綁定等多種功能的復雜表格。

（3）專業圖表組件——負責生成那些常用的專業圖表，例如分布圖，具備自動定位到用戶所指定的分布百分比對應的分界線上。

（4）基站分布組件——在地圖上動態地畫出當前視圖范圍內的滿足過濾條件的所有基站，并根據其頻率、廠家等信息個性化地進行顯示。

組件庫既規范了業務功能在各個應用的界面和交互，也大幅提升了代碼復用率，對提高開發質量，提升開發效率有很大幫助。組件庫隨著應用的持續開發而不斷擴展。

3.5 查詢節點動態切換，保證查詢服務的高可用性

Hadoop集群中的數據處理服務都是采用分布式多節點架構，如果其中某個節點掛死，可以切換到其他節點，以保證服務的穩定。例如Impala可以結合haproxy提供負載均衡[11]，然而，大數據集群也可能由于某種原因尚未提供高可用的支持，所以在后端查詢服務與大數據集群之間增加了一個動態切換查詢節點的模塊，其主要業務邏輯如下：

圖3 同步型查詢緩存流程

Design and Optimization of Network Operation Foreground System Architecture Based on Big Data

GAO Zhiheng
(Guangzhou Research Institute of China Telecom Co., Ltd., Guangzhou 510630, China)

According to service features, a technical architecture design of the telecommunication network operation foreground system based on big data was proposed in this paper. Considering the more and more applications, the system was optimized in the single page application architecture, query template, query cache, service function componentization and query service high availability, with respect to the page loading time reduction, query performance enhancement and code reusability improvement. It provides a reference to the construction of similar systems.

big data network operation foreground system technical architecture

10.3969/j.issn.1006-1010.2017.22.016

TP319

A

1006-1010(2017)22-0084-05

高智衡. 基于大數據的網運前臺系統架構設計與優化[J]. 移動通信, 2017,41(22): 84-88.

2017-09-26

劉妙 liumiao@mbcom.cn