CN117097597A - 一种资源状态信息推送方法、系统、电子设备和存储介质 - Google Patents

Abstract

本申请提供了一种资源状态信息推送方法、系统、电子设备和存储介质，其中，OpenStack集群中虚拟资源的资源状态信息推送方法包括：根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知；在公有云平台的OpenStack Notifier服务中定义虚拟资源的最终消息事件类型；当OpenStack集群获取到公有云平台的资源请求时，生成资源请求对应的notification消息，使用OpenStackNotification机制将notification消息推送至消息通知对应的消息队列中；使用OpenStackNotifier服务从消息队列中提取notification消息，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息。本申请的技术方案能解决现有技术中随着公有云用户和资源请求数量的增加，反复调用后端OpenStack集群的查询接口，导致后端OpenStack集群的负载会急剧增加的问题。

Description

一种资源状态信息推送方法、系统、电子设备和存储介质

技术领域

本申请涉及云服务技术领域，尤其涉及一种资源状态信息推送方法、系统、电子设备和存储介质。

背景技术

随着大数据技术和人工智能技术的迅猛发展，企业的业务数据呈现海量增长，这就导致许多企业需要在云上部署和分析海量数据。为了降低主流公有云服务的使用成本，许多企业开始考虑建立自己的公有云，并尽量减少研发成本。这种情况下，开源的IAAS平台的项目OpenStack成为建立公有云服务的不错选择。

在建立公有云服务时，由于业务需求来源广泛且数量众多，企业可能需要在全国甚至全球范围部署数据中心，因此需要一个统一的平台来管理这些数据中心，并实现多个OpenStack集群的接入和管理。为实现上述目的，一种可行的公有云架构是将公有云平台作为用户操作界面，同时将多个OpenStack集群作为后端资源的承载体，并通过公有云平台管理各个OpenStack集群已创建的虚拟资源。如图1所示，在OpenStack集群中，虚拟资源(例如：虚拟机、硬盘、虚拟路由器和虚拟防火墙)的创建通常是异步进行的。当用户通过公有云平台向OpenStack集群请求资源时，OpenStack集群的接口服务会在OpenStack自身数据库中创建相应条目并立即返回给公有云平台；然后通过内部消息队列通知OpenStack管理服务创建实际资源。这个过程需要一段时间，在此期间内资源在OpenStack集群内部调度过程中对用户是不可见的，因此，若用户希望获取虚拟资源的实时状态以便进行后续操作或使用，那么公有云平台必须要清楚这些虚拟资源在OpenStack集群后端的行为状态，这就需要公有云平台和OpenStack集群进行资源状态联动。

为了实现公有云平台和OpenStack集群的资源状态联动，现有的公有云平台获取OpenStack集群中虚拟资源的迁移状态的主要方式为：公有云平台不断向OpenStack集群发起资源请求，以获得虚拟资源当前的状态信息，然后使用该状态信息更新本端数据库。

然而，这种联动方法存在一些问题：随着公有云用户和资源请求数量的增加，后端OpenStack集群需要反复调用查询接口，导致后端OpenStack集群的负载会急剧增加，这可能导致响应变慢、服务崩溃甚至整个OpenStack集群瘫痪，进而会出现数据的丢失等安全性问题，从而降低用户体验。

申请内容

本申请提供资源状态信息推送方法、系统、电子设备和存储介质，能够解决现有技术中随着公有云用户和资源请求数量的增加，后端OpenStack集群需要反复调用查询接口，导致后端OpenStack集群的负载会急剧增加，这可能导致响应变慢、服务崩溃甚至整个OpenStack集群瘫痪，进而会出现数据的丢失，从而降低用户体验的问题。

为解决上述问题，本申请方法根据本申请的第一方面，本申请提出了一种OpenStack集群中虚拟资源的资源状态信息推送方法，该资源状态信息推送方法用于公有云服务系统，公有云服务系统包括公有云平台和多个OpenStack集群；状态信息推送方法包括：

根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知；

在公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型；

当OpenStack集群获取到公有云平台的资源请求时，生成资源请求对应的notification消息，使用OpenStack Notification机制将notification消息推送至消息通知对应的消息队列中；

使用OpenStack Notifier服务从消息队列中提取notification消息，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息。

优选的，上述状态信息推送方法中，根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知的步骤，包括：

从OpenStack集群中，查找资源类型对应的配置文件；

从资源类型对应的配置文件中，查找notification消息配置群组；

从notification消息配置群组的配置项中添加与消息队列对应的消息通知。

优选的，上述状态信息推送方法中，在公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型的步骤，包括：

使用OpenStackNotifier服务获取多种虚拟资源的操作业务；

分别定义每种操作业务对应的最终消息事件，以及定义每种最终消息事件的最终消息事件类型，其中，每种最终消息事件类型对应有一种资源状态；

