網(wǎng)絡(luò)優(yōu)化大數(shù)據(jù)平臺(tái)監(jiān)控技術(shù)研究

陳濤，陳彥名，王康，張冬晨

（中國(guó)移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司，北京 100080）

1 網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)的系統(tǒng)功能與監(jiān)控需求

隨著大數(shù)據(jù)存儲(chǔ)技術(shù)和處理技術(shù)的發(fā)展，日常的網(wǎng)優(yōu)工作已經(jīng)可以通過(guò)建立覆蓋全網(wǎng)的集中化的網(wǎng)優(yōu)平臺(tái)來(lái)支撐。如圖1所示，網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)使用FTP/SFTP協(xié)議每隔15 min從省端OMC服務(wù)器采集解析PM、NRM、MR數(shù)據(jù)文件，并將基礎(chǔ)Counter數(shù)據(jù)存入HBase數(shù)據(jù)庫(kù)中。上層網(wǎng)優(yōu)應(yīng)用，如專項(xiàng)保障分析和干擾分析、網(wǎng)絡(luò)結(jié)構(gòu)分析等通過(guò)對(duì)基礎(chǔ)網(wǎng)絡(luò)指標(biāo)進(jìn)行分析，給出優(yōu)化建議，并將網(wǎng)絡(luò)關(guān)鍵指標(biāo)在前臺(tái)進(jìn)行展示。

為保證網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)的全網(wǎng)匯總數(shù)據(jù)可靠性達(dá)到日常的無(wú)線網(wǎng)優(yōu)生產(chǎn)要求，各省原始網(wǎng)優(yōu)數(shù)據(jù)采集率需要在95%以上，系統(tǒng)在一個(gè)月內(nèi)指定連續(xù)7天的生產(chǎn)匯總周期內(nèi)不能有數(shù)據(jù)缺失問(wèn)題。此外，盡管系統(tǒng)使用的開(kāi)源分布式數(shù)據(jù)存儲(chǔ)和并行計(jì)算組件都有內(nèi)部的冗余容錯(cuò)機(jī)制，但是仍然需要有監(jiān)控手段及時(shí)發(fā)現(xiàn)大數(shù)據(jù)開(kāi)源組件的停機(jī)故障，并快速排查處置。通過(guò)總結(jié)平臺(tái)運(yùn)維經(jīng)驗(yàn)，匯總了網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)多層次的監(jiān)控需求如表1所示。

圖1 網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)的系統(tǒng)監(jiān)控需求

因?yàn)樾枰S護(hù)的設(shè)備眾多（省端OMC服務(wù)器有幾千臺(tái)），且實(shí)際生產(chǎn)中要求短時(shí)間內(nèi)發(fā)現(xiàn)排除平臺(tái)故障，很難通過(guò)人工手段完成，需要搭建網(wǎng)優(yōu)平臺(tái)監(jiān)控系統(tǒng)完成上述生產(chǎn)目標(biāo)。目前業(yè)界對(duì)大數(shù)據(jù)分析平臺(tái)的監(jiān)控技術(shù)研究不多[1，2]，本文介紹了一個(gè)擴(kuò)展性較強(qiáng)、可配置的網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)，設(shè)計(jì)思路和監(jiān)控手段可供相關(guān)研究人員參考。

表1 網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控需求

2 現(xiàn)有大數(shù)據(jù)平臺(tái)監(jiān)控技術(shù)綜述

2.1 主要開(kāi)源監(jiān)控軟件的介紹

利用開(kāi)源監(jiān)控軟件，可以快速搭建監(jiān)控系統(tǒng)，能滿足大數(shù)據(jù)分析平臺(tái)運(yùn)維初期的監(jiān)控需求，如下介紹了常用的開(kāi)源監(jiān)控軟件。

2.1.1 Ganglia軟件

