基于大數(shù)據(jù)的網(wǎng)運前臺系統(tǒng)架構設計與優(yōu)化

高智衡

基于大數(shù)據(jù)的網(wǎng)運前臺系統(tǒng)架構設計與優(yōu)化

高智衡

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

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

大數(shù)據(jù) 網(wǎng)絡運營 前臺系統(tǒng) 技術架構

1 電信網(wǎng)絡運營前臺系統(tǒng)概述

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

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

2 電信網(wǎng)絡運營前臺系統(tǒng)技術架構設計

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

基于上述業(yè)務特性，系統(tǒng)技術架構設計如圖1所示：

圖1 基于大數(shù)據(jù)的電信網(wǎng)運前臺系統(tǒng)技術架構

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

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

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

3 前臺系統(tǒng)的優(yōu)化

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

3.1 整體單頁面架構轉(zhuǎn)變?yōu)榘磻玫膯雾撁婕軜?，解決了控件版本沖突問題，提升了頁面運行性能

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

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

3.2 數(shù)據(jù)查詢模板化，實現(xiàn)前后端開發(fā)分離

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

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

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

3.3 創(chuàng)建查詢緩存，提升熱數(shù)據(jù)的查詢響應效率

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

圖2 查詢模板代碼片段

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

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

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

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

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

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

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

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

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

3.5 查詢節(jié)點動態(tài)切換，保證查詢服務的高可用性

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

圖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

高智衡. 基于大數(shù)據(jù)的網(wǎng)運前臺系統(tǒng)架構設計與優(yōu)化[J]. 移動通信, 2017,41(22): 84-88.

2017-09-26

劉妙 liumiao@mbcom.cn