CN109542643A - 一种OpenStack系统中消息的恢复方法及装置 - Google Patents

Abstract

本发明实施例提供的一种OpenStack系统中消息的恢复方法及装置，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，通过监控已处理服务请求消息及待处理服务请求消息，确定恢复的第一目标待处理服务请求消息，从而得知OpenStack内部的各个功能模块是否处理服务请求消息出现错误。如果有功能模块处理待处理服务请求消息出现错误后，通知处理待处理服务请求消息出现错误的功能模块从OpenStack系统的预设的存储设备中获取待处理服务请求消息进行重试处理。该方案可以减少用户需要重试发送服务请求消息的操作，因此可以提升用户体验。

Description

一种OpenStack系统中消息的恢复方法及装置

技术领域

本发明涉及云计算技术领域，特别是涉及一种OpenStack系统中消息的恢复方法及装置。

背景技术

OpenStack开放堆栈是一个开源、实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack内部包含镜像服务Glance、计算管理服务Nova、接口服务Console、块存储服务Cinder、网络管理服务Neutron和认证服务Keystone多个功能模块，每个功能模块包含多个类型的消息队列。

Nova功能模块接收用户发送的服务请求消息，并按照服务请求消息的类型存储至与服务请求消息的类型相对应的消息队列中，Nova功能模块根据各个模块的功能，将消息队列中的服务请求消息发送给对应的功能模块。

其他功能模块接收服务请求消息进行处理，如果处理成功，会产生携带服务请求信息的结束标识的信息。如果功能模块处理服务请求消息发生错误，会产生处理失败信息并存储至该功能模块的模块日志中。

相关技术中，查询各个功能模块的模块日志中的失败处理信息，如果发现一个处理失败信息，以重启功能模块的方式来恢复与该处理失败消息对应的服务请求消息。具体的，将传输处理过该服务请求消息的所有功能模块进行重启，发送通知消息，以告知用户重新发送服务请求消息给对应Nova功能模块。

由于一个服务请求消息在传输处理过程中使用到了多个功能模块，各个功能模块传输处理的服务请求消息也较多。如果重启所有功能模块，会影响未出现错误处理的功能模块对其他服务请求消息的处理，而且重启之后需要用户重试发送所有重启的功能模块未处理完成的所有服务请求消息，因此用户体验较差。

发明内容

本发明实施例的目的在于提供一种OpenStack系统中消息的恢复方法及装置，以提升用户体验。具体技术方案如下：

第一方面，本实施例提供了一种OpenStack系统中消息的恢复方法，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，恢复方法，包括：

从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；第一功能模块为接收用户终端的待处理服务请求消息，并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，第二功能模块为：各个功能模块中除第一功能模块外的功能模块；

从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；已处理服务请求消息为：第二功能模块对从第一功能模块接收的待处理服务请求消息进行处理后生成的；

根据保存的待处理服务请求消息和获取的已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息；

向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，恢复处理通知消息用于指示第二功能模块从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息并进行处理；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息。

可选的，从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理待处理服务请求消息的步骤，包括：

从OpenStack系统中的第一功能模块包含的消息队列中获取待处理服务请求消息；

其中，待处理服务请求消息包括：待处理服务请求消息的开始标识；待处理服务请求消息的开始标识用于标识该待处理服务请求消息即将被处理；

从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息的步骤，包括：

从OpenStack系统中各个第二功能模块包含的固定队列中获取已处理服务请求消息；

其中，固定队列与第二功能模块一一对应；已处理服务请求消息包括：已处理服务请求消息的处理标识；处理标识包括：结束标识和非结束标识；已处理服务请求消息的结束标识用于标识已处理服务请求消息被成功处理。

可选的，根据待处理服务请求消息和已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息的步骤，包括：

将包含开始标识的待处理服务请求消息的功能、名称标识与包含结束标识的已处理服务请求消息的功能、名称标识进行分别对比；

在对比结果为包括开始标识的待处理服务请求消息中，确定与所有包括结束标识的已处理服务请求消息的功能均不相同，且与所有包括结束标识的已处理服务请求消息的名称标识均不相同的待处理服务请求消息，为需要恢复的第一目标待处理服务请求消息。

可选的，预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息，包括：

由预设的存储设备中的本地持久化队列，接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求；

其中，预设的存储设备中的本地持久化队列与第一功能模块包含的消息队列一一对应。

可选的，在从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息的步骤之后，还包括：

将与已处理服务请求消息匹配的待处理服务请求消息作为需要删除的第二目标待处理服务请求消息；

将本地持久化队列中的第二目标待处理服务请求消息删除。

可选的，在向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息的步骤之后，还包括：

记录第二功能模块从预设的存储设备的持久化队列获取各个待处理服务请求消息的获取次数；

判断各个待处理服务请求消息的获取次数是否超过次数阈值；

在待处理服务请求消息的获取次数超过次数阈值的情况下，生成报警信息。

第二方面，本实施例提供了另一种OpenStack系统中消息的恢复方法，应用于OpenStack系统中非接收用户终端的服务请求消息的第二功能模块，包括：

接收OpenStack系统中的监控服务器发送的恢复处理通知消息；其中，恢复处理通知消息用于指示第二功能模块获取并处理第一目标待处理服务请求消息；第一目标待处理服务请求消息为监控服务器根据监控服务器保存的待处理服务请求消息和监控服务器从第二功能模块中获取的已处理服务请求消息确定的；

根据恢复处理通知消息，从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息；预设的存储设备独立于OpenStack系统中的各个功能模块；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息；

对第一目标待处理服务请求消息进行处理。

可选的，根据恢复处理通知消息，从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息，包括：

根据恢复处理通知消息，从预设的存储设备的本地持久化队列中获取第一目标待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

