一种网络运营支撑系统的制作方法

本发明涉及通信技术领域，具体而言，涉及一种网络运营支撑系统。

背景技术：

传统的WIFI网络运营支撑系统运行于网管中心的服务器上，其系统架构至今仍沿用传统的客户端-服务器结构。由于部署在服务器级别，所以依赖于NMS部署软件，而且系统本身没有编排。

近几年，随着云技术的兴起和广泛应用，由于其具备节省成本、可扩展性及可用性好、易于编排和实施等特点，使得私有云和公有云成为网络运营支撑系统更好的选择，并在云环境中进化出新的服务。但是，现有的基于云的WIFI网络运营支撑系统都是基于虚拟服务器进行部署的，依赖于云部署软件IAAS。由于部署在虚拟机级别，所以编排依赖于NMS服务器，而且系统本身难以扩展，可用性不佳。

技术实现要素：

有鉴于此，本发明的目的在于提供一种网络运营支撑系统，以改善上述问题。

本发明较佳实施例提供一种网络运营支撑系统，该系统包括：预配置微服务，用于接收由用户层接口输入的配置数据，并将所述配置数据存储于配置数据库；配置下载微服务，用于从所述配置数据库中获取配置数据后下发至网络设备；网络管理微服务，用于对网络设备进行运行状态及配置数据的监控管理，并根据在监控管理过程中获取的数据生成分析报表；分析微服务，用于为该网络运营支撑系统的所有分析需求提供算法支持；以及主数据库，用于同步存储各微服务的运行数据以及不同微服务的运行数据之间的数据模型，以进行数据的统一维护。

优选地，所述主数据库为采用图结构建立不同微服务的运行数据之间的数据模型的图形数据库。

优选地，该网络运营支撑系统中的每个微服务基于独立的容器实现，各个微服务的运行数据以数据库存储、文件存储及写入内存或缓存三种数据存储模式中的至少一种模式进行存储。

优选地，该系统还包括通信微服务，其中：所述网络管理微服务、配置下载微服务及通信微服务之间通过消息队列进行信息交互，其中，所述网络管理微服务对网络设备进行配置数据的监控管理的过程包括：

所述网络管理微服务通过所述消息队列将所述配置下载或升级请求发送至所述配置下载微服务；所述配置下载微服务根据所述配置下载或升级请求从所述配置数据库中获取到相应的配置数据后，将获取到的配置数据发送至所述通信微服务；所述通信微服务接收到所述配置数据后，再将该配置数据发送至所述网络设备。

优选地，该系统还包括：业务运营微服务，用于对所述网络运营支撑系统的业务进行运营管理，该业务运营微服务的运行数据存储于运营关系数据库中，所述主数据库与该运营关系数据库连接，以对所述业务运营微服务的运行数据进行同步存储。

优选地，该系统还包括：数据收集聚合微服务，用于从所述网络设备及各微服务中收集日志和统计信息，并将收集到的信息保存到NoSQL数据库中；诊断微服务，用于在所述分析微服务的配合下，基于保存到所述NoSQL数据库中或所述主数据库中的数据对该网络运营支撑系统的故障进行实时诊断。

优选地，该系统还包括：故障定位微服务，用于根据所述诊断微服务的诊断结果对故障进行实时排除。

本发明实施例提供的应用于WIFI网络的运营支撑系统采用基于容器实现的微服务架构，系统本身具有良好的可扩展性和可用性，无需依赖编排软件，支持云环境中的自动化和编排，更易实现组件和服务，以及在云环境中进一步演进新的服务。此外，该系统中还采用主数据库将各个微服务的运行数据链接在一起，进行统一的数据维护，提高系统的分析效率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明实施例提供的一种基于微服务架构的网络运营支撑系统的系统框架示意图；

图2为本发明实施例提供的另一种基于微服务架构的网络运营支撑系统的系统框架示意图。

图标：100-网络运营支撑系统；102-预配置微服务；104-配置下载微服务；106-网络管理微服务；108-分析微服务；110-用户界面微服务；112-通信微服务；114-业务运营微服务；116-数据收集聚合微服务；118-诊断微服务；120-故障定位微服务；101-主数据库；103-配置数据库；105-网管关系数据库；107-消息队列；109-运营关系数据库；111-NoSQL数据库。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

微服务架构(Microservices Architecture)是一种架构风格和设计模式，其开发方式是将应用分解为一组可独立部署、小型化、模块化的微服务，每个微服务运行于独立的进程中，微服务之间边界清晰，采用轻量级通信机制进行交互，通过版本化的API(Application Programming Interface，应用程序编程接口)和数据存储来服务于特定的商业目标。

本发明实施例中，将所述微服务架构应用于网络运营支撑系统的开发中，将原网络管理及运维服务按照功能边界分解成一组可在云服务器级别进行独立部署、编译和扩展的微服务模块。与现有技术中的部署于物理服务器级别或虚拟主机级别的网络运营支撑系统相比，具有更好的可扩展性和可用性，支持云环境下的自动化和编排，无需依赖编排软件。此外，本实施例提供的系统中，基于主数据库进行的统一数据维护，解决了现有微服务结构中各微服务的运行数据难以建立数据链接的难题，更进一步提升了系统的分析效率，从而使对系统的实时诊断和故障排除成为可能。

