CN111917587A - 利用服务系统进行网络服务管理的方法及服务系统 - Google Patents

Abstract

本公开提供了一种利用服务系统进行网络服务管理的方法及该服务系统、计算机系统和计算机可读存储介质，可用于大数据领域或其他领域，其中，该方法包括：获取第一网络配置变更请求获取数据库中存储的网络配置信息；根据第一网络配置变更请求和网络配置信息生成第一网络配置策略；以及根据第一网络配置策略调整网络配置信息。

Description

利用服务系统进行网络服务管理的方法及服务系统

技术领域

本公开涉及大数据领域和网络服务管理领域，更具体地，涉及一种利用服务系统进行网络服务管理的方法及服务系统、计算机系统和计算机可读存储介质。

背景技术

随着互联网应用的快速迭代，相对应的应用网络变更数量快速增长。因应互联网浪潮中对业务需求极速响应的渴求，传统的运维方法已经不足以支撑现在的业务需求，因此，在迭代周期和上线方式上，针对应用网络部署的灵活度演进随之到来。应用网络的部署，不可避免要进行不同用户之间的通信，尤其是具有不同网络知识的用户之间的通信。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题，由于部门间、及部门与用户间的隔离，导致运维人员需要花费大量时间通过沟通来了解实际应用需求，然后人工编写方案实施变更，这势必会浪费大量时间和人力用于沟通，无法满足应用快速部署灵活上线的需求，同时也无法保证变更的正确率。

发明内容

有鉴于此，本公开提供了一种利用服务系统进行网络服务管理的方法及服务系统、计算机系统和计算机可读存储介质。

本公开的一个方面提供了一种利用服务系统进行网络服务管理的方法，包括：获取第一网络配置变更请求；获取数据库中存储的网络配置信息；根据所述第一网络配置变更请求和所述网络配置信息生成第一网络配置策略；以及根据所述第一网络配置策略调整所述网络配置信息。

根据本公开的实施例，其中，所述预设数据格式包括字符串、数字和文本其中至少之一，所述网络配置信息包括与域名相关的配置信息和与负载均衡相关的配置信息其中至少之一。

根据本公开的实施例，该方法还包括，在根据所述第一网络配置变更请求和所述网络配置信息生成第一网络配置策略之前，将所述第一网络配置变更请求提交审核；以及在所述第一网络配置变更请求审核通过后，根据所述第一网络配置变更请求和所述网络配置信息生成所述第一网络配置策略。

根据本公开的实施例，该方法还包括：在获取所述第一网络配置变更请求之后，并在根据所述第一网络配置策略调整所述网络配置信息之前，获取第二网络配置变更请求；根据所述第二网络配置变更请求和所述网络配置信息生成第二网络配置策略；将所述第一网络配置策略和所述第二网络配置策略中相同的配置策略内容进行合并处理，将所述第一网络配置策略和所述第二网络配置策略中不同的配置策略内容分别进行处理，以调整所述网络配置信息。

根据本公开的实施例，该方法还包括：将所述第一网络配置变更请求和所述第一网络配置策略记录在所述数据库中，以实现能够响应配置查询功能。

本公开的另一个方面提供了一种服务系统，包括：需求管理模块，用于获取第一网络配置变更请求；配置解析模块，用于获取数据库中存储的网络配置信息；策略管理模块，用于根据所述第一网络配置变更请求和所述网络配置信息生成第一网络配置策略；以及配置修改模块，用于根据所述第一网络配置策略调整所述网络配置信息。

根据本公开的实施例，该系统还包括：审核模块，用于将所述第一网络配置变更请求提交审核并输出审核结果。

