蔡莉莉

（北京全路通信信號(hào)研究設(shè)計(jì)院集團(tuán)有限公司，北京 100070）

1 概述

網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)是在城市軌道交通通信網(wǎng)絡(luò)運(yùn)行過(guò)程中，將地理位置不同的網(wǎng)絡(luò)設(shè)備、服務(wù)器、存儲(chǔ)設(shè)備、終端等類(lèi)型網(wǎng)元進(jìn)行統(tǒng)一、全面監(jiān)控、維護(hù)、管理的系統(tǒng)，是保障通信網(wǎng)絡(luò)可靠運(yùn)行的重要手段。

網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)在滿(mǎn)足網(wǎng)絡(luò)的日常維護(hù)，快速定位故障的前提下，網(wǎng)絡(luò)擁有者和維護(hù)人員越來(lái)越期盼網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)能提供更高端、專(zhuān)業(yè)和個(gè)性化的網(wǎng)絡(luò)運(yùn)維管理功能來(lái)滿(mǎn)足不同場(chǎng)景下的應(yīng)用需要。

為了適配更多的應(yīng)用場(chǎng)景，滿(mǎn)足用戶(hù)個(gè)性化網(wǎng)絡(luò)運(yùn)維需求，本系統(tǒng)利用了Karaf平臺(tái)具有模塊化，熱部署，易擴(kuò)展等優(yōu)點(diǎn)，提出了基于Karaf的網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)。

網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)后臺(tái)軟件根據(jù)用戶(hù)定制向前臺(tái)頁(yè)面提供數(shù)據(jù)支持服務(wù)，數(shù)據(jù)包括網(wǎng)元配置信息、告警信息、性能信息、權(quán)限管理、拓?fù)湫畔⒌取?/p>

2 Karaf相關(guān)技術(shù)介紹

Karaf：Karaf是一個(gè)輕量級(jí)的、簡(jiǎn)單、靈活的OSGi容器，本文主要介紹系統(tǒng)通過(guò)使用Karaf容器熱部署、動(dòng)態(tài)配置的特性，實(shí)現(xiàn)軟件動(dòng)態(tài)模塊化組裝。

IPOJO：IPOJO是一個(gè)基于OSGi的服務(wù)構(gòu)件模型，其主要作用是簡(jiǎn)化OSGi的Bundle開(kāi)發(fā)，解決服務(wù)間依賴(lài)復(fù)雜問(wèn)題。

EventAdmin消息處理機(jī)制：EventAdmin是OSGi中的一種基于發(fā)布訂閱的消息處理機(jī)制，它的應(yīng)用減少了模塊間的依賴(lài)，降低模塊之間耦合度，加強(qiáng)程序的靈活性、可擴(kuò)展性。

3 基于Karaf的網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)的架構(gòu)/結(jié)構(gòu)設(shè)計(jì)

3.1 系統(tǒng)架構(gòu)

基于Karaf的網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)主要由數(shù)據(jù)庫(kù)服務(wù)器、網(wǎng)絡(luò)運(yùn)維管理服務(wù)器及以太網(wǎng)交換機(jī)組成，后臺(tái)服務(wù)器可根據(jù)功能及項(xiàng)目規(guī)模進(jìn)行分設(shè)或合設(shè)，在工區(qū)辦公室部署運(yùn)維管理終端，終端通過(guò)以太網(wǎng)交換機(jī)實(shí)現(xiàn)與網(wǎng)絡(luò)運(yùn)維管理服務(wù)器間的通信。

部署在各車(chē)站的網(wǎng)絡(luò)設(shè)備、終端設(shè)備，以及部署在中心機(jī)房的網(wǎng)絡(luò)設(shè)備、服務(wù)器設(shè)備、存儲(chǔ)設(shè)備及終端設(shè)備，通過(guò)傳輸設(shè)備或以太網(wǎng)接口接入到中心機(jī)房的以太網(wǎng)交換機(jī)上，實(shí)現(xiàn)被管網(wǎng)元與網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)服務(wù)器之間的通信，網(wǎng)絡(luò)運(yùn)維管理服務(wù)器通過(guò)網(wǎng)絡(luò)感知網(wǎng)元狀態(tài)，獲取網(wǎng)元基本信息，采集設(shè)備告警，性能信息等。系統(tǒng)架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)示意Fig.1 Schematic diagram of system architecture