Ganglia[3]是一個(gè)分布式監(jiān)控系統(tǒng)，沒(méi)有單點(diǎn)故障，主要由Gmond、Gmetad、Gweb 3部分組成。Gmond用于搜集監(jiān)控指標(biāo)，如主機(jī)的CPU、內(nèi)存等數(shù)據(jù)。搜集的數(shù)據(jù)將以多播的形式在集群內(nèi)部進(jìn)行廣播，每臺(tái)機(jī)器Gmond組件都會(huì)監(jiān)聽(tīng)并存儲(chǔ)集群相關(guān)主機(jī)的狀態(tài)。Gmetad負(fù)責(zé)輪詢Gmond節(jié)點(diǎn)，并將監(jiān)測(cè)數(shù)據(jù)存入RRDtool數(shù)據(jù)庫(kù)中。Gweb負(fù)責(zé)監(jiān)測(cè)數(shù)據(jù)的顯示。Ganglia通過(guò)插件方法可實(shí)現(xiàn)對(duì)Hadoop、HBase、Redis、Kafka、Spark等開(kāi)源組件的監(jiān)控。

2.1.2 Nagios/Centreon軟件

Nagios是一個(gè)監(jiān)視系統(tǒng)運(yùn)行狀態(tài)(如主機(jī)CPU、內(nèi)存等)和網(wǎng)絡(luò)信息的開(kāi)源系統(tǒng)。如果監(jiān)控指標(biāo)觸發(fā)報(bào)警，能通過(guò)E-Mail、短信等多種方式通知管理人員。

Centreon開(kāi)源監(jiān)控軟件擅長(zhǎng)監(jiān)控?cái)?shù)據(jù)的展示。底層通常采用Nagios作為監(jiān)控軟件，Nagios通過(guò)Ndoutil模塊將監(jiān)控到的數(shù)據(jù)定時(shí)寫(xiě)入數(shù)據(jù)庫(kù)中，而Centreon實(shí)時(shí)從數(shù)據(jù)庫(kù)讀取該數(shù)據(jù)并通過(guò)Web界面展現(xiàn)監(jiān)控?cái)?shù)據(jù)。

2.1.3 KafkaOffsetMonitor軟件

KafkaOffsetMonitor可以對(duì)Kafka消息組件進(jìn)行監(jiān)控，能檢測(cè)到Kafka集群是否有消息積壓，可視化的監(jiān)測(cè)系統(tǒng)消息消費(fèi)情況。程序以一個(gè)jar分組的形式運(yùn)行，部署較為方便。

2.1.4 Taokeeper軟件

Taokeeper是Alibaba出品的一個(gè)對(duì)Zookeeper集群開(kāi)源監(jiān)控軟件。能對(duì)集群所在主機(jī)的負(fù)載、單機(jī)連接數(shù)等指標(biāo)進(jìn)行監(jiān)控。允許進(jìn)行二次開(kāi)發(fā)，自主增加監(jiān)控項(xiàng)目。

2.1.5 Chukwa軟件

Chukwa軟件主要用于監(jiān)控Hadoop集群的運(yùn)行情況。本身也提供了很多內(nèi)置的功能，可以對(duì)Hadoop集群的日志進(jìn)行收集和分析。

2.1.6 Cloudera Manager軟件

如果使用Cloudera公司的CDH套件進(jìn)行大數(shù)據(jù)組件的安裝。就可以使用Cloudera Manager的管理界面對(duì)HDFS， HBase等組件進(jìn)行監(jiān)控。Cloudera Manager提供了豐富的系統(tǒng)監(jiān)視診斷和報(bào)告功能。Cloudera Manager免費(fèi)版本在集群管理規(guī)模上有所限制，且不提供API支持二次開(kāi)發(fā)。

2.2 自主開(kāi)發(fā)大數(shù)據(jù)平臺(tái)監(jiān)控軟件與采用開(kāi)源監(jiān)控軟件的優(yōu)缺點(diǎn)