根据本公开的实施例，该系统还包括，合并模块，在获取所述第一网络配置变更请求之后，并在根据所述第一网络配置策略调整所述网络配置信息之前，获取第二网络配置变更请求，根据所述第二网络配置变更请求和所述网络配置信息生成第二网络配置策略；以及所述合并模块用于将所述第一网络配置策略和所述第二网络配置策略中相同的配置策略内容进行合并处理。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，通过获取第一网络配置变更请求，获取数据库中存储的网络配置信息，根据第一网络配置变更请求和网络配置信息生成第一网络配置策略，以及根据第一网络配置策略调整网络配置信息的技术手段。由于将底层网络配置信息以预设数据格式存储在数据库中，并将网络配置变更请求、网络配置信息和网络配置策略均集成在一个服务系统内实现，至少部分地克服了具有不同网络知识的用户之间的通信的技术问题，进而达到了资源有效共享、跨专业沟通高效开展、减少理解歧义以及在线申请到配置下发的全流程自动化，并进一步提升变更效率及正确性等技术效果。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用该利用服务系统进行网络服务管理的方法及该服务系统的示例性系统架构；

图2示意性示出了根据本公开实施例的利用服务系统进行网络服务管理的方法的流程图；

图3示意性示出了根据本公开实施例的获取数据库中存储的具有预设数据格式的网络配置信息的流程图；

图4示意性示出了根据本公开实施例的根据第一网络配置变更请求和网络配置信息生成第一网络配置策略之前的方法的流程图；

图5示意性示出了根据本公开实施例的响应配置查询功能的实现方式；

图6示意性示出了根据本公开实施例的应用用户端利用服务系统进行网络服务管理的方法的流程图；

图7示意性示出了根据本公开实施例的运维人员端利用服务系统进行网络服务管理的方法的流程图；

图8示意性示出了根据本公开的实施例的服务系统的框图；以及

图9示意性示出了根据本公开实施例的适于实现利用服务系统进行网络服务管理的方法的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

传统的运维方法，一般通过线下的交流沟通获取应用需求，然后针对应用需求进行方案编写，之后才进行应用部署。针对传统运维方法，在实现本公开的构思过程中发明人发现，线下交流沟通时，因为用户与运维人员对网络知识的储备不同，势必会浪费大量时间，甚至可能会无法准确定位用户需求，从而无法保证应用部署的正确率即灵活性。

因此，本公开实施例提供了一种利用服务系统进行网络服务管理的方法及该服务系统，可以通过该系统实现应用资源的视图化展现，从而实现资源有效共享；并且该方法可消除不同设备间的差异，使跨专业的沟通也能高效开展；通过该系统和方法还可实现在现申请到配置下发的全流程自动化，提升变更效率及正确性。

本公开的实施例提供了一种利用服务系统进行网络服务管理的方法及该服务系统。其中，该方法包括：获取第一网络配置变更请求；获取数据库中存储的网络配置信息；根据第一网络配置变更请求和网络配置信息生成第一网络配置策略；以及根据第一网络配置策略调整网络配置信息。

图1示意性示出了根据本公开实施例的可以应用该利用服务系统进行网络服务管理的方法及该服务系统的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线和/或无线通信链路等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，也可以通过网络104实现终端设备101、102、103之间的交互，通过在终端设备101、102、103或服务器105上安装上述服务系统，以进行线上的网络服务管理。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所发出的请求提供支持的后台管理服务器。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果反馈给终端设备。

需要说明的是，本公开实施例所提供的利用服务系统进行网络服务管理的方法一般可以由服务器105执行。相应地，本公开实施例所提供的服务系统一般可以设置于服务器105中。本公开实施例所提供的利用服务系统进行网络服务管理的方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的服务系统也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。或者，本公开实施例所提供的利用服务系统进行网络服务管理的方法也可以由终端设备101、102、或103执行，或者也可以由不同于终端设备101、102、或103的其他终端设备执行。相应地，本公开实施例所提供的服务系统也可以设置于终端设备101、102、或103中，或设置于不同于终端设备101、102、或103的其他终端设备中。

例如，网络配置信息及网络配置策略可以原本存储在终端设备101、102、或103中的任意一个(例如，终端设备101，但不限于此)之中，或者存储在外部存储设备上并可以导入到终端设备101中。然后，终端设备101可以在本地执行本公开实施例所提供的利用服务系统进行网络服务管理的方法，或者将网络配置信息及网络配置策略发送到其他终端设备、服务器、或服务器集群，并由接收该网络配置信息及网络配置策略的其他终端设备、服务器、或服务器集群来执行本公开实施例所提供的利用服务系统进行网络服务管理的方法。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