第三方面，本实施例提供了一种OpenStack系统中消息的恢复装置，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，包括：

第一获取单元，用于从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；第一功能模块为接收用户终端的待处理服务请求消息，并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，第二功能模块为：各个功能模块中除第一功能模块外的功能模块；

第二获取单元，用于从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；已处理服务请求消息为：第二功能模块对从第一功能模块接收的待处理服务请求消息进行处理后生成的；

消息确定单元，用于根据保存的待处理服务请求消息和获取的已处理服务请求消息确定需要恢复的第一目标待处理服务请求消息；

消息通知单元，用于向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，恢复处理通知消息用于指示第二功能模块从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息并进行处理；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息。

第一获取单元具体用于：

从OpenStack系统中的第一功能模块包含的消息队列中获取待处理服务请求消息；

其中，待处理服务请求消息包括：待处理服务请求消息的开始标识；待处理服务请求消息的开始标识用于标识该待处理服务请求消息即将被处理；

第二获取单元具体用于：

从OpenStack系统中各个第二功能模块包含的固定队列中获取已处理服务请求消息；

其中，固定队列与第二功能模块一一对应；已处理服务请求消息包括：已处理服务请求消息的处理标识；处理标识包括：结束标识和非结束标识；已处理服务请求消息的结束标识用于标识已处理服务请求消息被成功处理。

可选的，消息确定单元具体用于：

将包含开始标识的待处理服务请求消息的功能、名称标识与包含结束标识的已处理服务请求消息的功能、名称标识进行分别对比；

在对比结果为包括开始标识的待处理服务请求消息中，确定与所有包括结束标识的已处理服务请求消息的功能均不相同，且与所有包括结束标识的已处理服务请求消息的名称标识均不相同的待处理服务请求消息，为需要恢复的第一目标待处理服务请求消息。

可选的，预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息，具体包括：

由预设的存储设备中的本地持久化队列，接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

可选的，本发明实施例第三方面提供的一种OpenStack系统中消息的恢复装置还包括：

消息删除单元，用于将与已处理服务请求消息匹配的待处理服务请求消息作为需要删除的第二目标待处理服务请求消息；

将本地持久化队列中的第二目标待处理服务请求消息删除。

可选的，消息通知单元包括：

输出报警子单元，用于记录第二功能模块从预设的存储设备的持久化队列获取各个待处理服务请求消息的获取次数；

判断各个待处理服务请求消息的获取次数是否超过次数阈值；

在待处理服务请求消息的获取次数超过次数阈值的情况下，生成报警信息。

第四方面，本实施例提供了另一种OpenStack系统中消息的恢复装置，特征在于，应用于OpenStack系统中非接收用户终端的服务请求消息的第二功能模块，包括：

消息接收单元，用于接收OpenStack系统中的监控服务器发送的恢复处理通知消息；其中，恢复处理通知消息用于指示第二功能模块获取并处理第一目标待处理服务请求消息；第一目标待处理服务请求消息为监控服务器根据监控服务器保存的待处理服务请求消息和监控服务器从第二功能模块中获取的已处理服务请求消息确定的；

消息保存单元，用于从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息；

消息处理单元，用于对第一目标待处理服务请求消息进行处理。

可选的，消息保存单元具体用于：

根据恢复处理通知消息，从预设的存储设备的本地持久化队列中获取第一目标待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

第五方面，本实施例提供了一种监控服务器，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

通信接口，用于与OpenStack系统中各个功能模块分别通信连接；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现任一所述的一种OpenStack系统中消息的恢复方法步骤。

第六方面，本实施例提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现任一所述的一种OpenStack系统中消息的恢复方法步骤。

本发明实施例提供的一种OpenStack系统中消息的恢复方法及装置，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，通过监控已处理服务请求消息及待处理服务请求消息，确定恢复的第一目标待处理服务请求消息，从而得知OpenStack内部的各个功能模块是否处理服务请求消息出现错误。如果有功能模块处理待处理服务请求消息出现错误后，通知处理待处理服务请求消息出现错误的功能模块从OpenStack系统的预设的存储设备中获取待处理服务请求消息进行重试处理。本发明实施例中，通过在OpenStack系统中功能模块处理服务请求消息出现错误时，从预设的存储设备中获取待处理服务请求消息进行重试处理来实现服务请求消息的恢复，这种恢复方式无需重启功能模块，可以减少用户需要重试发送服务请求消息的操作，因此可以提升用户体验。当然，实施本发明的任一产品或方法并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例的一种OpenStack系统中消息的恢复方法的流程图；

图2为图1所示实施例中步骤S102的一种具体流程图；

图3为本发明实施例的一种确定第一目标待处理服务请求消息的流程图；

图4为本发明实施例中删除本地持久化队列中待处理服务请求消息的流程图；

图5为本发明实施例中监控服务器生成报警信息的流程图；

图6为本发明实施例另一种OpenStack系统中消息的恢复方法的流程图；

图7为本发明实施例的一种OpenStack系统中消息的恢复装置的结构图；

图8为本发明实施例的另一种OpenStack系统中消息的恢复装置的结构图；

图9为本发明实施例的一种监控服务器的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例为了解决现有技术通过查询到的各个模块的模块日志中的失败处理的信息，将传输处理过该服务请求消息的所有功能模块进行重启，导致重启之后，需要用户重试发送所有重启的功能模块未处理完成的所有服务请求消息，造成用户体验差的问题。可以理解的是，用户发送的服务请求消息在用户终端创建时就会有服务请求消息标识，如果一个功能模块处理服务请求消息处理成功，服务请求消息标识会变化。本发明实施例监控服务器根据服务请求消息标识，可以找出未处理完成的服务请求消息。给负责未处理完成的服务请求消息的功能模块，发送恢复处理通知消息，使得该功能模块从预设的存储设备中获取未处理完成的服务请求消息进行处理，减少了用户重试发送出现错误处理的服务请求消息。实施本发明的任一产品或方法并不一定需要同时达到以上所述的所有优点。