3.2 軟件架構(gòu)

系統(tǒng)采用B/S軟件架構(gòu)，前臺(tái)Web使用Vue框架，后臺(tái)服務(wù)軟件基于Karaf容器進(jìn)行開(kāi)發(fā)，采用結(jié)構(gòu)化方法對(duì)系統(tǒng)進(jìn)行模塊劃分，各模塊盡量做到相互獨(dú)立，以增加軟件的可靠性及可用性。

后臺(tái)服務(wù)軟件按采集數(shù)據(jù)后的處理到展示的數(shù)據(jù)流向，采用分層結(jié)構(gòu)開(kāi)發(fā)，API（接口）層用于提供對(duì)外發(fā)布服務(wù)的接口，Aspect（安全/權(quán)限）層用于安全認(rèn)證，保證前后臺(tái)通信安全；REST接口層用于提供RESTful接口供前臺(tái)調(diào)用；Provider（邏輯處理）層為核心邏輯處理層，主要負(fù)責(zé)告警、性能采集任務(wù)的發(fā)起，多模塊協(xié)同工作等核心功能；Store層為數(shù)據(jù)層，完成與數(shù)據(jù)庫(kù)交互，以及數(shù)據(jù)緩存等功能，Protocol（協(xié)議）層為協(xié)議層，對(duì)Provider層提供統(tǒng)一的接口，支持不同廠(chǎng)家、不同型號(hào)設(shè)備信息的采集，以屏蔽不同廠(chǎng)家，不同型號(hào)信息的個(gè)性化處理。Websocket（消息分發(fā)處理）層，用于將數(shù)據(jù)的變化以消息的方式推送給所有已連接的前臺(tái)Web界面。具體軟件架構(gòu)如圖2所示。

圖2 系統(tǒng)軟件架構(gòu)設(shè)計(jì)Fig.2 System software architecture design drawing

3.3 系統(tǒng)功能

系統(tǒng)具備對(duì)網(wǎng)絡(luò)設(shè)備、存儲(chǔ)設(shè)備、服務(wù)器設(shè)備、終端設(shè)備等網(wǎng)元統(tǒng)一運(yùn)維監(jiān)控功能。主要實(shí)現(xiàn)網(wǎng)元狀態(tài)監(jiān)視、告警實(shí)時(shí)上報(bào)、網(wǎng)元故障診斷等，主要功能如下。

數(shù)據(jù)采集：支持采集各類(lèi)型網(wǎng)元的運(yùn)行狀態(tài)、告警信息、性能信息等，處理后存儲(chǔ)到數(shù)據(jù)庫(kù)中。

拓?fù)涔芾恚焊鶕?jù)設(shè)備信息自動(dòng)生成綜合網(wǎng)絡(luò)拓?fù)鋱D，對(duì)設(shè)備連接關(guān)系進(jìn)行展示，并能夠在拓?fù)鋱D中動(dòng)態(tài)展示各節(jié)點(diǎn)的告警狀態(tài)。

告警管理：實(shí)時(shí)告警按重要程度進(jìn)行分級(jí)管理，不同級(jí)別以明顯顏色區(qū)分，展示不同級(jí)別的告警統(tǒng)計(jì)信息，新告警以聲光的方式進(jìn)行提示，方便用戶(hù)及時(shí)了解網(wǎng)絡(luò)運(yùn)行狀態(tài)，對(duì)用戶(hù)不關(guān)心的告警進(jìn)行實(shí)時(shí)過(guò)濾；同時(shí)支持用戶(hù)按條件查詢(xún)歷史告警、按需要統(tǒng)計(jì)告警信息，方便對(duì)系統(tǒng)健康趨勢(shì)做出分析，查詢(xún)或統(tǒng)計(jì)結(jié)果均支持以圖表的形式呈現(xiàn)，并支持導(dǎo)出。