在OpenStackNotifier服务中定义虚拟资源的最终消息事件类型列表；

将多种最终消息事件分别对应的最终消息事件类型添加至最终消息事件类型列表。

优选的，上述状态信息推送方法中，生成资源请求对应的notification消息，使用OpenStack Notification机制将notification消息推送至消息通知对应的消息队列中的步骤，包括：

公有云平台的应用后端服务，通过网络服务器将资源请求路由至OpenStack集群的资源API服务；

OpenStack集群的资源API服务，生成资源请求对应的资源响应，按照原路由路径返回资源响应；

资源API服务生成资源请求对应的生产消息；

OpenStack集群的OpenStack管理服务消费生产消息，得到生产消息对应的notification消息；

OpenStack管理服务提取notification消息的消息通知，将notification消息推送至消息通知对应的消息队列中。

优选的，上述状态信息推送方法中，使用OpenStackNotifier服务从消息队列中提取notification消息，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息的步骤，包括：

OpenStackNotifier服务从消息队列中提取notification消息；

OpenStackNotifier服务提取notification消息的最终消息事件类型，判断notification消息的最终消息事件类型是否在预定义的最终消息事件类型列表中；

若最终消息事件类型在最终消息事件类型列表中，则使用最终消息事件类型对notification消息进行解析和封装，得到notification消息的资源状态信息。

优选的，上述状态信息推送方法中，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息的步骤，包括：

OpenStack Notifier服务使用HTTP请求，将资源状态信息推送至公有云平台的消息队列缓存器；

消息队列缓存器持久化资源状态信息，将资源状态信息发送至公有云平台的应用后端服务；

应用后端服务对资源状态信息的时间戳进行顺序校验，按照时间戳的顺序推送资源状态信息至公有云平台的应用前端服务。

优选的，上述状态信息推送方法中，OpenStack Notifier服务使用HTTP请求，将资源状态信息推送至公有云平台的消息队列缓存器的步骤，包括：

OpenStack Notifier服务将资源状态信息推送至消息队列缓存器后，判断是否接收到消息队列缓存器的成功响应；

若OpenStack Notifier服务接收到消息队列缓存器的成功响应，则OpenStackNotifier服务结束消息推送；

若OpenStack Notifier服务未接收到消息队列缓存器的成功响应，则OpenStackNotifier服务以非线性间隔时间方式，多次重试推送资源状态信息；

若多次重试推送资源状态信息后，未接收到消息队列缓存器的成功响应，则将资源状态信息放入缓存通道；

间隔预定时间重新将缓存通道中的资源状态信息推送至消息队列缓存器，直至消息队列缓存器成功响应。

根据本申请的第二方面，本申请还提供了一种公有云服务系统，包括：

公有云平台和多个OpenStack集群；其中，

多个OpenStack集群中每一OpenStack集群，用于根据虚拟资源的资源类型在OpenStack集群的配置文件中定义消息通知；

公有云平台，用于在公有平台内部的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型；

OpenStack集群，还用于在获取到公有云平台的资源请求时，生成资源请求对应的notification消息，使用OpenStackNotification机制将notification消息推送至消息通知对应的消息队列中；

公有云平台，还用于使用OpenStack Notifier服务从消息队列中提取notification消息；

公有云平台，还用于根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息。

根据本申请的第三方面，本申请还提供了一种电子设备，包括：

存储器、处理器及存储在存储器上并在处理器上运行的OpenStack集群中虚拟资源的资源状态信息推送程序，虚拟资源的状态信息推送程序被处理器执行时实现上述任一项技术方案提供的虚拟资源的状态信息推送方法的步骤。

根据本申请的第四方面，本申请还提供了一种计算机可读存储介质，计算机可读存储介质内存储有计算机程序，计算机程序被处理器执行时实现上述任一项方法的步骤。

综上，本申请提供的一种OpenStack集群中虚拟资源的资源状态信息推送方案，通过在每一OpenStack集群的配置文件中定义消息通知，在公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型。当OpenStack集群获取到公有云平台的资源请求时，生成资源请求对应的notification消息，该notification消息包括资源状态新。相比于公有云平台的主动查询虚拟资源的实时状态，通过启动OpenStackNotifier服务的主动推送该notification消息，减轻了OpenStack的负载，且能及时将状态展示给用户。综上，本申请提供的技术方案，能够改变策略，由主动查询变为被动推送。即在公有云平台向OpenStack接口发送请求并返回后，启动一个状态推送服务来实时上报OpenStack资源的创建状态，而无需反复调用查询接口，从而避免潜在的问题。这样一来，公有云平台能够更加高效地管理和监控后端OpenStack资源的状态，提升用户体验，并且减轻了OpenStack集群的负载压力。

