基于Karaf的網絡運維管理系統設計與實現

蔡莉莉

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

1 概述

網絡運維管理系統是在城市軌道交通通信網絡運行過程中，將地理位置不同的網絡設備、服務器、存儲設備、終端等類型網元進行統一、全面監控、維護、管理的系統，是保障通信網絡可靠運行的重要手段。

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

為了適配更多的應用場景，滿足用戶個性化網絡運維需求，本系統利用了Karaf平臺具有模塊化，熱部署，易擴展等優點，提出了基于Karaf的網絡運維管理系統。

網絡運維管理系統后臺軟件根據用戶定制向前臺頁面提供數據支持服務，數據包括網元配置信息、告警信息、性能信息、權限管理、拓撲信息等。

2 Karaf相關技術介紹

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

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

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

3 基于Karaf的網絡運維管理系統的架構/結構設計

3.1 系統架構

基于Karaf的網絡運維管理系統主要由數據庫服務器、網絡運維管理服務器及以太網交換機組成，后臺服務器可根據功能及項目規模進行分設或合設，在工區辦公室部署運維管理終端，終端通過以太網交換機實現與網絡運維管理服務器間的通信。

部署在各車站的網絡設備、終端設備，以及部署在中心機房的網絡設備、服務器設備、存儲設備及終端設備，通過傳輸設備或以太網接口接入到中心機房的以太網交換機上，實現被管網元與網絡運維管理系統服務器之間的通信，網絡運維管理服務器通過網絡感知網元狀態，獲取網元基本信息，采集設備告警，性能信息等。系統架構如圖1所示。

圖1 系統架構示意Fig.1 Schematic diagram of system architecture

3.2 軟件架構

系統采用B/S軟件架構，前臺Web使用Vue框架，后臺服務軟件基于Karaf容器進行開發，采用結構化方法對系統進行模塊劃分，各模塊盡量做到相互獨立，以增加軟件的可靠性及可用性。

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

圖2 系統軟件架構設計Fig.2 System software architecture design drawing

3.3 系統功能

系統具備對網絡設備、存儲設備、服務器設備、終端設備等網元統一運維監控功能。主要實現網元狀態監視、告警實時上報、網元故障診斷等，主要功能如下。

數據采集：支持采集各類型網元的運行狀態、告警信息、性能信息等，處理后存儲到數據庫中。

拓撲管理：根據設備信息自動生成綜合網絡拓撲圖，對設備連接關系進行展示，并能夠在拓撲圖中動態展示各節點的告警狀態。

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

性能管理：支持采集網元的CPU利用率、內存利用率等指標，支持用戶查看單個設備實時性能指標，支持對歷史性能數據進行查詢并導出。

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

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

4 關鍵技術實現

4.1 Karaf技術

為實現系統動態模塊化組裝，高動態、高可擴展的設計思路，選擇Karaf容器，因其具備方便部署各種選定的組件（Bundle），具有簡化打包和簡化安裝應用操作難度等優點。

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

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

4.2 IPOJO技術

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

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

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

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

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

4.3 EventAdmin消息機制

EventAdmin是通過事件機制實現 Bundle 間協作的標準通訊方式。

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

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

系統軟件EventAdmin消息關系如圖4所示。

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

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

5 開發結果示例或應用案例

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

運行界面如圖5所示。

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

6 結論和建議

本文通過Karaf及容器相關組件或技術在網管系統中的應用，說明了網管系統的設計思路，系統的總體架構以及系統實現的主要功能，經過神華現場實際應用，證明了系統可高效、安全的穩定運行。

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