通常平臺(tái)運(yùn)維人員會(huì)在平臺(tái)系統(tǒng)運(yùn)行初期利用Ganglia完成監(jiān)控?cái)?shù)據(jù)的采集工作，利用Nagios完成閾值檢查和報(bào)警的功能，利用Centreon完成Nagios系統(tǒng)的管理和數(shù)據(jù)展示功能。對(duì)特定組件的監(jiān)控，如Kafka、Redis等采用方便部署的KafkaOffsetMonitor、Codis等開(kāi)源監(jiān)控軟件。這種方法可以快速擁有對(duì)系統(tǒng)的監(jiān)控能力。但是隨著大數(shù)據(jù)分析平臺(tái)功能的擴(kuò)展，整合多個(gè)監(jiān)控系統(tǒng)并進(jìn)行二次開(kāi)發(fā)的工作難度會(huì)越來(lái)越大。且開(kāi)源軟件的監(jiān)控粒度較粗，只能監(jiān)控較為通用的系統(tǒng)指標(biāo)，如CPU/內(nèi)存/硬盤(pán)的使用率等，不能滿足定制化的監(jiān)控需求。

自主開(kāi)發(fā)監(jiān)控軟件可以采用統(tǒng)一的監(jiān)控框架、接口數(shù)據(jù)標(biāo)準(zhǔn)和監(jiān)控界面風(fēng)格，容易結(jié)合網(wǎng)優(yōu)應(yīng)用開(kāi)發(fā)特定的監(jiān)控功能，易于擴(kuò)展、部署與維護(hù)。因此，類似小米、阿里等互聯(lián)網(wǎng)公司都會(huì)自主設(shè)計(jì)開(kāi)發(fā)業(yè)務(wù)平臺(tái)監(jiān)控系統(tǒng)。自主開(kāi)發(fā)監(jiān)控系統(tǒng)也是網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)長(zhǎng)期運(yùn)營(yíng)的必要手段。

3 網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)設(shè)計(jì)與關(guān)鍵技術(shù)方案

3.1 監(jiān)控系統(tǒng)基礎(chǔ)架構(gòu)

結(jié)合網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)的運(yùn)維需求，我們的監(jiān)控系統(tǒng)從功能上分為3層。如圖2顯示了網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)的軟件結(jié)構(gòu)。

（1）監(jiān)控?cái)?shù)據(jù)采集層：通過(guò)周期性的主動(dòng)測(cè)量或調(diào)用JMX性能查詢接口等方式獲取被監(jiān)測(cè)對(duì)象的狀態(tài)信息，通過(guò)統(tǒng)一的Http接口上報(bào)數(shù)據(jù)到監(jiān)控服務(wù)器。

（2）監(jiān)控?cái)?shù)據(jù)處理層：主要完成原始監(jiān)控?cái)?shù)據(jù)的解析入庫(kù)；每小時(shí)，每天對(duì)原始的監(jiān)控?cái)?shù)據(jù)進(jìn)行匯總，存入?yún)R總監(jiān)控?cái)?shù)據(jù)表，刪除冗余數(shù)據(jù)以節(jié)省資源；對(duì)監(jiān)控?cái)?shù)據(jù)進(jìn)行異常狀態(tài)檢測(cè)，如果發(fā)現(xiàn)停機(jī)、負(fù)荷過(guò)重等異常情況，則觸發(fā)報(bào)警功能。

（3）展示層：可以接受監(jiān)控對(duì)象配置和用戶權(quán)限配置操作；可以向管理員展示平臺(tái)負(fù)荷情況，實(shí)時(shí)顯示系統(tǒng)數(shù)據(jù)吞吐量等。

監(jiān)控系統(tǒng)先讀取配置文件，按照配置加載需要執(zhí)行的監(jiān)控功能模塊。能根據(jù)需要自動(dòng)檢測(cè)集群主機(jī)的CPU/內(nèi)存/硬盤(pán)的負(fù)荷，自動(dòng)檢查Zookeeper集群、HBase集群、Redis等平臺(tái)組件工作是否正常。也能自動(dòng)檢測(cè)OMC FTP服務(wù)器的聯(lián)通性和用戶名、密碼的更改導(dǎo)致的故障，能檢查原始數(shù)據(jù)文件是否有效，能及時(shí)告警。

