高智衡

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

高智衡

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

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

大數(shù)據(jù) 網(wǎng)絡(luò)運(yùn)營 前臺(tái)系統(tǒng) 技術(shù)架構(gòu)

1 電信網(wǎng)絡(luò)運(yùn)營前臺(tái)系統(tǒng)概述

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

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

2 電信網(wǎng)絡(luò)運(yùn)營前臺(tái)系統(tǒng)技術(shù)架構(gòu)設(shè)計(jì)

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

基于上述業(yè)務(wù)特性，系統(tǒng)技術(shù)架構(gòu)設(shè)計(jì)如圖1所示：

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

系統(tǒng)采用了基于Web的BS架構(gòu)，具備跨平臺(tái)、客戶端零維護(hù)等優(yōu)勢(shì)[3]。然而BS架構(gòu)在系統(tǒng)響應(yīng)方面有所不足，而系統(tǒng)用戶要求絕大部分交互在3 s內(nèi)完成，因此根據(jù)不同的應(yīng)用場景需采用不同的數(shù)據(jù)存儲(chǔ)策略和查詢引擎。面向清單級(jí)別的查詢使用高度可擴(kuò)展、數(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ái)系統(tǒng)需要面對(duì)多種查詢引擎，增加了技術(shù)復(fù)雜度，所以在后端模塊中設(shè)計(jì)了通用數(shù)據(jù)查詢組件，統(tǒng)一封裝各種查詢引擎，提供標(biāo)準(zhǔn)SQL或類SQL的查詢命令支持，有效地把技術(shù)復(fù)雜度局限在小范圍內(nèi)。

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

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

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

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

3.1 整體單頁面架構(gòu)轉(zhuǎn)變?yōu)榘磻?yīng)用的單頁面架構(gòu)，解決了控件版本沖突問題，提升了頁面運(yùn)行性能

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

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

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

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

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

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

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

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

圖2 查詢模板代碼片段

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

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

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

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

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

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

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

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

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

3.5 查詢節(jié)點(diǎn)動(dòng)態(tài)切換，保證查詢服務(wù)的高可用性

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

圖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)運(yùn)前臺(tái)系統(tǒng)架構(gòu)設(shè)計(jì)與優(yōu)化[J]. 移動(dòng)通信, 2017,41(22): 84-88.

2017-09-26

劉妙 liumiao@mbcom.cn