附图说明

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

图1是现有技术提供的一种一种公有云平台与OpenStack集群的互动方法的流程示意图；

图2是本申请实施例提供的一种公有云服务系统的结构示意图；

图3是本申请实施例提供的一种OpenStack集群中虚拟资源的资源状态信息推送方法的流程示意图；

图4是图3所示实施例提供的一种OpenStack集群的配置文件中消息通知的定义方法的流程示意图；

图5是图3所示实施例提供的一种虚拟资源的最终消息事件类型的定义方法的流程示意图；

图6是图3所示实施例提供的一种资源请求对应的notification消息的生成方法的流程示意图；

图7是图3所示实施例提供的第一种notification消息的解析和封装方法的流程示意图；

图8是图3所示实施例提供的第二种notification消息的解析和封装方法的流程示意图；

图9是图8所示实施例提供的一种将资源状态信息推送至公有云平台的消息队列缓存器的方法的流程示意图；

图10是本申请实施例提供的一种公有云服务系统的结构示意图；

图11是图10所示实施例提供的一种消息推送失败的处理机制的流程示意图；

图12是本申请实施例提供的一种电子设备的结构示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

现有技术的技术方案存在如下技术问题：

现有技术提供的公有云平台获取OpenStack集群中虚拟资源的迁移状态的主要方式为：公有云平台不断向OpenStack集群发起资源请求，以获得虚拟资源当前的状态信息，然后使用该状态信息更新本端数据库。然而，这种联动方法存在一些问题：随着公有云用户和资源请求数量的增加，后端OpenStack集群需要反复调用查询接口，导致后端OpenStack集群的负载会急剧增加，这可能导致响应变慢、服务崩溃甚至整个OpenStack集群瘫痪，进而会出现数据的丢失等安全性问题，从而降低用户体验。

为了解决现有技术中的问题，本申请下述实施例提供了资源状态信息推送方法、系统、电子设备和存储介质的方案，通过改变资源状态信息的策略，由公有云平台的主动查询转变为OpenStack集群的被动推送。即在公有云平台向OpenStack集群的接口发送请求并返回响应后，启动一个状态推送服务来实时上报OpenStack集群中虚拟资源的创建状态，而无需反复调用查询接口，从而避免潜在的响应变慢、服务崩溃，甚至整个OpenStack集群弹簧的问题。这样一来，公有云平台能够更加高效地管理和监控后端OpenStack集群中虚拟资源的状态，从而提升用户体验，并且减轻了OpenStack集群的负载压力。

为实现上述目的，参见图2，图2为本申请实施例提供的一种公有云服务系统的结构示意图。如图2所示，该公有云服务器系统包括公有云平台和多个OpenStack集群。本申请实施例中，公有云平台内置有OpenStackNotifier服务，通过该OpenStackNotifier服务的主动推送，减轻了OpenStack的负载，且能及时将状态展示给用户；另外在OpenStack集群内部有效利用OpenStack Notification机制，根据资源请求生成notification通知消息，该通知消息包括针对虚拟资源的关键操作点增加消息通知topic(包括成功和失败消息通知)，且放入消息通知topic对应的消息队列中，能够丰富虚拟资源的状态监控能力。

图3为本申请实施例提供的一种OpenStack集群中虚拟资源的资源状态信息推送方法的流程示意图。如图3所示，该资源状态信息推送方法用于图1和图10所示的公有云服务系统，公有云服务系统包括公有云平台和多个OpenStack集群；状态信息推送方法包括：

S110：根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知。该消息通知topic与虚拟资源的资源类型相对应，而资源类型又与OpenStack集群的消息队列相对应，这样在存在notification消息的事件时，就能够通过该通知消息将notification消息推送至对应的消息队列MQ中。

具体地，作为一种优选的实施例，如图4所示，上述状态信息推送方法中，步骤S110：根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知的步骤，包括：

S111：从OpenStack集群中，查找资源类型对应的配置文件。例如在nova资源类型的配置文件nova.conf；cinder资源类型的配置文件cinder.conf。

S112：从资源类型对应的配置文件中，查找notification消息配置群组。例如：在nova资源类型的配置文件nova.conf中查找notification消息配置群组oslo_messaging_notifications group；在cinder资源类型的配置文件cinder.conf中查找notification消息配置群组oslo_messaging_notifications group。

S113：从notification消息配置群组的配置项中添加与消息队列对应的消息通知。因为消息通知设置在具体资源类型的配置文件中，这样就能够在配置文件中添加消息通知，就能够通过查找该消息通知，将notification事件推送到相应的消息队列中，其中，消息队列包括info队列和error队列。