系統(tǒng)采用了客戶端（負(fù)責(zé)被監(jiān)測(cè)主機(jī)基礎(chǔ)數(shù)據(jù)的采集）和服務(wù)器端（負(fù)責(zé)數(shù)據(jù)入庫(kù)、報(bào)警功能、配置與展示）分離的設(shè)計(jì)，可以通過(guò)配置文件定制監(jiān)控項(xiàng)目并調(diào)整檢測(cè)時(shí)間周期等參數(shù)。系統(tǒng)也根據(jù)網(wǎng)優(yōu)平臺(tái)常見(jiàn)故障優(yōu)化了監(jiān)控項(xiàng)目，如Hadoop根目錄過(guò)滿報(bào)警、采集服務(wù)器無(wú)目標(biāo)文件報(bào)警等，能更有效的保障網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)的運(yùn)行。

3.2 數(shù)據(jù)采集、上報(bào)與存儲(chǔ)的技術(shù)特點(diǎn)

我們的系統(tǒng)采用SSM框架實(shí)現(xiàn)系統(tǒng)監(jiān)控功能，可以同時(shí)部署在Windows平臺(tái)和Unix平臺(tái)上。系統(tǒng)關(guān)鍵技術(shù)介紹如下。

圖2 網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)總體結(jié)構(gòu)圖

3.2.1 利用Sigar組件采集宿主機(jī)負(fù)荷數(shù)據(jù)

Sigar組件是一個(gè)跨平臺(tái)的主機(jī)狀態(tài)信息測(cè)量工具，集成在監(jiān)控系統(tǒng)的客戶端并部署在宿主機(jī)上，周期性的采集所在機(jī)器的CPU/內(nèi)存/硬盤(pán)的負(fù)載情況，然后將測(cè)量數(shù)據(jù)封裝為JSON格式后，利用統(tǒng)一的Http Restful接口投遞到后臺(tái)服務(wù)器上。

3.2.2 Zookeeper和JMX接口的應(yīng)用

在利用Ganglia插件對(duì)Hadoop/HBase等組件進(jìn)行監(jiān)控時(shí)，所獲取的監(jiān)控信息往往比較粗糙，不能滿足細(xì)粒度的監(jiān)控需求。我們的監(jiān)控系統(tǒng)直接訪問(wèn)大數(shù)據(jù)組件的JMX接口獲取組件的詳細(xì)運(yùn)行信息，如宿主虛擬機(jī)的內(nèi)存狀態(tài)、內(nèi)存池狀態(tài)、Java堆信息等。此外，我們也通過(guò)查詢Zookeeper的存儲(chǔ)信息，獲取所管理集群各節(jié)點(diǎn)的存活信息、讀寫(xiě)次數(shù)等。這兩種方法采集的集群工作數(shù)據(jù)較為及時(shí)、詳細(xì)，逐漸成為大數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)的主流技術(shù)。

3.2.3 監(jiān)控對(duì)象無(wú)關(guān)的監(jiān)控?cái)?shù)據(jù)存儲(chǔ)設(shè)計(jì)

由于監(jiān)控對(duì)象眾多，每個(gè)監(jiān)控對(duì)象的監(jiān)控指標(biāo)各不相同，如果每個(gè)監(jiān)控對(duì)象采用不同的數(shù)據(jù)表存儲(chǔ)，勢(shì)必會(huì)增加監(jiān)控軟件開(kāi)發(fā)和維護(hù)的負(fù)擔(dān)。數(shù)據(jù)庫(kù)表會(huì)快速膨脹。在我們的監(jiān)控系統(tǒng)中，為每個(gè)監(jiān)控對(duì)象分配一個(gè)唯一的Objectid，將該對(duì)象的上報(bào)數(shù)據(jù)封裝成Json字符串直接存儲(chǔ)在監(jiān)控?cái)?shù)據(jù)表的Content字段中。后繼的數(shù)據(jù)處理和報(bào)警模塊根據(jù)Objectid指示解析對(duì)應(yīng)的監(jiān)控?cái)?shù)據(jù)對(duì)象，從而利用少量的基礎(chǔ)監(jiān)控?cái)?shù)據(jù)表和一個(gè)報(bào)警表格就可以支撐所有監(jiān)控和報(bào)警任務(wù)，且方便新增報(bào)警對(duì)象。表2、3是主要的數(shù)據(jù)庫(kù)表設(shè)計(jì)。