如图1所示，本发明实施例所提供的一种OpenStack系统中消息的恢复方法，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，包括如下步骤：

S101，从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；所述第一功能模块为接收用户终端的待处理服务请求消息，并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，所述第二功能模块为：所述各个功能模块中除所述第一功能模块外的功能模块；

其中，第一功能模块可以是OpenStack系统中用于接收用户终端的待处理服务请求消息的Nova功能模块。Nova功能模块还为虚拟服务器提供自动创建和管理，负责管理所有的资源、网络、认证以及扩展。第二功能模块可以是OpenStack系统中除Nova功能模块以外的其他功能模块，例如：Glance、Console、Cinder、Neutron及Keystone等。

S102，从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；已处理服务请求消息为：第二功能模块对从第一功能模块接收的待处理服务请求消息进行处理后生成的；

S103，根据保存的待处理服务请求消息和获取的已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息；

S104，向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，恢复处理通知消息用于指示第二功能模块从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息并进行处理；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息。

参考图2，本实施例中的存储设备是预先设置在OpenStack系统中的存储区域，该存储区域独立于在OpenStack系统中各个功能模块。存储设备主要用于对用户发送的服务请求消息做备份，以便第二功能模块获取服务请求消息。

本发明实施例通过监控服务器获得OpenStack系统中的第二功能模块中已处理的服务请求消息与服务器监控服务器保存的待处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息，发送恢复处理通知消息，使得第二功能模块从预设的存储设备中获取第一目标待处理服务请求消息进行处理。可以理解的是，需要恢复的待处理服务请求消息是从本地预设的存储设备中获取的，不需要发送通知消息让用户重试发送需要恢复的待处理服务请求消息，因此，可以提升用户体验。

可选的，S101可以通过如下步骤获得：

从OpenStack系统中的第一功能模块包含的消息队列中获取待处理服务请求消息；

其中，待处理服务请求消息包括：待处理服务请求消息的开始标识；待处理服务请求消息的开始标识用于标识该待处理服务请求消息即将被处理；

可以理解的是，本实施例中的第一功能模块包含多个消息队列，各个消息队列的类型不同。消息队列主要是存放用户终端发来的待处理服务请求消息。第一功能模块会将待处理服务请求消息存放至与待处理服务请求消息的类型相对应的消息队列。

可选的，S102可以通过如下步骤获得：

从OpenStack系统中各个第二功能模块包含的固定队列中获取已处理服务请求消息；

其中，固定队列与第二功能模块一一对应；已处理服务请求消息包括：已处理服务请求消息的处理标识；处理标识包括：结束标识和非结束标识；已处理服务请求消息的结束标识用于标识已处理服务请求消息被成功处理。

OpenStack系统构架如图2所示，其中，NOVA即第一功能模块；Glance、Console、Cinder、Neutron及Keystone等功能模块都是第二功能模块。

其中，NOVA功能模块包括多个消息队列A～H，这些消息队列预设被设置与不同的第二功能模块对应。例如：消息队列A和消息队列B与Glance功能模块对应；消息队列C与Console功能模块对应；消息队列D和消息队列E与Cinder功能模块对应；消息队列F和消息队列G与Neutron功能模块对应；消息队列H与Keystone功能模块对应。

NOVA功能模块接收用户发送的待处理服务请求消息，根据该待处理请求消息包含的第二功能模块标识，为其添加服务请求消息的开始标识后，保存至消息队列A～H中，以及存储设备中与消息队列A～H对应的持久化队列A～H。并将该待处理服务请求消息发送至与该待处理服务请求消息包含的第二功能模块标识对应的第二功能模块。

每个第二功能模块，包含固定队列和与NOVA消息队列A～H对应的消息队列。如图2所示，Glance模块包含固定队列1；Console功能模块包含固定队列2；Cinder功能模块包含固定队列3；Neutron功能模块包含固定队列4；Keystone功能模块包含固定队列5。

每个第二功能模块，收到第一功能模块的消息队列中包含开始标识的待处理服务请求消息，存储至自身的消息队列中。从自身的各个消息队列中读取包含开始标识的待处理服务请求消息，进行处理；假设第二功能模块故障，则该待处理服务请求消息就不会携带处理标识出现在固定队列中；假设第二功能模块处理该待处理服务请求消息未成功，但该待处理服务请求消息携带有非结束标识，则第二功能模块处理该待处理服务请求消息出现错误，需要重新处理。第二功能模块会将处理成功后的待处理服务请求消息加上结束标识保存至固定队列中。

本实施例中的固定队列是预先建立在各个第二功能模块之中，用于存储已处理的服务请求消息，为查找出未被成功处理的待处理服务请求消息做铺垫。每个第二功能模块只有一个固定队列，各个固定队列类型与第二功能模块的功能一一相关。例如：Glance、Console、Cinder、Neutron及Keystone功能模块中的固定队列标识可以分别是1、2、3、4、5。

可选的，如图3所示，S103具体可以包括如下步骤：

S301，将包含开始标识的待处理服务请求消息的功能、名称标识与包含结束标识的已处理服务请求消息的功能、名称标识进行分别对比；

S302，在对比结果为包括开始标识的待处理服务请求消息中，确定与所有包括结束标识的已处理服务请求消息的功能均不相同，且与所有包括结束标识的已处理服务请求消息的名称标识均不相同的待处理服务请求消息，为需要恢复的第一目标待处理服务请求消息。