具体地，在nova资源类型的配置文件nova.conf中notification消息配置群组oslo_messaging_notifications group的配置项topics增加nova类型的消息通知novatopic；在cinder资源类型的配置文件cinder.conf中的notification消息配置群组oslo_messaging_notifications group下配置项topics增加cinder类型的消息通知cindertopic，这样在有notification通知消息的事件时就会有对应消息推送到消息通知topic对应的消息队列(包含info和error队列)中。

图3所示实施例提供的资源状态信息推送方法，在每一OpenStack集群的配置文件中定义消息通知后，还包括以下步骤：

S120：在公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型。结合图10所示，公有云平台的OpenStackNotifier服务中定义有虚拟资源的最终消息事件类型列表，该最终消息事件类型列表包括定义的多种最终消息事件，该最终消息事件为虚拟资源创建操作业务时，表面该虚拟资源的资源状态，这样通过该最终消息事件查找匹配notification消息，就能够确定该notification消息对应的资源状态，例如资源状态为“请求中”、资源状态为“结束”以及资源状态为“可用”等。通过该方法，公有云平台能够实时获取到每个OpenStack集群中虚拟资源的资源状态的变化情况，并及时更新用户可见的资源状态。

具体地，作为一种优选的实施例，如图5所示，上述状态信息推送方法中，步骤S120：在公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型的步骤，包括：

S121：使用OpenStackNotifier服务获取多种虚拟资源的操作业务。例如虚拟机的创建业务，虚拟机的最终消息事件为compute.instance.create.end。

S122：分别定义每种操作业务对应的最终消息事件，以及定义每种最终消息事件的最终消息事件类型，其中，每种最终消息事件类型对应有一种资源状态。

S123：在OpenStackNotifier服务中定义虚拟资源的最终消息事件类型列表。

S124：将多种最终消息事件分别对应的最终消息事件类型添加至最终消息事件类型列表。

具体地，例如若存在虚拟机的创建业务，则虚拟机的最终消息事件为compute.instance.create.end，该最终消息事件表明事件类型是该类型的notification消息发送到消息队列时，虚拟机的状态是ACTIVE的，能够进行操作或使用；当然在虚拟机创建业务时，也有虚拟机的创建失败事件compute.instance.create.error，此时虚拟机是ERROR状态，不能再进行后续操作。综上，在OpenStack Notifier服务设置包含所有虚拟资源的最终消息事件类型列表，能够进行后续的消息过滤和推送。

图3所示实施例提供的技术方案，在公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型的步骤之后，还包括：

S130：当OpenStack集群获取到公有云平台的资源请求时，生成资源请求对应的notification消息，使用OpenStackNotification机制将notification消息推送至消息通知对应的消息队列中。

具体地，作为一种优选的实施例，如图6所示，上述状态信息推送方法中，步骤S130：生成资源请求对应的notification消息，使用OpenStack Notification机制将notification消息推送至消息通知对应的消息队列中的步骤，包括：

S131：公有云平台的应用后端服务，通过网络服务器将资源请求路由至OpenStack集群的资源API服务；结合图10所示云服务系统可知，用户在公有云平台的应用前端进行资源的业务需求操作，应用后端服务通过Nginx将资源请求路由到OpenStack集群中的资源API服务中。

S132：OpenStack集群的资源API服务，生成资源请求对应的资源响应，按照原路由路径返回资源响应。OpenStack集群的资源API服务对该资源请求做出响应，得到资源响应，并将该资源响应沿原路由路径返回至公有云平台的应用前端。

S133：资源API服务生成资源请求对应的生产消息。资源API服务生成该资源请求对应的生产消息，然后向OpenStack集群内部的消息队列MQ中发送资源操作消息，即该生产消息。

S134：OpenStack集群的OpenStack管理服务消费生产消息，得到生产消息对应的notification消息。

S135：OpenStack管理服务提取notification消息的消息通知，将notification消息推送至消息通知对应的消息队列中。负责资源落地的OpenStack管理服务消费该生产消息，然后对该生产消息进行落地，将落地结果封装为notification消息并发送到上述OpenStack集群内部的消息队列MQ中。

本申请实施例提供的技术方案，通过上述方式OpenStack集群在获取到公有云平台的资源请求后，不仅能够做出响应，还能够使用自身的OpenStack管理服务器生成notification消息，然后按照该notification消息的消息通知，将notification消息推送至该消息通知topic对应的消息队列MQ，然后通过该消息队列MQ将notification消息推送至公有云平台。Notification消息如下：在OpenStack服务内部，封装资源状态消息体和资源所处的最终消息事件，将此内容推送到预定义的消息通知topic所对应的消息队列中。其中，info内容就是此topic的info队列，error内容就是此topic的error队列。

图3所示实施例提供的技术方案，在使用OpenStackNotification机制将notification消息推送至消息通知对应的消息队列中的步骤之后，还包括：