需要强调的是，本发明实施例提供的网络运营支撑系统可以应用于WIFI网络系统的管理和运维，但并不限制于此。

下面将以WIFI网络为例，并结合附图，对本发明实施例提供的所述网络运营支撑系统的实现原理进行详细的阐述。所应理解的是，下述实施例提供的微服务架构仅是示例性的，其中包含的各基础微服务及可选微服务在其他实施例中可以进行相互变换或者根据实际需求进行另外的服务设计、功能边界划分等。所述基础微服务是指网络运营支撑系统中核心(必要)的微服务，所述可选微服务可以是指网络运营支撑系统中用于进一步优化系统的微服务。

如图1所示，作为一种实施方式，本实施例提供一种仅包含基础微服务及主数据库101的网络运营支撑系统100的系统架构图。其中，所述基础微服务包括预配置微服务102、配置下载微服务104、网络管理微服务106以及分析微服务108。本实施例中，该网络运营支撑系统100的每个微服务均是基于独立的容器(如Docker容器)实现。下面对图1所示的各微服务的功能进行描述。

所述预配置微服务102用于接收由用户层接口输入的配置数据，并将所述配置数据存储于配置数据库103中。也就是说，用户通过所述用户层接口输入的配置数据将最终交付至所述预配置微服务102，由该预配置微服务102进行持久化。当然，在其他实施例中，所述预配置微服务102还可以用于检查配置的有效性。此外，所述配置数据也可以直接存储于主数据库101中，而无需另设配置数据库103。

所述配置下载微服务104用于从所述配置数据库103中获取配置数据后下发至网络设备。所述网络设备可以是无线控制器以及与所述无线控制器通信连接的无线接入点，但并不限制于此。所述无线控制器通过CAPWAP隧道对无线接入点进行管理，当所述无线控制器接收到配置下载微服务104下发的配置数据后，再通过所述CAPWAP隧道将配置数据发送给无线接入点。

所述网络管理微服务106用于对所述网络设备进行运行状态及配置数据的监控管理，并根据在监控管理过程中获取的数据生成分析报表。应注意的是，在其他实施例中，所述网络管理微服务106还可以具备其他功能，比如已有网管服务中的系统管理、拓扑管理功能等。

所述分析微服务108用于为该网络运营支撑系统100的所有分析需求提供算法支持，如为所述网络管理微服务106在统计报表时提供相应的分析算法。

所述主数据库101用于同步存储各微服务的运行数据以及不同微服务的运行数据之间的数据模型，以进行数据的统一维护，进而提升系统的分析效率。本实施例中，所述主数据库101采用图形数据库实现。所述图形数据库通过图结构建立不同微服务的运行数据之间的数据模型，以满足树形存储结构的需求。

需要说明的是，各微服务的运行数据可以以数据库存储、文件存储及写入内存或缓存三种数据存储模式中的至少一种模式进行存储。也就是说，本实施例提供的网络运营支撑系统100中，允许微服务的运行数据的存储模式与主数据库101不同。例如，所述预配置微服务102将配置数据存储于配置数据库103中，所述网络管理微服务106可以将运行数据中的适于结构化存储的数据(如设备仓库等)存储于网管关系数据库105中，将其他运行数据写入缓存或内存。

关于所述配置下载微服务104，更为具体的是，其进行配置数据下发通常包括如下两种情形：

其一是，响应所述网络管理微服务106发起的配置下载或升级请求，从所述配置数据库103中获取与所述请求相应的配置数据后，下发至所述网络设备。

其二是，主动从所述配置数据库103中获取配置数据后下发至网络设备。所述配置数据库103中存储有用于记载已被所述预配置微服务102更新的配置数据的数据表。所述配置下载微服务104按照预定的时间表对所述数据表进行更新检测，一旦发现存在已被更新的配置数据，所述配置下载微服务104则获取当前所有已被更新的配置数据并下发至所述网络设备。

本实施例提供的网络运营支撑系统100中各微服务以服务组件形式存在。在一些实施例中，部分微服务可以进一步根据功能边界划分为多个可部署的子服务组件。在另外一些实施例中，该网络运营支撑系统100中的某两个或两个以上的微服务还可以合并为一个微服务，例如，作为一种实施方式，所述预配置微服务102与所述配置下载微服务104可以合并为一个配置微服务，该配置微服务可以统筹负责系统的数据配置操作。

本实施例中，各微服务可通过所述用户层接口被访问。此外，应强调的是，虽然图1中未示出各微服务间的信息交互关系，但不同微服务之间的相互访问(比如网络管理微服务106与配置下载微服务104之间的信息交互)可以通过远程访问协议(如AMQP、REST等)实现。而且通常一个微服务会与其他一个甚至多个微服务之间存在信息交互，比如分析微服务108是为系统中的所有分析需求提供算法支持，所以其可能与其他每个微服务都存在着信息交互关系。