需要说明的是，本公开利用服务系统进行网络服务管理的方法及该服务系统、计算机系统和计算机可读存储介质可用于大数据领域，也可用于除大数据领域之外的任意领域，本公开利用服务系统进行网络服务管理的方法及该服务系统、计算机系统和计算机可读存储介质的应用领域不做限定。

图2示意性示出了根据本公开实施例的利用服务系统进行网络服务管理的方法的流程图。

根据本公开的实施例，该服务系统用于管理网络配置信息，服务系统中包括不同的用户角色以及不同用户角色相对应的角色视图和功能，用户角色包括但不限于应用用户和运维人员，对应的角色功能分别为应用用户功能和运维人员功能。

其中，应用用户功能包括但不限于针对现有网络系统的配置查询功能，根据查询结果需要提交申请变更配置时的需求申请功能，以及针对需求申请提交后的进度查询功能等；运维人员功能包括但不限于针对现有网络系统的配置查询功能，针对应用用户提交的需求申请及实施时的状态查询功能，以及通过运维人员自身实施的变更管理功能。

进一步的，应用用户视图包括将现有网络系统的配置查询结果以应用用户可理解的视图方式展现，具体地，将相关设备参数翻译为需求申请时需要填写的内容，以得到需求申请视图；运维人员视图包括将现有网络系统的配置查询结果以运维视角展现，具体地，直接显示设备配置参数，以得到网络配置的视图化展现；应用用户视图和运维人员视图中均包括对应用用户需求申请的进度查询视图，进度查询结果包括需求申请为待提交、待审核、已审核、已完成或已取消等状态；以及运维人员视图中还包括通过运维人员自身实施变更管理的视图。

如图2所示，该利用服务系统进行网络服务管理的方法包括操作S201～S204。

在操作S201，获取第一网络配置变更请求。

根据本公开的实施例，第一网络配置变更请求可以是来自应用用户的需求申请，且需求申请包括针对现有网络配置进行新增配置和修改或删除配置等变更申请，或应急申请，本公开实施例中主要针对变更申请着重阐述。

在操作S202，获取数据库中存储的网络配置信息。

根据本公开的实施例，数据库可以是传统通用的各类数据库，内置于该服务系统或与该服务系统有通信连接关系，网络配置信息以预设数据格式存储于数据库中，预设数据格式为根据实际选用的数据库支持的数据格式来设定，具有预设数据格式的网络配置信息主要是将实际的网络配置转化为符合该预设数据格式的结构化、层次化的数据，然后将其存储入相对应的数据库中。

在操作S203，根据第一网络配置变更请求和网络配置信息生成第一网络配置策略。

根据本公开的实施例，第一网络配置策略是用于实现上述的第一网络配置变更请求而制定的策略。

根据本公开的实施例，在接收到来自应用用户的关于网络配置变更的需求申请的情况下，系统自动从数据库中查询得到现有的网络配置信息，如果用户的需求申请与现有的网络配置存在冲突，则系统会直接提示冲突而无法继续申请，如果用户的需求申请与现有的网络配置不存在冲突，且在用户的需求申请合理的情况下，由系统自动基于现有的网络配置制定并生成该第一网络配置策略，以实现该应用用户的需求申请。

在操作S204，根据第一网络配置策略调整网络配置信息。

根据本公开的实施例，基于上一步操作得到的第一网络配置策略，由系统自动调整当前网络配置，以最终实现应用用户的需求申请。同时将调整后的网络配置信息录入数据库，以便于能够执行下一次用户的需求申请。

在本公开实施例中，服务系统首先获取应用用户的需求申请，然后根据数据库中的网络配置信息确认该需求申请可行之后，由服务系统自动生成相应的网络配置策略，对原始的网络配置信息进行调整，以响应应用用户的需求申请。

通过本公开实施例，在一个服务系统中同时集成应用用户功能和现有网络系统的网络配置信息，可实现网络配置对应用用户的资源有效共享，同时，服务系统中通过数据库存储的具有预设数据格式的网络配置信息，将散落在网络设备中的应用资源进行统一管理，并最终以视图化方式展现，进一步为用户快速查询相关信息提供了方便。