本实施例为了找出未被第二功能模块成功处理的待处理服务请求消息。如果第二功能模块处理一待处理服务请求消息成功后，该服务请求消息会携带结束标识。不同服务请求消息的功能和名称是不同的，例如，用户发送的创建服务消息，第二功能模块接收该创建服务消息为：创建.start；用户发送的查找服务消息，第二功能模块接收该查找服务消息为：查找.start；如果第二功能模块处理创建.start成功后，该查找服务消息为：创建.end；如果创建.start未被成功处理，该创建.start的服务请求消息不会携带end结束标识；如果第二功能模块故障，则固定队列中不存在该创建服务请求消息。如果第二功能模块处理创建.start未成功，在固定队列中存储的该服务请求消息可能为：创建.error。

因此，本实施例可以通过所有已处理服务请求消息的功能及名称标识与待处理服务请求消息的功能及名称标识是否相同，确定出未被成功处理的待处理服务请求消息。

可选的，步骤S104中OpenStack系统的预设的存储设备接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息包括：

由预设的存储设备中的本地持久化队列接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

本实施例为了将第一功能模块接收到的待处理服务请求消息做备份，方便为后续第二功能模块接收恢复通知后，从存储设备中取出未成功处理的待处理服务请求消息重新处理。本实施例在存储设备创建本地持久化队列的方法与现有技术创建持久化队列方法相同，都是由开发人员通过将消息队列设置可持久标志，然后将交换机设置为可持久；将通道设置为可持久；服务请求消息发送时将服务请求消息设置可持久，在此不做赘述。

可以理解的是，本实施例中的本地持久化队列与第一功能模块包含的消息队列的类型相同。例如：如果第一功能模块包含消息队列A、B，那么存储设备中包含本地持久化队列A、B。本地持久化队列中的待处理服务请求消息，不会因为第二功能模块重启造成待处理服务请求消息的丢失，为保存所有待处理服务请求消息提供可靠的保证。

可选的，本发明实施例中从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息的步骤之后，可以删除本地持久化队列中待处理服务请求消息，具体的流程图如图4所示，包括：

S401：将与已处理服务请求消息匹配的待处理服务请求消息作为需要删除的第二目标待处理服务请求消息；

其中，如果包含开始标识的待处理服务请求消息与所有包括结束标识的已处理服务请求消息的功能及名称标识均不相同，则待处理服务请求消息与已处理服务请求消息不匹配。

S402：将存储设备的本地持久化队列中的第二目标待处理服务请求消息删除。

可以理解的是，由于存储设备的本地持久化队列存储所有的待处理服务请求消息，随着时间的推移，本地持久化队列中存储的待处理服务请求消息会逐渐增多。本实施例中获取已处理服务请求消息匹配的待处理服务请求消息目的是，为了将成功处理的待处理服务请求消息从本地持久化队列中删除，减轻本地持久化队列存储的负担。为方便第二功能模块在接收到恢复通知后，获取需要恢复的待处理服务请求消息，提高效率。

可选的，本发明实施例中在向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息的步骤之后，可以输出监控服务器报警信息，具体的流程图如图5所示，包括：

S501，记录第二功能模块从预设的存储设备的持久化队列获取各个待处理服务请求消息的获取次数；

S502，判断各个待处理服务请求消息的获取次数是否超过次数阈值；

其中，次数阈值是开发人员根据经验预先设置的，通常是3。

可以理解的是，开发人员根据经验预先设置次数阈值，可以准确找出获取次数超过次数阈值的待处理服务请求消息，以便后续开发人员决定是否重启第二功能模块提供参考。

S503，在待处理服务请求消息的获取次数超过次数阈值的情况下，生成报警信息。

可以理解的是，如果一个待处理服务请求消息的获取多次，可以得出处理该待处理服务请求消息的第二功能模块必然发生了错误，需要对该第二功能模块进行重启，使得该功能模块可以正常处理待处理服务请求消息。

本实施例生成报警信息的目的是：为开发人员提供参考，开发人员可以根据监控服务器输出报警信息得知，具体那个第二功能模块处理待处理服务请求消息发生错误，使得开发人员有针对性的重启该第二功能模块，以避免重启其他第二功能模块，影响其他第二功能模块正常运行。

如图6所示，本发明实施例所提供的另一种OpenStack系统中消息的恢复方法，应用于OpenStack系统中非接收用户终端的服务请求消息的第二功能模块，包括如下步骤：

可以理解的是，第一功能模块接收用户发送的待处理服务请求消息后，会将待处理服务请求消息发给第二功能模块。第二功能模块处理待处理服务请求消息成功后，会生成与待处理服务请求消息类型及名称相同的服务请求消息。如果第二功能模块处理待处理服务请求消息发生错误，监控服务器会向第二功能模块发送恢复处理通知消息，让第二功能模块重新处理该待处理服务请求消息。

S601，接收OpenStack系统中的监控服务器发送的恢复处理通知消息；其中，恢复处理通知消息用于指示第二功能模块获取并处理第一目标待处理服务请求消息；目标待处理服务请求消息为监控服务器根据监控服务器保存的待处理服务请求消息和监控服务器从第二功能模块中获取的已处理服务请求消息确定的；

S602，根据恢复处理通知消息，从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息；

S603，对第一目标待处理服务请求消息进行处理。

本发明实施例中的第二功能模块通过接收监控服务器发送恢复处理通知消息，从预设的存储设备中获取出现错误处理的待处理服务请求消息重新进行处理。可以理解的是，需要恢复的待处理服务请求消息是从本地预设的存储设备中获取的，不需要发送通知消息让用户重试发送需要恢复的待处理服务请求消息，因此，可以提升用户体验。

可选的，S602根据恢复处理通知消息，从OpenStack系统的预设的存储设备中获取目标待处理服务请求消息，包括：

根据恢复处理通知消息，从预设的存储设备的本地持久化队列中获取第一目标待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