S140：使用OpenStackNotifier服务从消息队列中提取notification消息，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息。如上所述，notification消息包括虚拟资源的最终消息事件，这样就能够按照预定义的最终消息事件类型匹配该notification消息的最终消息事件，使用上述最终消息事件类型对该notification消息进行解析和封装。具体地，封装的资源状态消息提存在特定操作的标识，使公有云平台的应用后端能够清楚了解该操作对应的业务。

具体地，作为一种优选的实施例，如图7所示，该步骤S140：使用OpenStackNotifier服务从消息队列中提取notification消息，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息，具体包括：

S141：OpenStack Notifier服务从消息队列中提取notification消息。Notification消息在OpenStack服务内部，封装资源状态消息体和资源所处的最终消息事件。

S142：OpenStackNotifier服务提取notification消息的最终消息事件类型，判断notification消息的最终消息事件类型是否在预定义的最终消息事件类型列表中；若最终消息事件类型在最终消息事件类型列表中，则执行步骤S143。

S143：使用最终消息事件类型对notification消息进行解析和封装，得到notification消息的资源状态信息。

本申请实施例提供的技术方案中，OpenStackNotifier服务分别根据各个OpenStack集群内部消息队列中消息所属的事件类型是否在定义的最终消息事件类型列表中，若在该最终消息事件类型列表则进行消息解析和组装；封装的资源状态消息体有特定某个操作的标识，使公有云平台的应用后端服务能清楚了解操作的业务。，

另外，作为另一种优选的实施例，如图8所示，上述状态信息推送方法中，步骤S140：使用OpenStackNotifier服务从消息队列中提取notification消息，根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息的步骤，包括：

S144：OpenStack Notifier服务使用HTTP请求，将资源状态信息推送至公有云平台的消息队列缓存器。消息队列缓存器也包含多种消息队列，该消息队列与上述资源类型的消息通知topic相对应，因此在得到资源状态信息后，能够将该资源状态信息推送至消息队列缓存器中消息通知topic对应的消息队列。

S145：消息队列缓存器持久化资源状态信息，将资源状态信息发送至公有云平台的应用后端服务。其中，该资源状态信息仍以消费信息的状态存在，消息队列缓存器持久化该消费消息，然后将该消费消息发送至应用后端服务，如果发送失败，会将该消息进行标记，该标记用于重试发送消息。消息缓存器中的消息队列MQ限制外部的直接访问，使用安全设备进行过滤和监控流量，从而保证MQ的消息安全。

S146：应用后端服务对资源状态信息的时间戳进行顺序校验，按照时间戳的顺序推送资源状态信息至公有云平台的应用前端服务。应用后端服务能够对上述消费消息的时间戳进行顺序校验，按照时间戳的顺序推送上述消费消息，以避免并发时的消息混乱情况。

通过上述方式，能够在公有云平台向OpenStack集群请求资源时，实时监控和更新虚拟资源的资源状态信息，这样能够提供给用户实时且准确的资源状态，使其能够了解资源操作的进展，并做出相应的决策。

其中，作为一种优选的实施例，如图9所示，上述状态信息推送方法中，S144：OpenStack Notifier服务使用HTTP请求，将资源状态信息推送至公有云平台的消息队列缓存器的步骤，包括：

S1441：OpenStackNotifier服务将资源状态信息推送至消息队列缓存器。

S1442：OpenStackNotifier服务判断是否接收到消息队列缓存器的成功响应。

S1443：若OpenStackNotifier服务接收到消息队列缓存器的成功响应，则OpenStackNotifier服务结束消息推送。

S1444：若OpenStackNotifier服务未接收到消息队列缓存器的成功响应，则OpenStackNotifier服务以非线性间隔时间方式，多次重试推送资源状态信息。

S1445：若多次重试推送资源状态信息后，未接收到消息队列缓存器的成功响应，则将资源状态信息放入缓存通道。

S1446：间隔预定时间重新将缓存通道中的资源状态信息推送至消息队列缓存器，直至消息队列缓存器成功响应。

本申请实施例提供的技术方案，OpenStack Notifier服务内部针对消息推送失败或者公有云平台的消息队列缓存器的异常场景存在相应的处理机制，若OpenStackNotifier服务接收到消息队列缓存器的成功响应，则判定推送成功，此时结束消息推送服务。若未接收到成功响应，则OpenStackNotifier服务以非线性间隔时间的方式，多层重试推送该信息，若仍未成功，则将该资源状态信息放入缓存通道中，从而避免该信息占用过多推送资源，在缓存通道中间隔预定时间推送该资源状态信息，不断尝试直至成功，从而使得公有云平台的前端用户实时了解到OpenStack集群内的资源状态的更新情况。