下面参考图3～图5，结合具体实施例对图2所示的方法做进一步说明。

图3示意性示出了根据本公开实施例的获取数据库中存储的具有预设数据格式的网络配置信息的流程图。

根据本公开的实施例，上述的预设数据格式包括字符串、数字和文本其中至少之一，上述的网络配置信息包括与域名相关的配置信息和与负载均衡相关的配置信息其中至少之一。

如图3所示，该获取方法包括操作S301～S305。

在操作S301，获取多个网络设备的标识信息和类型信息。

根据本公开的实施例，每个网络设备均具有确定其自身身份信息的设备标识符(即标识信息)，网络设备类型包括但不限于服务器、交换机、集线器、路由器和终端设备等，其类型信息用不同的设定数据加以区分及表示。

在操作S302，确定每个网络设备的类型信息相匹配的配置信息。

根据本公开的实施例，配置信息包括但不限于相同或不同类型的网络设备间的负载均衡配置方式和域名解析配置方式。

在操作S303，对每个网络设备的配置信息进行解析并转化为结构化的配置信息。

根据本公开的实施例，该解析结果为获得各个网络设备及其分别对应的具体的网络配置方式，结构化的配置信息包括符合预设数据格式的存储网络设备的数据和存储网络配置方式的数据。

在操作S304，将每个网络设备的标识信息、类型信息和结构化的配置信息进行关联，得到具有预设数据格式的网络配置信息。

根据本公开的实施例，具有预设数据格式的网络配置信息包括上述的标识信息、类型信息、结构化的配置信息以及其间具有的关联信息，该关联信息包括但不限于实现负载均衡的相同或不同类型的网络设备间的配置信息、实现域名解析的相同或不同类型的网络设备间的配置信息和同时实现负载均衡和域名解析的相同或不同类型的网络设备间的配置信息等。

在操作S305，将具有预设数据格式的网络配置信息存储在数据库中。

根据本公开的实施例，在配置信息为域名解析配置方式的情况下，写入数据库的上述具有预设数据格式的网络配置信息例如可以为以字符串格式存储在数据库中的包括域名、域名类型(如普通域名、智能域名等)、域名对应ip、健康检查方式、健康检查端口和深度健康检查路径及返回等的字段信息。其中，健康检查端口还可以是以数据格式存储的字段信息，其他字段信息例如还可以是以文本类型格式存储的字段信息，文本类型格式例如可以包括varchar(可变长字符串)或text(文本)等。

根据本公开的实施例，在配置信息为负载均衡配置方式的情况下，写入数据库的上述具有预设数据格式的网络配置信息例如可以为以字符串格式存储在数据库中的包括虚地址、虚地址对外端口、下挂服务器列表、连接时间、会话保持方式、会话保持时间、源地址转换列表、健康检查方式、健康检查端口、深度健康检查路径及返回和下挂服务器节点优先级、权重等的字段信息。其中，下挂服务器列表例如可以为一个由包括ip和端口构成的单独表的形式存在，虚地址对外端口、下挂服务器列表中的端口、连接时间、会话保持时间、健康检查端口和下挂服务器节点优先级、权重还可以是以数据格式存储的字段信息，其他字段信息例如还可以是以文本类型格式存储的字段信息。

在本公开实施例中，首先获取全量在线设备及设备类型，并根据负载均衡或域名解析设备选取对应的配置抓取方法，进行配置抓取；然后根据负载均衡或域名解析设备类型结合配置抓取结果进行配置解析；之后将不同设备类型的配置数据转化为统一的结构化数据，并写入数据库；最后将负载均衡配置和域名解析配置进行关联，并根据不同专业(应用用户和运维人员)的需求进行翻译，翻译结果即在服务系统中表现为应用用户的需求申请视图和运维人员的网络配置的视图化展现。以为应用用户的需求申请通过更加便捷的申请方式。