其中，恢复处理通知消息可以包含需要恢复的待处理服务请求消息的类型及名称标识。因此，第二功能模块可以快速的在预设的存储设备的本地持久化队列中获取待处理服务请求消息进行处理。因此，提高了恢复待处理服务请求消息重新处理的效率。

相应于上述方法实施例，本发明实施例提供了一种OpenStack系统中消息的恢复装置，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，如图7所示，包括：

第一获取单元701，用于从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；第一功能模块为接收用户终端的待处理服务请求消息，并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，第二功能模块为：各个功能模块中除第一功能模块外的功能模块；

其中，第一功能模块可以是OpenStack系统中用于接收用户终端的待处理服务请求消息的Nova功能模块。Nova功能模块还为虚拟服务器提供自动创建和管理，负责管理所有的资源、网络、认证以及扩展。第二功能模块可以是OpenStack系统中除Nova功能模块以外的其他功能模块，例如：Glance、Console、Cinder、Neutron及Keystone等。

第二获取单元702，用于从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；已处理服务请求消息为：第二功能模块对从第一功能模块接收的待处理服务请求消息进行处理后生成的；

消息确定单元703，用于根据保存的待处理服务请求消息和获取的已处理服务请求消息确定需要恢复的第一目标待处理服务请求消息；

消息通知单元704，用于向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，恢复处理通知消息用于指示第二功能模块从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息并进行处理；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息。

本发明实施例通过监控服务器中的装置获得OpenStack系统中的第二功能模块中已处理的服务请求消息与服务器监控服务器保存的待处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息，发送恢复处理通知消息，使得第二功能模块从预设的存储设备中获取第一目标待处理服务请求消息进行处理。可以理解的是，需要恢复的待处理服务请求消息是从本地预设的存储设备中获取的，不需要发送通知消息让用户重试发送需要恢复的待处理服务请求消息，因此，可以提升用户体验。

第一获取单元具体用于：

从OpenStack系统中的第一功能模块包含的消息队列中获取待处理服务请求消息；

其中，待处理服务请求消息包括：待处理服务请求消息的开始标识；待处理服务请求消息的开始标识用于标识该待处理服务请求消息即将被处理；

可以理解的是，本实施例中的第一功能模块包含多个消息队列，各个消息队列的类型不同。消息队列主要是存放用户终端发来的待处理服务请求消息。第一功能模块会将待处理服务请求消息存放至与待处理服务请求消息的类型相对应的消息队列。

第二获取单元具体用于：

从OpenStack系统中各个第二功能模块包含的固定队列中获取已处理服务请求消息；

其中，固定队列与第二功能模块一一对应；已处理服务请求消息包括：已处理服务请求消息的处理标识；处理标识包括：结束标识和非结束标识；已处理服务请求消息的结束标识用于标识已处理服务请求消息被成功处理。

OpenStack系统构架如图2所示，其中，NOVA即第一功能模块；Glance、Console、Cinder、Neutron及Keystone等功能模块都是第二功能模块。

其中，NOVA功能模块包括多个消息队列A～H，这些消息队列预设被设置与不同的第二功能模块对应。例如：消息队列A和消息队列B与Glance功能模块对应；消息队列C与Console功能模块对应；消息队列D和消息队列E与Cinder功能模块对应；消息队列F和消息队列G与Neutron功能模块对应；消息队列H与Keystone功能模块对应。

NOVA功能模块接收用户发送的待处理服务请求消息，根据该待处理请求消息包含的第二功能模块标识，为其添加服务请求消息的开始标识后，保存至消息队列A～H中，以及存储设备中与消息队列A～H对应的持久化队列A～H。并将该待处理服务请求消息发送至与该待处理服务请求消息包含的第二功能模块标识对应的第二功能模块。

每个第二功能模块，包含固定队列和与NOVA消息队列A～H对应的消息队列。如图2所示，Glance模块包含固定队列1；Console功能模块包含固定队列2；Cinder功能模块包含固定队列3；Neutron功能模块包含固定队列4；Keystone功能模块包含固定队列5。

每个第二功能模块，收到第一功能模块的消息队列中包含开始标识的待处理服务请求消息，存储至自身的消息队列中。从自身的各个消息队列中读取包含开始标识的待处理服务请求消息，进行处理；假设第二功能模块故障，则该待处理服务请求消息就不会携带处理标识出现在固定队列中；假设第二功能模块处理该待处理服务请求消息未成功，但该待处理服务请求消息携带有非结束标识，则第二功能模块处理该待处理服务请求消息出现错误，需要重新处理。第二功能模块会将处理成功后的待处理服务请求消息加上结束标识保存至固定队列中。

本实施例中的固定队列是预先建立在各个第二功能模块之中，用于存储已处理的服务请求消息，为查找出未被成功处理的待处理服务请求消息做铺垫。每个第二功能模块只有一个固定队列，各个固定队列类型与第二功能模块的功能一一相关。例如：Glance、Console、Cinder、Neutron及Keystone功能模块中的固定队列标识可以分别是1、2、3、4、5。

可选的，消息确定单元具体用于：

将包含开始标识的待处理服务请求消息的功能、名称标识与包含结束标识的已处理服务请求消息的功能、名称标识进行分别对比；

在对比结果为包括开始标识的待处理服务请求消息中，确定与所有包括结束标识的已处理服务请求消息的功能均不相同，且与所有包括结束标识的已处理服务请求消息的名称标识均不相同的待处理服务请求消息，为需要恢复的第一目标待处理服务请求消息。