如图2所示，是本发明实施例提供的另一种网络运营支撑系统100的系统架构图。与图1所示的不同的是，本实施例提供的系统还包括用于进一步优化系统服务的微服务。

具体地，除图1中所示的各基础微服务外，该系统还包括用户界面微服务110、通信微服务112、业务运营微服务114、数据收集聚合微服务116、诊断微服务118以及故障定位微服务120。下面将对各微服务的功能进行详细阐述。

所述用户界面微服务110用于提供图形用户界面形式的用户层接口，以供用户通过该图形用户界面访问所有微服务。本实施例中，所述预配置微服务102接收到的配置数据可以是用户通过所述图形用户界面输入的配置信息。

所述通信微服务112用于下发配置数据以及监测数据下发状态。该通信微服务112可以是但不限于，ONOS或OpenDayLight模块。本实施例中，所述网络管理微服务106、配置下载微服务104及通信微服务112之间通过消息队列107(如RabbitMQ)进行信息交互。下面将示例性的举出两种可能的交互过程。

其一，所述网络管理微服务106对网络设备进行配置数据的监控管理的过程中，通过所述消息队列107将配置下载或升级请求发送至所述配置下载微服务104后，所述配置下载微服务104响应该请求，从所述配置数据库103中获取到相应的配置数据后，将获取到的配置数据发送至所述通信微服务112。所述通信微服务112接收到所述配置数据后，再将该配置数据发送至所述网络设备。

其二，当所述通信微服务112监测到通过网络配置协议(Netconf协议)向所述网络设备发送配置数据失败时，该通信微服务112将把配置数据下发失败的详细信息发送至消息队列107，再由所述消息队列107将接收到的下发失败的信息发送至配置下载微服务104，由所述配置下载微服务104将其记录于配置数据库103的数据表中。

本实施例中，引入消息队列107的作用在于实现微服务间的解耦和削峰。既可以通过消息队列107的通知机制完成一对多的通信，又能够减轻高并发抖动时对系统造成的压力。

所述业务运营微服务114用于对所述网络运营支撑系统100的业务进行运营管理及提供服务支持，例如服务注册、激活、计费、排名等。该业务运营微服务114的运行数据存储于运营关系数据库109中。所述主数据库101与该运营关系数据库109连接，以对所述业务运营微服务114的运行数据进行同步存储。

所述数据收集聚合微服务116用于从所述网络设备及各微服务中收集日志和统计信息，并将收集到的信息保存到NoSQL数据库111(如Cassandra数据库)中。NoSQL数据库111可以在云环境中高效地存储数据，具有出色的可扩展性和可用性。然而，由于NoSQL数据库111的无模式特点，存储于NoSQL数据库111中的数据之间的关系通常很难被描述。本实施例中，所述网络管理微服务106可以与所述NoSQL数据库111连接，以根据其中存储的数据进行分析，对网络设备进行更好的监控管理。

所述诊断微服务118用于在所述分析微服务108的配合下，基于保存到所述NoSQL数据库111中或所述主数据库101中的数据对该网络运营支撑系统100的故障进行实时诊断，查找出故障原因及相关信息。

所述故障定位微服务120用于根据所述诊断微服务118的诊断结果对故障进行实时排除。该故障定位微服务120为诊断出的故障提供修复方案，并根据所述修复方案进行故障排除，使系统以最小的成本恢复到正常工作状态。

所应说明的是，在其他实施例中，所述网络运营支撑系统100还可以包括第三方应用的服务组件，以根据第三方应用反馈的数据对网络进行优化管理。

此外，在一些实施例中，所述网络运营支撑系统100还可以仅包括上述可选微服务中的部分。比如，在一实施例中，该系统除上述基础微服务外，仅包括所述通信微服务112和业务运营微服务114。在另一实施例中，该系统除上述基础微服务外，仅包括所述数据收集聚合微服务116、诊断微服务118和故障定位微服务120。

另外，与图1类似地，图2中部分微服务之间的信息交互关系未示出，但应理解，当两个不同微服务之间需要进行访问时，可以通过消息队列107实现通信。

在本实施例提供的网络运营支撑系统100的实际开发过程中，可以采用Mesos和Marathon框架。这种框架完全自动化和集成敏捷过程，开发人员可以负责微服务及其容器的开发，以及后续运营支持和生命周期管理。

综上所述，本发明实施例提供的部署于云服务器级别的网络运营支撑系统100具有良好的可扩展性和可用性，支持云环境下的自动化和编排。另外，由于各微服务具备独立的运行进程，所以基于微服务结构的网络运营支撑系统100可以实现微服务的独立和实时部署，有效提升了系统整体的部署效率。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统也可以通过其它的方式实现。以上所描述的实施例仅仅是示意性的。

本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)实现本发明各个实施例所述微服务的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。