通过本公开实施例，将网络底层各设备间的差异屏蔽，将网络配置信息转化为结构化、层次化数据，并存储入数据库中，同时，以此为支撑，在服务系统中得到包括应用用户和运维用户等不同用户角色下对网络配置信息的在线化、可视化的展现，该展现形式将底层网络属性进行封装，降低了用户角色对网络知识的要求，可确保不同用户角色间沟通时的高效开展，帮助应用专业更好地理解网络参数，减少理解歧义，并将沟通确认时间缩短，使得跨专业的沟通也能高效开展。

图4示意性示出了根据本公开实施例的根据第一网络配置变更请求和网络配置信息生成第一网络配置策略之前的方法的流程图。

如图4所示，该方法包括操作S401～S405。

在操作S401，将第一网络配置变更请求提交审核。

根据本公开的实施例，该审核过程由运维人员执行。

在操作S402，在第一网络配置变更请求审核通过后，根据第一网络配置变更请求和网络配置信息生成第一网络配置策略。

根据本公开的实施例，审核是否通过由运维人员根据应用用户需求申请的合理性来判断，需求合理时审核通过，审核通过后才结合当前网络配置信息生成相应的网络配置策略。

进一步的，根据本公开的实施例，该方法还包括操作S403～S405。

在操作S403，在获取第一网络配置变更请求之后，并在根据第一网络配置策略调整网络配置信息之前，获取第二网络配置变更请求。

根据本公开的实施例，第二网络配置变更请求为来自应用用户的另一需求申请，且该需求申请包括与第一网络配置变更请求相同的针对现有网络配置进行的新增配置和修改或删除配置等需求申请。

在操作S404，根据第二网络配置变更请求和网络配置信息生成第二网络配置策略。

根据本公开的实施例，第二网络配置策略为基于现有的网络配置制定的可实现该应用用户的该另一需求申请的一种具体的网络配置方式，其基于的网络配置与第一网络配置策略基于的网络配置相同。

在操作S405，将第一网络配置策略和第二网络配置策略中相同的配置策略内容进行合并处理，将第一网络配置策略和第二网络配置策略中不同的配置策略内容分别进行处理，以调整网络配置信息。

根据本公开的实施例，同一或不同应用用户提出多个需求申请且均审核通过后得到相应的多种网络配置策略包含全部或部分相同的配置策略内容时，服务系统将该相同的配置策略内容合并处理。

综上，在本公开实施例中，应用用户的需求申请需要由服务系统提交运维人员审核，运维人员将审核通过的结果返回至服务系统后再由服务系统生成网络配置策略，多个审核通过的需求申请对应的多种网络配置策略存在相同的配置策略内容时，对其中相同的配置策略内容进行合并处理，并对除该相同的配置策略内容之外的其他的配置策略内容分别处理，以最终实现各个需求申请所需的网络配置。

通过本公开实施例，可以将应用用户的需求申请和运维人员的审核工作通过同一服务系统实现，并通过该服务系统可无需考虑应用用户和运维人员之间的网络知识的差异；同时，应用用户和运维人员所获取的网络配置信息均来自该服务系统存储的网络配置信息，在服务系统实现资源有效共享的同时，也提升了网络配置时的变更效率和正确性。

图5示意性示出了根据本公开实施例的响应配置查询功能的实现方式。

如图5所示，该方式包括：将第一网络配置变更请求和第一网络配置策略记录在数据库500中，以实现能够响应配置查询功能。

根据本公开的实施例，将应用用户的需求申请及相对应的网络配置策略以一一对应的关系存储在数据库中，基于数据库自带的或由程序设计的查询功能进行相应的配置查询。

通过本公开实施例，利用配置查询功能可直接且明确的得到各网络设备间的连接关系，进一步可通过直观显示的网络配置关系为应用用户在需求申请时提供便利，同时降低了对用户的网络知识的要求。

图6示意性示出了根据本公开实施例的应用用户端利用服务系统进行网络服务管理的方法的流程图。

如图6所示，在服务系统的应用用户端，该方法包括操作S610～S640。

在操作S610，应用用户选择需求申请的类型。

根据本公开的实施例，该需求申请的类型包括对现有网络配置的新增、修改或删除的需求申请。

在操作S620，应用用户选择需求申请类型为新增时，填写新增需求信息。