性能管理：支持采集網(wǎng)元的CPU利用率、內(nèi)存利用率等指標(biāo)，支持用戶(hù)查看單個(gè)設(shè)備實(shí)時(shí)性能指標(biāo)，支持對(duì)歷史性能數(shù)據(jù)進(jìn)行查詢(xún)并導(dǎo)出。

報(bào)表管理：支持生成多種報(bào)表類(lèi)型，包括告警分布統(tǒng)計(jì)報(bào)表、告警趨勢(shì)統(tǒng)計(jì)報(bào)表、告警TOP/BOTTOM N統(tǒng)計(jì)報(bào)表、性能分布統(tǒng)計(jì)報(bào)表、性能趨勢(shì)統(tǒng)計(jì)報(bào)表、性能TOP/BOTTOM N統(tǒng)計(jì)報(bào)表。

安全管理：按照不同角色管理維護(hù)人員權(quán)限，對(duì)用戶(hù)登錄、操作行為進(jìn)行日常記錄。

4 關(guān)鍵技術(shù)實(shí)現(xiàn)

4.1 Karaf技術(shù)

為實(shí)現(xiàn)系統(tǒng)動(dòng)態(tài)模塊化組裝，高動(dòng)態(tài)、高可擴(kuò)展的設(shè)計(jì)思路，選擇Karaf容器，因其具備方便部署各種選定的組件（Bundle），具有簡(jiǎn)化打包和簡(jiǎn)化安裝應(yīng)用操作難度等優(yōu)點(diǎn)。

以本系統(tǒng)后臺(tái)Provider層為例，其包括配置組件、告警組件、性能組件、報(bào)表組件、安全組件等基本組件。當(dāng)用戶(hù)額外需要數(shù)據(jù)維護(hù)組件對(duì)數(shù)據(jù)庫(kù)數(shù)據(jù)進(jìn)行定期維護(hù)管理時(shí)，可單獨(dú)開(kāi)發(fā)數(shù)據(jù)維護(hù)組件，并熱部署到系統(tǒng)中以滿(mǎn)足用戶(hù)需求。當(dāng)用戶(hù)不需要報(bào)表功能時(shí)，可將報(bào)表組件卸載，不再消耗系統(tǒng)資源，同時(shí)保證其他功能不受影響。

目前本系統(tǒng)包括45個(gè)Bundle，根據(jù)用戶(hù)需求可對(duì)系統(tǒng)功能進(jìn)行裁剪或增加，只需將必要的Bundle熱部署到Karaf中，以最小的代價(jià)解決用戶(hù)定制化需求。

4.2 IPOJO技術(shù)

因Karaf的高動(dòng)態(tài)、高可擴(kuò)展特性，增加了開(kāi)發(fā)的復(fù)雜性，且開(kāi)發(fā)中對(duì)服務(wù)的依賴(lài)也變得復(fù)雜，服務(wù)的關(guān)系管理變得非常重要。通過(guò)引入IPOJO組件讓開(kāi)發(fā)者以簡(jiǎn)單的方式完成復(fù)雜的服務(wù)間依賴(lài)關(guān)系。

IPOJO本 著“盡 可 能 偷 懶（Be as lazy as possible）”的原則，支持注解，xml或者基于Java的API來(lái)定義組件，極大方便了對(duì)依賴(lài)服務(wù)進(jìn)行注冊(cè)。