3.2.4 省端OMC FTP采集服務(wù)器的監(jiān)控

為保證各省的數(shù)據(jù)采集率在95%以上，中國(guó)移動(dòng)開(kāi)發(fā)的采集系統(tǒng)需要不斷對(duì)各省的OMC FTP服務(wù)器進(jìn)行狀態(tài)監(jiān)控，避免由于配置錯(cuò)誤或原始文件缺失導(dǎo)致數(shù)據(jù)采集問(wèn)題。我們的監(jiān)控系統(tǒng)周期性模擬采集程序做OMC FTP服務(wù)器的登錄測(cè)試，原始文件的抓取測(cè)試。能檢測(cè)出網(wǎng)絡(luò)中斷、登錄用戶名、密碼錯(cuò)誤、FTP協(xié)議傳輸模式錯(cuò)誤，原始數(shù)據(jù)文件目錄錯(cuò)誤或文件缺失等常見(jiàn)問(wèn)題。通過(guò)統(tǒng)計(jì)各省各地區(qū)數(shù)據(jù)采集率和采集小區(qū)的信息，可以準(zhǔn)確的追蹤到有問(wèn)題的采集服務(wù)器，并快速通知省端排查。

表2 監(jiān)控?cái)?shù)據(jù)表

表3 報(bào)警信息數(shù)據(jù)表

3.3 數(shù)據(jù)質(zhì)量保證的技術(shù)方案

3.3.1 HBase Mapreduce/Spark在采集率統(tǒng)計(jì)上應(yīng)用

網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)需要每天統(tǒng)計(jì)各省性能、MR等數(shù)據(jù)的采集率，且各省采集率在95%以上才能利用網(wǎng)絡(luò)統(tǒng)計(jì)指標(biāo)指導(dǎo)全網(wǎng)的優(yōu)化工作。由于原始數(shù)據(jù)在4億條左右，利用單機(jī)多線程統(tǒng)計(jì)方法不能及時(shí)完成采集率的統(tǒng)計(jì)，我們采用了HBase Mapreduce[4]的計(jì)算框架，可以在2h左右完成統(tǒng)計(jì)任務(wù)。也可以使用Spark在1h完成統(tǒng)計(jì)任務(wù)，但是高峰時(shí)會(huì)耗用大量Hadoop集群讀寫(xiě)I/O，影響正常的網(wǎng)優(yōu)數(shù)據(jù)入庫(kù)。相比Spark、Mapreduce計(jì)算耗用的資源更少，當(dāng)然計(jì)算時(shí)間更長(zhǎng)。

3.3.2 中間表監(jiān)測(cè)與自動(dòng)報(bào)表的生成

在正常的生產(chǎn)中，除了原始數(shù)據(jù)外，匯總數(shù)據(jù)是否正常也是需要監(jiān)控的項(xiàng)目，我們的軟件會(huì)自動(dòng)對(duì)每天匯總的數(shù)據(jù)項(xiàng)目，條數(shù)進(jìn)行檢查，能發(fā)現(xiàn)缺失的省市指標(biāo)。系統(tǒng)會(huì)自動(dòng)生成數(shù)據(jù)質(zhì)量的報(bào)表，包括集群運(yùn)行情況、各省市采集情況，可以使網(wǎng)優(yōu)業(yè)務(wù)人員及時(shí)了解數(shù)據(jù)質(zhì)量和分析導(dǎo)致數(shù)據(jù)缺失的原因，通常可能是省公司未報(bào)送或數(shù)據(jù)解析、入庫(kù)等問(wèn)題造成。

4 應(yīng)用實(shí)踐

4.1 前端展示效果

本文監(jiān)控系統(tǒng)在生產(chǎn)環(huán)境部署后，在過(guò)去1年里，系統(tǒng)可以檢測(cè)到HBase、主機(jī)、網(wǎng)絡(luò)的最新?tīng)顟B(tài)，并可以查看系統(tǒng)歷史運(yùn)行情況，對(duì)異常及時(shí)告警，有效地提高了運(yùn)維人員的工作效率。部分操作界面如圖3-5所示。