具体地，结合图3至图9所示方法以及图10所示的公有云服务系统，当公有云平台100的应用后端服务102通过Ngnix103向OpenStack集群200请求资源时，在应用前端101将用户可见的资源状态设置为"请求中"。同时，在每个OpenStack集群200中，当每个虚拟资源的资源状态发生变化时，通过监听预定义的最终消息事件类型，状态推送服务OpenStackNotifier服务104能够获取到OpenStack集群200内部操作资源结束的消息。然后将这些消息解析并组装成HTTP方式，直接推送到消息队列缓存器105中，公有云平台100再根据时间顺序拉取消息队列缓存器105中的最终消息。这样一来，公共平台100就能够将用户可见的资源状态设置为"可用"。通过这种方法，公有云平台100能够实时获取到每个OpenStack集群200中虚拟资源状态的变化情况，并及时更新用户可见的资源状态。这样不仅提高了系统的响应速度，也增强了用户对资源状态的可感知性和可靠性。

综上，本申请提供的OpenStack集群中虚拟资源的资源状态信息推送方法，通过在每一OpenStack集群的配置文件中定义消息通知，在公有云平台的OpenStack Notifier服务中定义虚拟资源的最终消息事件类型。当OpenStack集群获取到公有云平台的资源请求时，生成资源请求对应的notification消息，该notification消息包括资源状态新。相比于公有云平台的主动查询虚拟资源的实时状态，通过启动OpenStackNotifier服务的主动推送该notification消息，减轻了OpenStack的负载，且能及时将状态展示给用户。综上，本申请提供的技术方案，能够改变策略，由主动查询变为被动推送。即在公有云平台向OpenStack接口发送请求并返回后，启动一个状态推送服务来实时上报OpenStack资源的创建状态，而无需反复调用查询接口，从而避免潜在的问题。这样一来，公有云平台能够更加高效地管理和监控后端OpenStack资源的状态，提升用户体验，并且减轻了OpenStack集群的负载压力。

另外，基于上述方法实施例的同一构思，本申请实施例还提供了公有云服务系统，用于实现本申请的上述方法，由于该方法实施例解决问题的原理与系统相似，因此至少具有上述实施例的技术方案所带来的所有有益效果，在此不再一一赘述。

参见图10，图10为本申请实施例提供的一种公有云服务系统的结构示意图，该公有云服务系统，包括：

公有云平台100和多个OpenStack集群200；其中，

多个OpenStack集群200中每一OpenStack集群，用于根据虚拟资源的资源类型在OpenStack集群的配置文件中定义消息通知；

公有云平台100，用于在公有平台内部的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型；

OpenStack集群200，还用于在获取到公有云平台的资源请求时，生成资源请求对应的notification消息，使用OpenStackNotification机制将notification消息推送至消息通知对应的消息队列中；

公有云平台100，还用于使用OpenStackNotifier服务从消息队列中提取notification消息；

公有云平台100，还用于根据最终消息事件类型对notification消息进行解析和封装，得到并推送资源状态信息。

上述公有云服务系统的工作过程如下：

1.每个OpenStack集群200根据资源类型在配置文件中定义消息通知topic，比如nova资源类型的配置文件nova.conf中oslo_messaging_notifications group下配置项topics增加nova类型的消息通知nova topic，cinder资源类型的配置文件cinder.conf中oslo_messaging_notifications group下配置项topics增加cinder类型的消息通知cindertopic，这样在有notification通知消息的事件时就会有对应消息推送到消息通知topic对应的消息队列(包含info和error队列)中；

2.OpenStack Notifier服务104定义虚拟资源的最终消息事件类型列表，比如虚拟机的创建业务，该虚拟机的最终消息事件为compute.instance.create.end，表明最终消息事件类型是这个notification消息发送到消息队列时，虚拟机的状态是ACTIVE的，能够进行操作或使用了；当然也有虚拟机的创建失败事件compute.instance.create.error，此时虚拟机是ERROR状态，不能再进行后续操作。因此OpenStackNotifier服务104包含所有的虚拟资源的最终消息事件类型列表，以便进行后续的消息过滤和推送。

3.用户在公有云平台100的应用前端服务101进行资源的业务需求操作，应用后端服务102通过Nginx103或者LVS将资源请求路由到OpenStack集群200的资源API服务201中；

4.OpenStack集群200的资源API服务201对资源请求做出响应，并向OpenStack集群内部的消息队列MQ203发送资源操作消息(即图10中的生产消息)；

5.负责资源落地的OpenStack管理服务202消费相应的生产消息，然后进行落地，将落地结果消息(即图10中的消费消息)发送到OpenStack集群200内部的消息队列MQ203中。该消费消息即notification消息。