運(yùn)維管理系統(tǒng)服務(wù)器軟件在設(shè)計(jì)之初，考慮到依賴(lài)關(guān)系的復(fù)雜性，系統(tǒng)縱向按數(shù)據(jù)流向劃分了多個(gè)層次，每個(gè)層次又按功能劃分多個(gè)功能模塊。為簡(jiǎn)化依賴(lài)關(guān)系，避免相互依賴(lài)，同一層次的模塊間不能存在依賴(lài)關(guān)系，盡可能減小模塊間的依賴(lài)，但各層之間仍不可避免的存在大量的依賴(lài)關(guān)系，如圖3所示。Store層各模塊中提供的服務(wù)的啟動(dòng)需要依賴(lài)SYSTEM CFG（系統(tǒng)基本配置信息管理）模塊，Provider層各模塊均向下依賴(lài)Store層對(duì)應(yīng)模塊，各模塊數(shù)據(jù)間的關(guān)聯(lián)帶來(lái)不可避免的依賴(lài)關(guān)系。對(duì)于開(kāi)發(fā)者來(lái)說(shuō)過(guò)于復(fù)雜的依賴(lài)關(guān)系管理起來(lái)相當(dāng)耗時(shí)費(fèi)力，需要通過(guò)大量的代碼才能實(shí)現(xiàn)，而IPOJO內(nèi)部機(jī)制可解決這個(gè)問(wèn)題，開(kāi)發(fā)者只需關(guān)注當(dāng)前服務(wù)需要依賴(lài)哪些相關(guān)服務(wù)，通過(guò)簡(jiǎn)單的注冊(cè)語(yǔ)句，就可把所需服務(wù)注入進(jìn)來(lái)，一旦注入進(jìn)來(lái)，IPOJO會(huì)托管服務(wù)整個(gè)生命周期。

圖3 運(yùn)維管理平臺(tái)服務(wù)器軟件模塊依賴(lài)關(guān)系Fig.3 Dependency diagram of server software module of operation and maintenance management platform

本系統(tǒng)中，使用注解方式簡(jiǎn)化服務(wù)依賴(lài)的寫(xiě)法，@Provider（提供）注解對(duì)外發(fā)布服務(wù)，@Required（請(qǐng)求）注冊(cè)服務(wù)，通過(guò)設(shè)置Required的參數(shù)來(lái)說(shuō)明對(duì)服務(wù)器依賴(lài)是否是強(qiáng)制性的，如果強(qiáng)制依賴(lài)，則被依賴(lài)的服務(wù)不啟動(dòng)，本服務(wù)也不會(huì)被啟動(dòng)，如果非強(qiáng)制依賴(lài)，不管被依賴(lài)的服務(wù)是否啟動(dòng)都不影響本服務(wù)啟動(dòng)，開(kāi)發(fā)人員不必寫(xiě)一個(gè)單獨(dú)、冗長(zhǎng)復(fù)雜的類(lèi)來(lái)維護(hù)所有服務(wù)的依賴(lài)關(guān)系，避免維護(hù)這個(gè)服務(wù)依賴(lài)關(guān)系類(lèi)的出錯(cuò)風(fēng)險(xiǎn)，同時(shí)極大節(jié)省了代碼量。

4.3 EventAdmin消息機(jī)制

EventAdmin是通過(guò)事件機(jī)制實(shí)現(xiàn) Bundle 間協(xié)作的標(biāo)準(zhǔn)通訊方式。

事件發(fā)布者使用 EventAdmin 服務(wù)發(fā)送基于主題(Topic) 的消息，所有關(guān)心這一主題的事件訂閱者都會(huì)收到這個(gè)消息，不同訂閱者收到這個(gè)消息后根據(jù)自己的需求去做出相應(yīng)的處理。

