DOI: 10.3969/j.issn.1673-4440.2022.12.010
基于Karaf的网络运维管理系统设计与实现
蔡莉莉
（北京全路通信信号研究设计院集团有限公司，北京 100070）
摘要：研究基于Karaf的网络运维管理系统对网元集中管理及监控的技术，实现网络运营维护管理过程中的网元状态监视、拓扑展示、告警管理、性能管理、权限管理等功能。通过动态模
块化组装、iPOJO技术、EventAdmin消息处理机制等关键技术的分析和设计，提出基于Karaf 的网络运维管理系统架构，具有根据不同用户需求，动态模块化定制系统，轻量级运行的优点，可满足不同应用场景下对网络设备、服务器、存储设备、终端等类型网元的集中管理及监
控的需求。
关键词：Karaf容器；iPOJO技术；EventAdmin消息处理机制；动态模块化组装
中图分类号：TN915.07              文献标志码：A                文章编号：1673-4440(2022)12-0048-06
Design and Implementation of Network Operation and Maintenance
restful接口设计
Management System Based on Karaf
Cai Lili
(CRSC Research & Design Institute Group Co., Ltd., Beijing 100070, China)
Abstract: This paper studies the technology of centralized management and monitoring of network
elements by the network operation and maintenance management system based on Karaf, and realizes the functions of network element status monitoring, topology display, alarm management, performance management, authority management and so on. Through the analysis and design of key technologies such as dynamic modular assembly, iPOJO technology and EventAdmin message processing mechanism, a network operation and maintenance management system architecture based on Karaf platform is proposed, which has the advantages of dynamic modular customization of the system and lightweight operation according to different user needs, and can meet the requirements of centralized management and monitoring of network elements such as network devices, servers, storage devices, and terminals in different application scenarios.
Keywords: Karaf container; iPOJO technology; EventAdmin message processing mechanism;
dynamic modular assembly
收稿日期：2021-10-13；修回日期：2022-11-01
基金项目：北京全路通信信号研究设计院集团有限公司科研项目（2300-K1170025）；中国神华能源股份有限公司重大科研项目
（SHGF-20-01）
作者简介：蔡莉莉（1982—），女，工程师，本科，主要研究方向： 通信信息，邮箱：****************。
1 概述
网络运维管理系统是在城市轨道交通通信网络运行过程中，将地理位置不同的网络设备、服务器、存储设备、终端等类型网元进行统一、全面监控、维护、管理的系统，是保障通信网络可靠运行的重要手段。
网络运维管理系统在满足网络的日常维护，快速定位故障的前提下，网络拥有者和维护人员越来越期盼网络运维管理系统能提供更高端、专业和个性化的网络运维管理功能来满足不同场景下的应用需要。为了适配更多的应用场景，满足用户个性化网络运维需求，本系统利用了Karaf平台具有模块化，热部署，易扩展等优点，提出了基于Karaf的网络运维管理系统。
网络运维管理系统后台软件根据用户定制向前台页面提供数据支持服务，数据包括网元配置信息、告警信息、性能信息、权限管理、拓扑信息等。 2 Karaf相关技术介绍
Karaf：Karaf是一个轻量级的、简单、灵活的OSGi容器，本文主要介绍系统通过使用Karaf容器热部署、动态配置的特性，实现软件动态模块化组装。
IPOJO：IPOJO是一个基于OSGi的服务构件模型，其主要作用是简化OSGi的Bundle开发，解决服务间依赖复杂问题。EventAdmin消息处理机制：EventAdmin是OSGi中的一种基于发布订阅的消息处理机制，它的应用减少了模块间的依赖，降低模块之间耦合度，加强程序的灵活性、可扩展性。
3 基于Karaf的网络运维管理系统的架构/结构设计
3.1 系统架构
基于Karaf的网络运维管理系统主要由数据库服务器、网络运维管理服务器及以太网交换机组成，后台服
务器可根据功能及项目规模进行分设或合设，在工区办公室部署运维管理终端，终端通过以太网交换机实现与网络运维管理服务器间的通信。部署在各车站的网络设备、终端设备，以及部署在中心机房的网络设备、服务器设备、存储设备及终端设备，通过传输设备或以太网接口接入到中心机房的以太网交换机上，实现被管网元与网络运维管理系统服务器之间的通信，网络运维管理服务器通过网络感知网元状态，获取网元基本信息，采集设备告警，性能信息等。系统架构如图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所示。
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层各模块中提供的服务的启动
模块，Provider层各模块均向下依赖Store层对应模块，各模块数据间的关联带来不可避免的依赖关系。对于开发者来说过于复杂的依赖关系管理起来相当耗时费力，需要通过大量的代码才能实现，而IPOJO内部机制可解决这个问题，开发者只需关注当前服务需要依赖哪些相关服务，通过简单的注册语句，就可把所需服务注入进来，一旦注入进来，
法，@Provider（提供）注解对外发布服务，@ Required（请求）注册服务，通过设置Required 的参数来说明对服务器依赖是否是强制性的，如果强制依赖，则被依赖的服务不启动，本服务也不会被启动，如果非强制依赖，不管被依赖的服务是否启动都不影响本服务启动，开发人员不必写一个单独、冗长复杂的类来维护所有服务的依赖关系，避免维护这个服务依赖关系类的出错风险，同时极大节省了代码量。
4.3 EventAdmin消息机制EventAdmin是通过事件机制实现 Bundle 间协作的标准通讯方式。
事件发布者使用 EventAdmin 服务发送基于主题 (Topic) 的消息，所有关心这一主题的事件订阅者都会收到这个消息，不同订阅者收到这个消息后根据自己的需求去做出相应的处理。
本系统中对网元状态、告警状态、配置信
心的主题进行订阅。以网元删除为例，当有网元被删除后，Provider层的配置管理Bundle里的deviceService服务生成一条主题为deviceDelete 的EventAdmin消息，并发布。如网元被删除，就不再有告警，无需关注其告警状态变化，无需采集该网元相关性能信息，所以告警管理Bundle及性能管理Bundle就需要订阅这条消息。当告警管理Bundle收到这条消息后，alarmService会处理该消息，首先恢复该网元下的所有活跃告警，并将该网元从告警状态维护列表中删除，不再关注该网元的告警状态；当性能管理Bundle收到这条消息后，proformSrevice会停止该网元的性能采集。以上是有模块关注这条de
viceDelete的EventAdmin 消息的情况，如没有模块关注这条消息，也并不影响任何模块的正常运行。
系统软件EventAdmin消息关系如图4所示。以上证明，EventAmdin消息机制减少模块间
图�　运维管理平台服务器软件EventAdmin消息关系
Fig.4    EventAdmin message relationship of server software of operation and maintenance management platform
发布消息        订阅消息        向订阅者发送消息
图�　神华运维管理系统示例
Fig.5    Example of Shenhua operation and maintenance management system
的依赖，降低模块之间耦合度，加强程序的灵活性、可扩展性。
5 开发结果示例或应用案例
本系统目前已成功应用于神华铁路调度信息系
统工程项目，通过系统分布式部署，在总部及下属4个分公司分别部署网络运维管理系统，在总部集中管理。系统管理分布在不同物理位置的网络设备、服务器、存储设备及终端等网元，实时监控网元的
运行状态及告警信息、按告警的严重程度进行分级
提示、提供告警统计分析功能、告警维护经验的收集，提供必要的处理建议、性能数据的采集及分析等，用户接口通过智能、友好的人机界面，方便运
维人员及时、准确地了解网元的运行状态，并快速准确的定位故障，保障通信网络的正常运行，从而提高运维效率，降低运维成本，保障通信网络安全
可靠的运行。
运行界面如图5所示。
6 结论和建议
本文通过Karaf 及容器相关组件或技术在网管
系统中的应用，说明了网管系统的设计思路，系统的总体架构以及系统实现的主要功能，经过神华现场实际应用，证明了系统可高效、安全的稳定运行。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。