6.OpenStack Notifier服务104分别根据各个OpenStack集群200内部消息队列MQ203中notification消息所属的事件类型是否在定义的最终消息事件类型列表中进行消息的解析和组装；封装的资源状态消息体有特定某个操作的标识，使公有云平台100的应用后端服务102能清楚了解操作的是哪种业务。

7.OpenStackNotifier服务104使用HTTP请求将组装好的消息推送到公有云平台100的消息队列缓存器105中。

8.公有云平台100的消息队列缓存器105持久化上述组装好的消息，然后将该消息发送给应用后端服务102。如果消息发送失败，会将消息进行标记，用来重试发送。消息队列缓存器105中的消息队列能够限制外部的直接访问，使用安全设备进行过滤和监控流量，保证了消息队列中的消息安全。后端应用服务102会对消费消息的时间戳进行顺序校验，以避免并发时的消息混乱情况。

通过上述过程，能够实现在公有云平台100向OpenStack集群200请求资源时，实时监控和更新虚拟资源的资源状态信息。这样能够提供给用户准确的资源状态，使其能够了解资源操作的进展，并做出相应的决策。

另外，OpenStackNotifier服务内部针对消息推送失败或者公有云平台100的消息队列缓存器105的异常场景有相应的处理机制，如图11所示。具体地：

1.如果OpenStackNotifier服务104组装的消息体成功发送给公有云平台的消息队列缓存器105，对端做出正常的响应，则此消息推送结束；

2.如果OpenStack Notifier服务104没有收到确认应答或者公有云平台100的消息缓存器105服务异常，则会进行重试推送。重试是以非线性间隔时间方式，防止对对端造成冲击。进行5次重试推送时仍是失败的话就将原消息放入缓存通道中，进行5s间隔再进行非线性5次重试，反复进行。当通道达到限制后，则阻塞消费OpenStack消息以避免消息丢失。其间按放入通道中的顺序取消息来在一定间隔内向消息队列缓存器105尝试推送，不断尝试，直至消息推送成功，这样保证OpenStack消息队列和消息队列缓存器105中消息一致。

参见图12，图12为申请实施例提供的一种电子设备的结构示意图。如图12所示，该电子设备包括：

处理器1001、通信总线1002、通信模块1003、存储器1004及存储在存储器1004上并在所述处理器1001上运行的OpenStack集群中虚拟资源的资源状态信息推送程序，该OpenStack集群中虚拟资源的资源状态信息推送程序被处理器1001执行时实现如上述任一项实施例提供的OpenStack集群中虚拟资源的资源状态信息推送方法的步骤。

上述电子设备中的存储器1004、处理器1001通过通信总线1002和通信接口进行通信。所述通信总线1002能够是外设部件互连标准(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，简称EISA)总线等。该通信总线1002能够分为地址总线、数据总线和控制总线等。

存储器1004能够包括随机存取存储器(Random Access Memory，简称RAM)，也能够包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

可选的，存储器104还能够是至少一个位于远离前述处理器的存储装置。

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

根据本申请实施例的又一方面，还提供了一种具有处理器可执行的非易失的程序代码的计算机可读存储介质。该计算机可读存储介质内存储有计算机程序，该计算机程序被处理器执行时实现上述任一项实施例所述的基于AR技术的真实场景中数字藏品的生成方法的步骤。

可选地，在本申请实施例中，计算机可读存储介质被设置为存储用于所述处理器执行上述方法的程序代码。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

应当注意的是，在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的单词“一”或“一个”不排除存在多个这样的部件。本申请可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种OpenStack集群中虚拟资源的资源状态信息推送方法，其特征在于，所述资源状态信息推送方法用于公有云服务系统，所述公有云服务系统包括公有云平台和多个OpenStack集群；所述资源状态信息推送方法包括：

根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知；

在所述公有云平台的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型；

当所述OpenStack集群获取到所述公有云平台的资源请求时，生成所述资源请求对应的notification消息，使用OpenStack Notification机制将所述notification消息推送至所述消息通知对应的消息队列中；

使用所述OpenStackNotifier服务从所述消息队列中提取所述notification消息，根据所述最终消息事件类型对所述notification消息进行解析和封装，得到并推送资源状态信息。

2.根据权利要求1所述的状态信息推送方法，其特征在于，所述根据虚拟资源的资源类型，在每一OpenStack集群的配置文件中定义消息通知的步骤，包括：

从所述OpenStack集群中，查找所述资源类型对应的配置文件；

从所述资源类型对应的配置文件中，查找notification消息配置群组；

从所述notification消息配置群组的配置项中添加与所述消息队列对应的消息通知。

3.根据权利要求1所述的状态信息推送方法，其特征在于，所述在所述公有云平台的OpenStack Notifier服务中定义虚拟资源的最终消息事件类型的步骤，包括：

使用所述OpenStackNotifier服务获取多种虚拟资源的操作业务；