本实施例为了找出未被第二功能模块成功处理的待处理服务请求消息。如果第二功能模块处理一待处理服务请求消息成功后，该服务请求消息会携带结束标识。不同服务请求消息的功能和名称是不同的，例如，用户发送的创建服务消息，第二功能模块接收该创建服务消息为：创建.start；用户发送的查找服务消息，第二功能模块接收该查找服务消息为：查找.start；如果第二功能模块处理创建.start成功后，该查找服务消息为：创建.end；如果创建.start未被成功处理，该创建.start的服务请求消息不会携带end结束标识；如果第二功能模块故障，则固定队列中不存在该创建服务请求消息。如果第二功能模块处理创建.start未成功，在固定队列中存储的该服务请求消息可能为：创建.error。

因此，本实施例可以通过所有已处理服务请求消息的功能及名称标识与待处理服务请求消息的功能及名称标识是否相同，确定出未被成功处理的待处理服务请求消息。

可选的，预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息，具体包括：

由预设的存储设备中的本地持久化队列，接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

本实施例为了将第一功能模块接收到的待处理服务请求消息做备份，方便为后续第二功能模块接收恢复通知后，从存储设备中取出未成功处理的待处理服务请求消息重新处理。本实施例在存储设备创建本地持久化队列的方法与现有技术创建持久化队列方法相同，都是由开发人员通过将消息队列设置可持久标志，然后将交换机设置为可持久；将通道设置为可持久；服务请求消息发送时将服务请求消息设置可持久，在此不做赘述。

可以理解的是，本实施例中的本地持久化队列与第一功能模块包含的消息队列的类型相同。例如：如果第一功能模块包含消息队列A、B，那么存储设备中包含本地持久化队列A、B。本地持久化队列中的待处理服务请求消息，不会因为第二功能模块重启造成待处理服务请求消息的丢失，为保存所有待处理服务请求消息提供可靠的保证。

可选的，本发明实施例第三方面提供的一种OpenStack系统中消息的恢复装置还包括：

消息删除单元，用于将与已处理服务请求消息匹配的待处理服务请求消息作为需要删除的第二目标待处理服务请求消息；

其中，如果包含开始标识的待处理服务请求消息与所有包括结束标识的已处理服务请求消息的功能及名称标识均不相同，则待处理服务请求消息与已处理服务请求消息不匹配。

将本地持久化队列中的第二目标待处理服务请求消息删除。

可选的，消息通知单元包括：

输出报警子单元，用于记录第二功能模块从预设的存储设备的持久化队列获取各个待处理服务请求消息的获取次数；

判断各个待处理服务请求消息的获取次数是否超过次数阈值；

在待处理服务请求消息的获取次数超过次数阈值的情况下，生成报警信息。

可以理解的是，如果一个待处理服务请求消息的获取多次，可以得出处理该待处理服务请求消息的第二功能模块必然发生了错误，需要对该第二功能模块进行重启，使得该功能模块可以正常处理待处理服务请求消息。

本实施例生成报警信息的目的是：为开发人员提供参考，开发人员可以根据监控服务器输出报警信息得知，具体那个第二功能模块处理待处理服务请求消息发生错误，使得开发人员有针对性的重启该第二功能模块，以避免重启其他第二功能模块，影响其他第二功能模块正常运行。

第四方面，本实施例提供了另一种OpenStack系统中消息的恢复装置，特征在于，应用于OpenStack系统中非接收用户终端的服务请求消息的第二功能模块，包括：

可以理解的是，第一功能模块接收用户发送的待处理服务请求消息后，会将待处理服务请求消息发给第二功能模块。第二功能模块处理待处理服务请求消息成功后，会生成与待处理服务请求消息类型及名称相同的服务请求消息。如果第二功能模块处理待处理服务请求消息发生错误，监控服务器会向第二功能模块发送恢复处理通知消息，让第二功能模块重新处理该待处理服务请求消息。

消息接收单元801，用于接收OpenStack系统中的监控服务器发送的恢复处理通知消息；其中，恢复处理通知消息用于指示第二功能模块获取并处理第一目标待处理服务请求消息；第一目标待处理服务请求消息为监控服务器根据监控服务器保存的待处理服务请求消息和监控服务器从第二功能模块中获取的已处理服务请求消息确定的；

消息保存单元802，用于从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息；

消息处理单元803，用于对第一目标待处理服务请求消息进行处理。

本发明实施例中的第二功能模块通过接收监控服务器发送恢复处理通知消息，从预设的存储设备中获取出现错误处理的待处理服务请求消息重新进行处理。可以理解的是，需要恢复的待处理服务请求消息是从本地预设的存储设备中获取的，不需要发送通知消息让用户重试发送需要恢复的待处理服务请求消息，因此，可以提升用户体验。

可选的，消息保存单元具体用于：

根据恢复处理通知消息，从预设的存储设备的本地持久化队列中获取第一目标待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

其中，恢复处理通知消息可以包含需要恢复的待处理服务请求消息的类型及名称标识。因此，第二功能模块可以快速的在预设的存储设备的本地持久化队列中获取待处理服务请求消息进行处理。因此，提高了恢复待处理服务请求消息重新处理的效率。

本发明实施例还提供了一种监控服务器，如图9所示，包括处理器901、通信接口902、存储器903和通信总线904，其中，处理器901，通信接口902，存储器903通过通信总线904完成相互间的通信，

存储器903，用于存放计算机程序；

处理器901，用于执行存储器903上所存放的程序时，实现如下步骤：

从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；第一功能模块为接收用户终端的待处理服务请求消息，并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，第二功能模块为：各个功能模块中除第一功能模块外的功能模块；

从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；已处理服务请求消息为：第二功能模块对从第一功能模块接收的待处理服务请求消息进行处理后生成的；

根据保存的待处理服务请求消息和获取的已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息；