本系統(tǒng)中對(duì)網(wǎng)元狀態(tài)、告警狀態(tài)、配置信息等變化以不同主題發(fā)布，其他模塊對(duì)關(guān)心的主題進(jìn)行訂閱。以網(wǎng)元?jiǎng)h除為例，當(dāng)有網(wǎng)元被刪除后，Provider層的配置管理Bundle里的deviceService服務(wù)生成一條主題為deviceDelete的EventAdmin消息，并發(fā)布。如網(wǎng)元被刪除，就不再有告警，無(wú)需關(guān)注其告警狀態(tài)變化，無(wú)需采集該網(wǎng)元相關(guān)性能信息，所以告警管理Bundle及性能管理Bundle就需要訂閱這條消息。當(dāng)告警管理Bundle收到這條消息后，alarmService會(huì)處理該消息，首先恢復(fù)該網(wǎng)元下的所有活躍告警，并將該網(wǎng)元從告警狀態(tài)維護(hù)列表中刪除，不再關(guān)注該網(wǎng)元的告警狀態(tài)；當(dāng)性能管理Bundle收到這條消息后，proformSrevice會(huì)停止該網(wǎng)元的性能采集。以上是有模塊關(guān)注這條deviceDelete的EventAdmin消息的情況，如沒(méi)有模塊關(guān)注這條消息，也并不影響任何模塊的正常運(yùn)行。

系統(tǒng)軟件EventAdmin消息關(guān)系如圖4所示。

圖4 運(yùn)維管理平臺(tái)服務(wù)器軟件EventAdmin消息關(guān)系Fig.4 EventAdmin message relationship of server software of operation and maintenance management platform

以上證明，EventAmdin消息機(jī)制減少模塊間的依賴(lài)，降低模塊之間耦合度，加強(qiáng)程序的靈活性、可擴(kuò)展性。

5 開(kāi)發(fā)結(jié)果示例或應(yīng)用案例

本系統(tǒng)目前已成功應(yīng)用于神華鐵路調(diào)度信息系統(tǒng)工程項(xiàng)目，通過(guò)系統(tǒng)分布式部署，在總部及下屬4個(gè)分公司分別部署網(wǎng)絡(luò)運(yùn)維管理系統(tǒng)，在總部集中管理。系統(tǒng)管理分布在不同物理位置的網(wǎng)絡(luò)設(shè)備、服務(wù)器、存儲(chǔ)設(shè)備及終端等網(wǎng)元，實(shí)時(shí)監(jiān)控網(wǎng)元的運(yùn)行狀態(tài)及告警信息、按告警的嚴(yán)重程度進(jìn)行分級(jí)提示、提供告警統(tǒng)計(jì)分析功能、告警維護(hù)經(jīng)驗(yàn)的收集，提供必要的處理建議、性能數(shù)據(jù)的采集及分析等，用戶(hù)接口通過(guò)智能、友好的人機(jī)界面，方便運(yùn)維人員及時(shí)、準(zhǔn)確地了解網(wǎng)元的運(yùn)行狀態(tài)，并快速準(zhǔn)確的定位故障，保障通信網(wǎng)絡(luò)的正常運(yùn)行，從而提高運(yùn)維效率，降低運(yùn)維成本，保障通信網(wǎng)絡(luò)安全可靠的運(yùn)行。

運(yùn)行界面如圖5所示。

圖5 神華運(yùn)維管理系統(tǒng)示例Fig.5 Example of Shenhua operation and maintenance management system

6 結(jié)論和建議

本文通過(guò)Karaf及容器相關(guān)組件或技術(shù)在網(wǎng)管系統(tǒng)中的應(yīng)用，說(shuō)明了網(wǎng)管系統(tǒng)的設(shè)計(jì)思路，系統(tǒng)的總體架構(gòu)以及系統(tǒng)實(shí)現(xiàn)的主要功能，經(jīng)過(guò)神華現(xiàn)場(chǎng)實(shí)際應(yīng)用，證明了系統(tǒng)可高效、安全的穩(wěn)定運(yùn)行。

如考慮運(yùn)維平臺(tái)支持對(duì)更多網(wǎng)元類(lèi)型及型號(hào)的管理，還需進(jìn)一步考慮如何支持快速接入更多接口類(lèi)型網(wǎng)元，建議后續(xù)對(duì)支持多接口相關(guān)問(wèn)題做深入研究。