根据本公开的实施例，该新增需求信息包括需要新增的设备和/或网络配置信息。

在操作S621，服务系统通过数据库查询现有的网络配置信息，并与该新增需求信息进行比较。

在操作S622，如果该新增需求信息在现有的网络配置信息中已存在，则服务系统自动提示应用用户对于该新增需求信息“无需申请”。

在操作S623，如果该新增需求信息在现有的网络配置信息中不存在，则服务系统将应用用户的该新增需求信息自动提交申请。

在操作S630，应用用户选择需求申请类型为修改或删除时，服务系统查询现有的网络配置信息，和需要修改或删除的网络配置。

在操作S631，应用用户根据服务系统查询到现有的网络配置信息，选择需要修改的网络配置进行修改，得到修改需求信息。

在操作S632，服务系统将应用用户的该修改需求信息自动提交申请。

在操作S640，服务系统将操作S623中提交申请的新增需求信息和操作S632中提交申请的修改需求信息通过自动邮件或其他方式传送至运维人员进行审核。

需要说明的是，应用用户的需求申请在实施过程中，相关申请自动生成任务号进行保存，以防异常退出后填写内容丢失。

图7示意性示出了根据本公开实施例的运维人员端利用服务系统进行网络服务管理的方法的流程图。

如图7所示，在服务系统的运维人员端，该方法包括操作S710～S730。

在操作S710，运维人员查看需求申请信息。

根据本公开的实施例，运维人员查看的需求申请信息为操作S640中服务系统通过自动邮件或其他方式传送来应用用户的新增需求信息或修改需求信息。

在操作S720，运维人员对相关需求申请信息进行审核。

在操作S721，需求申请信息合理，运维人员判定审核通过，将该需求申请信息提交至服务系统，并由服务系统根据现有的网络配置信息，自动生成相应的网络配置策略，然后根据该网络配置策略自动变更现有的网络配置，以达到符合应用用户需求申请的网络配置需求。

在操作S722，需求申请信息不合理，运维人员判定审核不通过，直接将该需求申请信息退回服务系统。

在操作S730，根据操作S721和操作S722的操作内容，通过自动邮件或其他方式通知应用用户具体的审核结果。

需要说明的是，针对需求申请信息的审核不通过并退回后，应用用户可根据退回提示理由进行修改后直接取消。

根据本公开的实施例，服务系统中应用用户功能还包括针对需求申请提交后的进度查询功能，具体的，根据需求申请时生成的任务号查询申请进度，进度状态包括待提交、待审核、已审核、已完成、已取消。其中：待提交状态为需求申请未填写完成，仅该状态用户可进行修改相关需求申请；待审核状态为需求申请已提交，待运维人员进行审核；已审核状态为需求申请已审核通过并自动生成相关实施方案，待实施配置内容；已完成状态为针对需求申请的配置内容已实施；已取消状态为需求申请无需实施被取消。

根据本公开的实施例，服务系统中运维人员功能还包括通过运维人员自身实施的变更管理功能，具体的，其包括：由运维人员(而不是服务系统)管理查看变更配置方案及变更实施状态，以及如有特殊情况，运维人员可按序认为在线修改配置。其中的特殊情况包括但不限于存在服务系统未识别到的不同的应用用户间提出同样的需求申请，或同一应用用户两次提出相同的需求申请等情况。

图8意性示出了根据本公开的实施例的服务系统的框图。

如图8所示，服务系统800包括需求管理模块810、配置解析模块820、策略管理模块830、和配置修改模块840。

需求管理模块810，用于获取第一网络配置变更请求。

配置解析模块820，用于获取数据库中存储的网络配置信息。

策略管理模块830，用于根据第一网络配置变更请求和网络配置信息生成第一网络配置策略。

配置修改模块840，用于根据第一网络配置策略调整网络配置信息。

根据本公开的实施例，服务系统800还包括：审核模块850、合并模块860和记录模块870。

审核模块850，用于将第一网络配置变更请求提交审核并输出审核结果。