向与第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，恢复处理通知消息用于指示第二功能模块从OpenStack系统的预设的存储设备中获取第一目标待处理服务请求消息并进行处理；预设的存储设备用于接收并保存第一功能模块发送至各个第二功能模块的待处理服务请求消息。

本发明实施例提供的一种OpenStack系统中消息的恢复的监控服务器，通过监控已处理服务请求消息及待处理服务请求消息，确定恢复的第一目标待处理服务请求消息，从而得知OpenStack内部的各个功能模块是否处理服务请求消息出现错误。如果有功能模块处理待处理服务请求消息出现错误后，通知处理待处理服务请求消息出现错误的功能模块从OpenStack系统的预设的存储设备中获取待处理服务请求消息进行重试处理。本发明实施例中，通过在OpenStack系统中功能模块处理服务请求消息出现错误时，从预设的存储设备中获取待处理服务请求消息进行重试处理来实现服务请求消息的恢复，这种恢复方式无需重启功能模块，可以减少用户需要重试发送服务请求消息的操作，因此可以提升用户体验。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，通过监控已处理服务请求消息及待处理服务请求消息，确定恢复的第一目标待处理服务请求消息，从而得知OpenStack内部的各个功能模块是否处理服务请求消息出现错误。如果有功能模块处理待处理服务请求消息出现错误后，通知处理待处理服务请求消息出现错误的功能模块从OpenStack系统的预设的存储设备中获取待处理服务请求消息进行重试处理。本发明实施例中，通过在OpenStack系统中功能模块处理服务请求消息出现错误时，从预设的存储设备中获取待处理服务请求消息进行重试处理来实现服务请求消息的恢复，这种恢复方式无需重启功能模块，可以减少用户需要重试发送服务请求消息的操作，因此可以提升用户体验。

在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，通过监控已处理服务请求消息及待处理服务请求消息，确定恢复的第一目标待处理服务请求消息，从而得知OpenStack内部的各个功能模块是否处理服务请求消息出现错误。如果有功能模块处理待处理服务请求消息出现错误后，通知处理待处理服务请求消息出现错误的功能模块从OpenStack系统的预设的存储设备中获取待处理服务请求消息进行重试处理。本发明实施例中，通过在OpenStack系统中功能模块处理服务请求消息出现错误时，从预设的存储设备中获取待处理服务请求消息进行重试处理来实现服务请求消息的恢复，这种恢复方式无需重启功能模块，可以减少用户需要重试发送服务请求消息的操作，因此可以提升用户体验。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

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

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置/监控服务器/计算机可读存储介质/计算机程序产品实施例/计算机程序实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (18)

1.一种OpenStack系统中消息的恢复方法，其特征在于，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，包括：

从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；所述第一功能模块为接收用户终端的待处理服务请求消息，并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，所述第二功能模块为：所述各个功能模块中除所述第一功能模块外的功能模块；

从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；所述已处理服务请求消息为：所述第二功能模块对从所述第一功能模块接收的待处理服务请求消息进行处理后生成的；

根据保存的所述待处理服务请求消息和获取的所述已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息；

向与所述第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，所述恢复处理通知消息用于指示所述第二功能模块从OpenStack系统的预设的存储设备中获取所述第一目标待处理服务请求消息并进行处理；所述预设的存储设备用于接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求消息。

2.根据权利要求1所述的方法，其特征在于，

所述从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息的步骤，包括：

从OpenStack系统中的第一功能模块包含的消息队列中获取待处理服务请求消息；

其中，所述待处理服务请求消息包括：待处理服务请求消息的开始标识；所述待处理服务请求消息的开始标识用于标识该待处理服务请求消息即将被处理；

所述从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息的步骤，包括：

从OpenStack系统中各个第二功能模块包含的固定队列中获取已处理服务请求消息；

其中，所述固定队列与所述第二功能模块一一对应；所述已处理服务请求消息包括：已处理服务请求消息的处理标识；所述处理标识包括：结束标识和非结束标识；所述已处理服务请求消息的结束标识用于标识已处理服务请求消息被成功处理。

3.根据权利要求2所述的方法，其特征在于，

所述根据所述待处理服务请求消息和所述已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息的步骤，包括：

将包含所述开始标识的所述待处理服务请求消息的功能、名称标识与包含所述结束标识的已处理服务请求消息的功能、名称标识进行分别对比；

在对比结果为包括所述开始标识的待处理服务请求消息中，确定与所有包括所述结束标识的已处理服务请求消息的功能均不相同，且与所有包括所述结束标识的已处理服务请求消息的名称标识均不相同的待处理服务请求消息，为需要恢复的第一目标待处理服务请求消息。

4.根据权利要求2所述的方法，其特征在于，所述预设的存储设备用于接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求消息，包括：

由所述预设的存储设备中的本地持久化队列，接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求；

其中，预设的存储设备中的本地持久化队列与所述第一功能模块包含的消息队列一一对应。

5.根据权利要求4所述的方法，其特征在于，在从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息的步骤之后，还包括：

将与已处理服务请求消息匹配的待处理服务请求消息作为需要删除的第二目标待处理服务请求消息；

将所述本地持久化队列中的所述第二目标待处理服务请求消息删除。

6.根据权利要求4所述的方法，其特征在于，在向与所述第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息的步骤之后，还包括：

记录所述第二功能模块从预设的存储设备的持久化队列获取所述待处理服务请求消息的获取次数；

判断所述待处理服务请求消息的获取次数是否超过次数阈值；

在所述待处理服务请求消息的获取次数超过次数阈值的情况下，生成报警信息。

7.一种OpenStack系统中消息的恢复方法，特征在于，应用于OpenStack系统中非接收用户终端的服务请求消息的第二功能模块，所述恢复方法，包括：