4.2 常見(jiàn)報(bào)警的處置

4.2.1 大數(shù)據(jù)計(jì)算組件宕機(jī)

HBase/HDFS，Redis等大數(shù)據(jù)組件都有可能由于突發(fā)業(yè)務(wù)量高峰，導(dǎo)致I/O超過(guò)門(mén)限而宕機(jī)。通過(guò)監(jiān)控系統(tǒng)可以及時(shí)發(fā)現(xiàn)宕機(jī)，并操作重啟。通過(guò)監(jiān)控歷史數(shù)據(jù)，可以得知宕機(jī)的時(shí)間，評(píng)估積壓網(wǎng)優(yōu)數(shù)據(jù)對(duì)網(wǎng)優(yōu)業(yè)務(wù)的影響。在經(jīng)常宕機(jī)的時(shí)間，應(yīng)該采用錯(cuò)開(kāi)計(jì)算作業(yè)等措施減輕峰值計(jì)算負(fù)荷。

4.2.2 存儲(chǔ)空間用盡

存儲(chǔ)空間耗盡會(huì)導(dǎo)致系統(tǒng)宕機(jī)，并觸發(fā)警告，需要管理員利用du，fd等命令及時(shí)查找導(dǎo)致系統(tǒng)存儲(chǔ)資源耗盡的原因，通常是計(jì)算作業(yè)輸出了大量的log日志或計(jì)算結(jié)果文件未及時(shí)清除所致，應(yīng)該建立自動(dòng)腳本予以刪除。

4.2.3 采集數(shù)據(jù)缺失

圖3 Hbase監(jiān)控系統(tǒng)頁(yè)面

圖4 集群主機(jī)CPU負(fù)荷情況

圖5 Hbase讀寫(xiě)訪問(wèn)次數(shù)統(tǒng)計(jì)

各省的數(shù)據(jù)采集率不能達(dá)到95%的要求，多是OMC FTP服務(wù)器配置用戶名、密碼、文件目錄的信息發(fā)生變更或省端沒(méi)有及時(shí)上傳工參和性能，MR數(shù)據(jù)分組所導(dǎo)致，監(jiān)控系統(tǒng)能模擬人工檢查配置信息，并給出詳細(xì)的測(cè)試失敗原因。

5 結(jié)束語(yǔ)

自主開(kāi)發(fā)網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)是長(zhǎng)期運(yùn)營(yíng)維護(hù)網(wǎng)優(yōu)平臺(tái)的重要保障，本文介紹的網(wǎng)優(yōu)大數(shù)據(jù)平臺(tái)監(jiān)控軟件由于采用統(tǒng)一的采集接口、簡(jiǎn)單的數(shù)據(jù)庫(kù)表設(shè)計(jì)、JMX虛擬機(jī)狀態(tài)查詢解析技術(shù)，與直接采用開(kāi)源監(jiān)控軟件相比，監(jiān)控粒度更為細(xì)致，系統(tǒng)易于擴(kuò)展，部署，在平臺(tái)正常生產(chǎn)運(yùn)營(yíng)中發(fā)揮了重要作用。

[1] 吳明禮, 楊小燕, 李也白. 多數(shù)據(jù)庫(kù)系統(tǒng)環(huán)境數(shù)據(jù)庫(kù)監(jiān)控與管理技術(shù)研究[J]. 工業(yè)技術(shù)創(chuàng)新, 2015,02:239-244.

[2] 王雷, 錢(qián)招明, 郭進(jìn)偉, 等. OceanBase數(shù)據(jù)庫(kù)監(jiān)控系統(tǒng)[J]. 計(jì)算機(jī)應(yīng)用, 2016,S1:237-239.

[3] 梅西. Ganglia系統(tǒng)監(jiān)控[M]. 北京：機(jī)械工業(yè)出版社，2013,09.

[4] Lars George, HBase權(quán)威指南[M]. 北京：人民郵電出版社，2013,10.