基于Karaf的網(wǎng)絡(luò)運維管理系統(tǒng)設(shè)計與實現(xiàn)

蔡莉莉

（北京全路通信信號研究設(shè)計院集團有限公司，北京 100070）

1 概述

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

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

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

網(wǎng)絡(luò)運維管理系統(tǒng)后臺軟件根據(jù)用戶定制向前臺頁面提供數(shù)據(jù)支持服務(wù)，數(shù)據(jù)包括網(wǎng)元配置信息、告警信息、性能信息、權(quán)限管理、拓撲信息等。

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

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

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

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

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

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

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

部署在各車站的網(wǎng)絡(luò)設(shè)備、終端設(shè)備，以及部署在中心機房的網(wǎng)絡(luò)設(shè)備、服務(wù)器設(shè)備、存儲設(shè)備及終端設(shè)備，通過傳輸設(shè)備或以太網(wǎng)接口接入到中心機房的以太網(wǎng)交換機上，實現(xiàn)被管網(wǎng)元與網(wǎng)絡(luò)運維管理系統(tǒng)服務(wù)器之間的通信，網(wǎng)絡(luò)運維管理服務(wù)器通過網(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)，前臺Web使用Vue框架，后臺服務(wù)軟件基于Karaf容器進行開發(fā)，采用結(jié)構(gòu)化方法對系統(tǒng)進行模塊劃分，各模塊盡量做到相互獨立，以增加軟件的可靠性及可用性。

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

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

3.3 系統(tǒng)功能

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

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

拓撲管理：根據(jù)設(shè)備信息自動生成綜合網(wǎng)絡(luò)拓撲圖，對設(shè)備連接關(guān)系進行展示，并能夠在拓撲圖中動態(tài)展示各節(jié)點的告警狀態(tài)。

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

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

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

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

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

4.1 Karaf技術(shù)

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

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

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

4.2 IPOJO技術(shù)

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

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

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

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

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

4.3 EventAdmin消息機制

EventAdmin是通過事件機制實現(xiàn) Bundle 間協(xié)作的標準通訊方式。

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

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

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

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

以上證明，EventAmdin消息機制減少模塊間的依賴，降低模塊之間耦合度，加強程序的靈活性、可擴展性。

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

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

運行界面如圖5所示。

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

6 結(jié)論和建議

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

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