接收所述OpenStack系统中的监控服务器发送的恢复处理通知消息；其中，所述恢复处理通知消息用于指示所述第二功能模块获取并处理第一目标待处理服务请求消息；所述目标待处理服务请求消息为所述监控服务器根据所述监控服务器保存的待处理服务请求消息和所述监控服务器从所述第二功能模块中获取的已处理服务请求消息确定的；

根据恢复处理通知消息，从所述OpenStack系统的预设的存储设备中获取所述第一目标待处理服务请求消息；所述预设的存储设备用于接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求消息；

对所述第一目标待处理服务请求消息进行处理。

8.根据权利要求7所述的方法，其特征在于，所述根据恢复处理通知消息，从所述OpenStack系统的预设的存储设备中获取所述第一目标待处理服务请求消息，包括：

根据所述恢复处理通知消息，从预设的存储设备的本地持久化队列中获取所述第一目标待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

9.一种OpenStack系统中消息的恢复装置，其特征在于，应用于与OpenStack系统中各个功能模块分别通信连接的监控服务器，所述装置包括：

第一获取单元，用于从OpenStack系统中的第一功能模块中，获取并保存用户终端的待处理服务请求消息；所述第一功能模块为接收用户终端的待处理服务请求消息并将接收到的待处理服务请求消息发送给各个第二功能模块的功能模块；其中，所述第二功能模块为：所述各个功能模块中除所述第一功能模块外的功能模块；

第二获取单元，用于从OpenStack系统中的各个第二功能模块中，获取已处理服务请求消息；所述已处理服务请求消息为：所述第二功能模块对从所述第一功能模块接收的待处理服务请求消息进行处理后生成的；

消息确定单元，用于根据保存的所述待处理服务请求消息和获取的所述已处理服务请求消息，确定需要恢复的第一目标待处理服务请求消息；

消息通知单元，用于向与所述第一目标待处理服务请求消息对应的第二功能模块发送恢复处理通知消息，其中，所述恢复处理通知消息用于指示所述第二功能模块从OpenStack系统的预设的存储设备中获取所述第一目标待处理服务请求消息并进行处理；所述预设的存储设备用于接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求消息。

10.根据权利要求9所述的装置，其特征在于，

所述第一获取单元具体用于：

从OpenStack系统中的第一功能模块包含的消息队列中获取待处理服务请求消息；

其中，所述待处理服务请求消息包括：待处理服务请求消息的开始标识；所述待处理服务请求消息的开始标识用于标识该待处理服务请求消息即将被处理；

所述第二获取单元具体用于：

从OpenStack系统中各个第二功能模块包含的固定队列中获取已处理服务请求消息；

其中，所述固定队列与所述第二功能模块一一对应；所述已处理服务请求消息包括：所述已处理服务请求消息包括：已处理服务请求消息的处理标识；所述处理标识包括：结束标识和非结束标识；所述已处理服务请求消息的结束标识用于标识已处理服务请求消息被成功处理。

11.根据权利要求10所述的装置，其特征在于，所述消息确定单元具体用于：

将包含所述开始标识的所述待处理服务请求消息的功能、名称标识与包含所述结束标识的已处理服务请求消息的功能、名称标识进行分别对比；

在对比结果为包括所述开始标识的待处理服务请求消息中，确定与所有包括所述结束标识的已处理服务请求消息的功能均不相同，且与所有包括所述结束标识的已处理服务请求消息的名称标识均不相同的待处理服务请求消息，为需要恢复的第一目标待处理服务请求消息。

12.根据权利要求10所述的装置，其特征在于，所述预设的存储设备用于接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求消息，具体包括：

由所述预设的存储设备中的本地持久化队列，接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求；

其中，预设的存储设备的本地持久化队列与所述第一功能模块包含的消息队列一一对应。

13.根据权利要求12所述的装置，其特征在于，所述装置还包括：

消息删除单元，用于将与已处理服务请求消息匹配的待处理服务请求消息作为需要删除的第二目标待处理服务请求消息；

将所述本地持久化队列中的所述第二目标待处理服务请求消息删除。

14.根据权利要求12所述的装置，其特征在于，所述消息通知单元包括：

输出报警子单元，用于记录所述第二功能模块从预设的存储设备的持久化队列获取所述待处理服务请求消息的获取次数；

判断所述各个待处理服务请求消息的获取次数是否超过次数阈值；

在所述待处理服务请求消息的获取次数超过次数阈值的情况下，生成报警信息。

15.一种OpenStack系统中消息的恢复装置，特征在于，应用于OpenStack系统中非接收用户终端的服务请求消息的第二功能模块，所述装置包括：

消息接收单元，用于接收所述OpenStack系统中的监控服务器发送的恢复处理通知消息；其中，所述恢复处理通知消息用于指示所述第二功能模块获取并处理第一目标待处理服务请求消息；所述第一目标待处理服务请求消息为所述监控服务器根据所述监控服务器保存的待处理服务请求消息和所述监控服务器从所述第二功能模块中获取的已处理服务请求消息确定的；

消息保存单元，用于从所述OpenStack系统的预设的存储设备中获取所述第一目标待处理服务请求消息；所述预设的存储设备独立所述各个功能模块；所述预设的存储设备用于接收并保存所述第一功能模块发送至各个第二功能模块的待处理服务请求消息；

消息处理单元，用于对所述第一目标待处理服务请求消息进行处理。

16.根据权利要求15所述的装置，其特征在于，所述消息保存单元具体用于：

根据所述恢复处理通知消息，从预设的存储设备的本地持久化队列中获取所述第一目标待处理服务请求消息；

其中，预设的存储设备的本地持久化队列与第一功能模块包含的消息队列一一对应。

17.一种监控服务器，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

通信接口，用于与OpenStack系统中各个功能模块分别通信连接；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现权利要求1-8任一所述的方法步骤。

18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-8任一所述的方法步骤。