分别定义每种操作业务对应的最终消息事件，以及定义每种所述最终消息事件的最终消息事件类型，其中，每种最终消息事件类型对应有一种资源状态；

在所述OpenStackNotifier服务中定义所述虚拟资源的最终消息事件类型列表；

将多种所述最终消息事件分别对应的最终消息事件类型添加至所述最终消息事件类型列表。

4.根据权利要求1所述的状态信息推送方法，其特征在于，所述生成所述资源请求对应的notification消息，使用OpenStackNotification机制将所述notification消息推送至所述消息通知对应的消息队列中的步骤，包括：

所述公有云平台的应用后端服务，通过网络服务器将所述资源请求路由至所述OpenStack集群的资源API服务；

所述OpenStack集群的资源API服务，生成所述资源请求对应的资源响应，按照原路由路径返回所述资源响应；

所述资源API服务生成所述资源请求对应的生产消息；

所述OpenStack集群的OpenStack管理服务消费所述生产消息，得到所述生产消息对应的notification消息；

所述OpenStack管理服务提取所述notification消息的消息通知，将所述notification消息推送至所述消息通知对应的消息队列中。

5.根据权利要求3所述的状态信息推送方法，其特征在于，所述使用所述OpenStackNotifier服务从所述消息队列中提取所述notification消息，根据所述最终消息事件类型对所述notification消息进行解析和封装，得到并推送资源状态信息的步骤，包括：

所述OpenStackNotifier服务从所述消息队列中提取所述notification消息；

所述OpenStackNotifier服务提取所述notification消息的最终消息事件类型，判断所述notification消息的最终消息事件类型是否在预定义的所述最终消息事件类型列表中；

若最终消息事件类型在所述最终消息事件类型列表中，则使用所述最终消息事件类型对所述notification消息进行解析和封装，得到所述notification消息的资源状态信息。

6.根据权利要求1或5所述的状态信息推送方法，其特征在于，所述使用所述OpenStackNotifier服务从所述消息队列中提取所述notification消息，根据所述最终消息事件类型对所述notification消息进行解析和封装，得到并推送资源状态信息的步骤，包括：

所述OpenStackNotifier服务使用HTTP请求，将所述资源状态信息推送至所述公有云平台的消息队列缓存器；

所述消息队列缓存器持久化所述资源状态信息，将所述资源状态信息发送至所述公有云平台的应用后端服务；

所述应用后端服务对所述资源状态信息的时间戳进行顺序校验，按照所述时间戳的顺序推送所述资源状态信息至所述公有云平台的应用前端服务。

7.根据权利要求1所述的状态信息推送方法，其特征在于，所述OpenStackNotifier服务使用HTTP请求，将所述资源状态信息推送至所述公有云平台的消息队列缓存器的步骤，包括：

所述OpenStackNotifier服务将所述资源状态信息推送至消息队列缓存器后，判断是否接收到所述消息队列缓存器的成功响应；

若所述OpenStackNotifier服务接收到所述消息队列缓存器的成功响应，则所述OpenStackNotifier服务结束消息推送；

若所述OpenStackNotifier服务未接收到所述消息队列缓存器的成功响应，则所述OpenStackNotifier服务以非线性间隔时间方式，多次重试推送所述资源状态信息；

若所述多次重试推送所述资源状态信息后，未接收到所述消息队列缓存器的成功响应，则将所述资源状态信息放入缓存通道；

间隔预定时间重新将所述缓存通道中的资源状态信息推送至所述消息队列缓存器，直至所述消息队列缓存器成功响应。

8.一种公有云服务系统，其特征在于，包括：

公有云平台和多个OpenStack集群；其中，

所述多个OpenStack集群中每一OpenStack集群，用于根据虚拟资源的资源类型在所述OpenStack集群的配置文件中定义消息通知；

所述公有云平台，用于在所述公有平台内部的OpenStackNotifier服务中定义虚拟资源的最终消息事件类型；

所述OpenStack集群，还用于在获取到所述公有云平台的资源请求时，生成所述资源请求对应的notification消息，使用OpenStack Notification机制将所述notification消息推送至所述消息通知对应的消息队列中；

所述公有云平台，还用于使用所述OpenStackNotifier服务从所述消息队列中提取所述notification消息；

所述公有云平台，还用于根据所述最终消息事件类型对所述notification消息进行解析和封装，得到并推送资源状态信息。

9.一种电子设备，其特征在于，包括：

存储器、处理器及存储在所述存储器上并在所述处理器上运行的OpenStack集群中虚拟资源的资源状态信息推送程序，所述虚拟资源的状态信息推送程序被所述处理器执行时实现如权利要求1至7中任一项所述的虚拟资源的状态信息推送方法的步骤。

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