合并模块860，在获取第一网络配置变更请求之后，并在根据第一网络配置策略调整网络配置信息之前，获取第二网络配置变更请求，根据第二网络配置变更请求和网络配置信息生成第二网络配置策略；以及该合并模块860用于将第一网络配置策略和第二网络配置策略中相同的配置策略内容进行合并处理。

记录模块870，用于将第一网络配置变更请求和第一网络配置策略记录在数据库中，以实现能够响应配置查询功能。

根据本公开的实施例的模块中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，需求管理模块810、配置解析模块820、策略管理模块830、和配置修改模块840中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，需求管理模块810、配置解析模块820、策略管理模块830、和配置修改模块840中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，需求管理模块810、配置解析模块820、策略管理模块830、和配置修改模块840中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

需要说明的是，本公开的实施例中服务系统部分与本公开的实施例中利用服务系统进行网络服务管理的方法部分是相对应的，服务系统部分的描述具体参考利用服务系统进行网络服务管理的方法部分，在此不再赘述。

图9示意性示出了根据本公开实施例的适于实现利用服务系统进行网络服务管理的方法的计算机系统的框图。图9示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，根据本公开实施例的计算机系统900包括处理器901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。处理器901例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 903中，存储有系统900操作所需的各种程序和数据。处理器901、ROM 902以及RAM 903通过总线904彼此相连。处理器901通过执行ROM 902和/或RAM 903中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 902和RAM 903以外的一个或多个存储器中。处理器901也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统900还可以包括输入/输出(I/O)接口905，输入/输出(I/O)接口905也连接至总线904。系统900还可以包括连接至I/O接口905的以下部件中的一项或多项：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被处理器901执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 502和/或RAM 503和/或ROM 502和RAM 503以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (10)

1.一种利用服务系统进行网络服务管理的方法，包括：

获取第一网络配置变更请求；

获取数据库中存储的网络配置信息；

根据所述第一网络配置变更请求和所述网络配置信息生成第一网络配置策略；以及

根据所述第一网络配置策略调整所述网络配置信息。

2.根据权利要求1所述的方法，其中，所述网络配置信息包括与域名相关的配置信息和与负载均衡相关的配置信息中的至少之一。

3.根据权利要求1所述的方法，还包括，在根据所述第一网络配置变更请求和所述网络配置信息生成第一网络配置策略之前，

将所述第一网络配置变更请求提交审核；以及

在所述第一网络配置变更请求审核通过后，根据所述第一网络配置变更请求和所述网络配置信息生成所述第一网络配置策略。

4.根据权利要求3所述的方法，还包括：

在获取所述第一网络配置变更请求之后，并在根据所述第一网络配置策略调整所述网络配置信息之前，获取第二网络配置变更请求；

根据所述第二网络配置变更请求和所述网络配置信息生成第二网络配置策略；

将所述第一网络配置策略和所述第二网络配置策略中相同的配置策略内容进行合并处理，将所述第一网络配置策略和所述第二网络配置策略中不同的配置策略内容分别进行处理，以调整所述网络配置信息。

5.根据权利要求1所述的方法，还包括：

将所述第一网络配置变更请求和所述第一网络配置策略记录在所述数据库中，以实现能够响应配置查询功能。

6.一种服务系统，包括：

需求管理模块，用于获取第一网络配置变更请求；

配置解析模块，用于获取数据库中存储的网络配置信息；

策略管理模块，用于根据所述第一网络配置变更请求和所述网络配置信息生成第一网络配置策略；以及

配置修改模块，用于根据所述第一网络配置策略调整所述网络配置信息。

7.根据权利要求6所述的系统，还包括：

审核模块，用于将所述第一网络配置变更请求提交审核并输出审核结果。

8.根据权利要求6所述的系统，还包括，合并模块，

在获取所述第一网络配置变更请求之后，并在根据所述第一网络配置策略调整所述网络配置信息之前，获取第二网络配置变更请求，根据所述第二网络配置变更请求和所述网络配置信息生成第二网络配置策略；以及

所述合并模块用于将所述第一网络配置策略和所述第二网络配置策略中相同的配置策略内容进行合并处理。

9.一种计算机系统，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至5中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器实现权利要求1至5中任一项所述的方法。

Images