阅读说明：本技术 消息处理方法及装置、消息处理设备及存储介质 (Message processing method and device, message processing equipment and storage medium ) 是由 杨巍巍 房耘耘 马琪 于 2019-04-08 设计创作，主要内容包括：本发明实施例公开了一种消息处理方法及装置、消息处理设备及存储介质。所述方法包括：接收目标消息；确定所述目标消息的项目信息；根据所述项目信息及消息策略,利用与所述项目信息对应的消息队列进行所述目标消息的传输；如此,中间件在消息的生产者和消费者之间利用消息队列传输消息时,会根据消息策略将待处理消息有针对性压入对应的消息队列；如此,在出现消息传递失败时,至少可以根据当前传输失败的消息所在的项目,定位出消息出现故障的消息队列,有利于简化消息出错队列的定位和问题排查。(The embodiment of the invention discloses a message processing method and device, message processing equipment and a storage medium. The method comprises the following steps: receiving a target message; determining item information of the target message; according to the project information and the message strategy, transmitting the target message by using a message queue corresponding to the project information; therefore, when the middleware transmits the message between the producer and the consumer of the message by using the message queue, the message to be processed is pertinently pressed into the corresponding message queue according to the message strategy; therefore, when the message transmission fails, the message queue with the message failure can be positioned at least according to the item of the message with the current transmission failure, and the positioning and problem troubleshooting of the message error queue are facilitated to be simplified.)

消息处理方法及装置、消息处理设备及存储介质

技术领域

本发明涉及信息技术领域，尤其涉及一种消息处理方法及装置、消息处理设备及存储介质。

背景技术

消息实现分布式服务，在当前已成为一种必然趋势。在Openstack云平台下，消息代理方式比较多，包括Rabbitmq、Qpid等。以Rabbitmq这个工具进行详细阐述。当前，Rabbitmq的实现，如图1所示，生产者(publisher)负责产生消息，消息会根据绑定规则，路由到指定的队列，再由消费者端(consumer)的订阅者(Subscriber)负责从队列拉去消息并处理。中间件(broker)通过交换(exchange)并利用队列(Queue)进行消息的生产者和消费者之间的交互。

而Openstack云平台下的服务在消息的使用上，体现在两个方面：

一方面是消息的监听，在服务启动的过程中，会通过指定的目标(target)对象及监听的消息类型，同时创建到Rabbitmq server端的连接，实现服务对于消息的监听；

另一方面是客户端消息的发送，客户端通过初始化远程过程调用(RemoteProcedure Call，RPC)的流程，指定消息的目标对象，及上下文消息的通道，获得连接到Rabbitmq server的通道，从而进一步根据消息的类型。

路由规则发送消息到消息队列中间人(Broker)。

从上述两方面，得知消息在Openstack云平台的流转过程，首先是客户端，获取RPC客户端连接通道，然后按照客户端想要发送的消息模式，封装消息并发送到Broker，然后消费者服务监听到消息的到来，会立即拉取消息，进行处理，如果是同步消息，会返回处理结果，否则不返回。

Openstack下的消息种类分为direct、fanout、topic三种类型，其中服务在启动的时候，一般会监听fanout和topic两种类型的消息，表示监听匹配模式和所有发送到这个路由上的消息，direct类型的消息，一般会在进程中用到，用于接收同步请求的消息返回结果。

在现有消息队列的框架下，首先，一旦平台出了问题，运维人员往往比较不知所措，对于后端服务的认知能力并没有达到研发的水平下，即使知道了出问题的队列，也依旧不能排查问题。

其次，消息的出错的具***置也难以确定。

最后，消息队列是云平台的一个重要的性能瓶颈点，这并不是消息队列本身的能力问题，而是消费者服务能力不足导致的。

发明内容

有鉴于此，本发明实施例期望提供一种消息处理方法及装置、消息处理设备及存储介质

本发明的技术方案是这样实现的：

一种消息处理方法，包括：

接收目标消息；

确定所述目标消息的项目信息；

根据所述项目信息及消息策略，利用与所述项目信息对应的消息队列进行所述目标消息的传输。

基于上述方案，所述方法还包括：

获取所述目标消息的属性信息；

根据所述属性信息，确定是否追踪所述目标消息；

若确定追踪所述目标消息，将所述目标消息的消息记录和/或链路轨迹信息记录到元数据中。

基于上述方案，所述获取所述目标消息的属性信息，包括：

根据追踪模式，获取所述目标消息的属性信息。

基于上述方案，所述根据追踪模式，获取所述目标消息的属性信息，包括以下之一：

根据项目模式，获取所述目标消息的项目信息；

根据路由模式，获取所述目标消息的路由信息；

根据队列模式，获取所述目标消息的队列信息。

基于上述方案，所述根据所述属性信息，确定是否追踪所述目标消息，包括：

将所述属性信息与追踪设定的属性信息进行匹配；

若匹配成功，确定追踪所述目标消息的消息记录和/或链路轨迹信息。

基于上述方案，所述若确定追踪所述目标消息，将所述目标消息的消息记录和/或链路轨迹信息记录到元数据中，包括以下至少之一：

在项目模式下，若确定追踪所述目标消息，将包含所述目标消息的路由信息、队列信息、路由键、消息内容、消息的生产者、消息的接收者、消息的收发情况信息的至少其中之一，记录到所述元数据中；

在路由模式下，若确定追踪所述目标消息，将包含所述目标消息的发送者、接收者、消息内容及消息收发情况信息的至少其中之一，记录到所述元数据中；

在队列模式下，若确定追踪所述目标消息，将包含所述消息的消息内容、消息的生产者、消息的接收者、消息的收发情况信息、消息的项目信息的至少其中之一，记录到所述元数据中。

基于上述方案，所述方法还包括：

根据所述属性信息，确定所述目标消息的追踪优先级；

根据所述追踪优先级，确定追踪所述目标消息的记录方式。

基于上述方案，所述记录方式包括以下至少之一：

信息info方式；

错误error方式；

除错debug方式。

基于上述方案，所述方法还包括：

若所述目标消息的消息队列所在第一集群异常，将所述消息队列和/或进行消息处理的中间件切换到与所述第一集群互为备份的第二集群上。

基于上述方案，所述方法还包括：

若所述第一集群异常，根据所述目标消息所在项目的恢复机制，将所述目标消息所在项目处理异常的消息通过所述第二集群进行恢复。

基于上述方案，所述元数据包括以下数据对象的至少之一：

队列对象；

请求对象；

路由对象；

资源对象。

基于上述方案，所述队列对象包括以下字段的至少之一：

消息标识、路由键、消息头、消息体、消息的生产者、消息的目的；

所述请求对象包括以下字段的至少之一：

标识，所述标识包括以下之一：请求标识、项目标识、队列标识、路由标识、消息标识；

创建时间；

所述路由对象包括以下字段的至少之一：

路由标识；

路由名称；

项目名称；

队列名称；

所述资源对象包括以下字段的至少之一：

中间件的资源标识；

主机资源所在的节点位置；

队列的资源信息；

服务资源所在的服务信息；

端口信息。

基于上述方案，所述方法还包括：

基于查询请求，查询所述元数据获得待追踪消息的消息记录和/或链路轨迹信息；

根据所述消息记录和/或链路轨迹信息，进行信息处理。

基于上述方案，所述根据所述消息记录和/或链路轨迹信息，进行信息处理，包括以下至少之一：

根据所述消息记录和/或链路轨迹信息，进行一个项目的消息数量的统计、单位时间内传递的消息条数的统计、处理消息的消息服务器的服务能力的评估；

根据所述消息记录和/或链路轨迹信息，进行错误节点定位、出错服务的定位、错误原因定位的至少其中之一。

一种消息处理装置，包括：

第一接收模块，用于接收目标消息；

第一确定模块，用于确定所述目标消息的项目信息；

传输模块，用于根据所述项目信息及消息策略，利用与所述项目信息对应的消息队列进行所述目标消息的传输。

基于上述方案，所述装置还包括：

第一获取模块，用于获取所述目标消息的属性信息；

第二确定模块，用于根据所述属性信息，确定是否追踪所述目标消息；

记录模块，用于若确定追踪所述目标消息，将所述目标消息的消息记录和/或链路轨迹信息记录到元数据中。

基于上述方案，所述第一获取模块，用于根据追踪模式，获取所述目标消息的属性信息。

基于上述方案，所述第一获取模块，具体用于执行以下之一：

根据项目模式，获取所述目标消息的项目信息；

根据路由模式，获取所述目标消息的路由信息；

根据队列模式，获取所述目标消息的队列信息。

基于上述方案，所述第二确定模块，用于将所述属性信息与追踪设定的属性信息进行匹配；若匹配成功，确定追踪所述目标消息的消息记录和/或链路轨迹信息。

基于上述方案，所述记录模块，具体用于执行以下之一：

在项目模式下，若确定追踪所述目标消息，将包含所述目标消息的路由信息、队列信息、路由键、消息内容、消息的生产者、消息的接收者、消息的收发情况信息的至少其中之一，记录到所述元数据中；

在路由模式下，若确定追踪所述目标消息，将包含所述目标消息的发送者、接收者、消息内容及消息收发情况信息的至少其中之一，记录到所述元数据中；

在队列模式下，若确定追踪所述目标消息，将包含所述消息的消息内容、消息的生产者、消息的接收者、消息的收发情况信息、消息的项目信息的至少其中之一，记录到所述元数据中。

基于上述方案，所述装置还包括：

第三确定模块，用于根据所述属性信息，确定所述目标消息的追踪优先级；

第四确定模块，用于根据所述追踪优先级，确定追踪所述目标消息的记录方式。

基于上述方案，所述装置还包括：

切换模块，用于若所述目标消息的消息队列所在第一集群异常，将所述消息队列和/或进行消息处理的中间件切换到与所述第一集群互为备份的第二集群上。

基于上述方案，所述装置还包括：

恢复模块，用于若所述第一集群异常，根据所述目标消息所在项目的恢复机制，将所述目标消息所在项目处理异常的消息通过所述第二集群进行恢复。

基于上述方案，所述装置还包括：

查询模块，用于基于查询请求，查询所述元数据获得待追踪消息的消息记录和/或链路轨迹信息；

处理模块，用于根据所述消息记录和/或链路轨迹信息，进行信息处理。

基于上述方案，所述处理模块，用于执行以下至少之一：

根据所述消息记录和/或链路轨迹信息，进行一个项目的消息数量的统计、单位时间内传递的消息条数的统计、处理消息的消息服务器的服务能力的评估；

根据所述消息记录和/或链路轨迹信息，进行错误节点定位、出错服务的定位、错误原因定位的至少其中之一。

一种消息处理设备，包括：

存储器；

处理器，与所述处理器连接，用于通过执行存储在所述存储器上的计算机可执行指令，能够实现前述一个或多个技术方案提供的消息处理方法。

一种计算机存储介质，所述计算机存储介质存储有计算机可执行指令；所述计算机可执行指令被处理器执行后，能够实现前述一个或多个技术方案提供的消息处理方法。

本发明实施例提供的消息处理方法及装置、消息处理设备及存储介质，会在分项目设置不同的消息队列，如此中间件在消息的生产者和消费者之间利用消息队列传输消息时，会根据消息策略将待处理消息有针对性压入对应的消息队列；如此，在出现消息传递失败时，至少可以根据当前传输失败的消息所在的项目，定位出消息出现故障的消息队列，有利于简化消息的出错的定位，和问题排查。

附图说明

图1为一种消息的传输路径示意图；

图2为本发明实施例提供的一种消息处理方法的流程示意图；

图3为本发明实施例提供的另一种消息处理方法的流程示意图；

图4为本发明实施例提供的一种消息处理装置的结构示意图；

图5为本发明实施例提供的再一种消息处理方法的流程示意图；

图6为本发明实施例提供的一种消息传递示意图；

图7为本发明实施例提供的一种元数据的数据结构示意图；

图8为本发明实施例提供的一种云平台、消息服务器及集群之间的对应关系示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

如图2所示，本实施例提供一种消息处理方法，包括：

步骤S110：接收目标消息；

步骤S120：确定所述目标消息的项目信息；

步骤S130：根据所述项目信息及消息策略，利用与所述项目信息对应的消息队列进行所述目标消息的传输。

在本实施例中，该消息处理方法可以应用于云平台和消息服务器的中间件中。

该中间件可以以插件的形式嵌入到云平台和/或消息服务器中；如此，不用改造云平台和/或消息服务器的物理架构，与现有技术的兼容性强，与此同时可以实现按照项目进行消息队列的区分，实现项目粒度的消息转发及传输等处理。

中间件为位于消息的生产者(Provider)和消费者(Consumer)之间的。中间件至少可用于对需要压入队列的消息或者从队列提取消息的中转。例如，中间件将从生产者提供的消息，按照消息所在的项目，压入对应的消息队列中，以方便消息的消费者从对应的消息队列中拉取消息。

本实施例中所述项目可为一个或多个服务组成。若一个项目由多个服务组成，这些服务之间为具有关联性的服务。例如，一个软件的管理项目可包括：该软件的认证服务、该软件的升级服务等；这几个服务的关联性就体现在对应于同一个软件。再例如，以移动通信收费项目为例，该通信收费项目可包括：通信计费服务、收费管理服务等。当然以上仅是举例。

在具体的实现过程中，所述项目的设置可以根据需要进行处理。在一些实施例中，一个所述项目可以是一个大服务下一个或多个子服务构成。

在本实施例中，所述目标消息可为任意需要在消息的生产者和消费者之间传输的任意消息，例如，某一个线程产生的触发消息等。

在本实施例中，预先设置了消息策略，该消息策略可以由中间件运行。若接收到一条信息需要在云平台和消息服务器之间进行转发时，首先会确定出消息的项目信息，该项目信息会指示该目标消息所述的项目。不同的项目设置有不同的消息队列，在本实施例中称之为消息队列。

例如，项目A和项目B分别设置了各种用于收发消息的消息队列，项目A的队列可为A队列，项目B的队列可为B队列。在步骤S130中中间件进行消息中转时，可以利用A队列处理项目A的消息，利用B队列处理项目B的消息。

如此，在云平台和消息服务器之间传输的消息，将利用不同的消息队列实现不同项目的消息中转等消息处理，实现了项目级别的消息队列的区分，如此，在定位故障或者有消息堆积时，可以根据项目进行针对性调整，实现云平台和/或消息服务有针对性的性能优化，提升消息传输质量和效率。若消息传输过程中出现错误，至少可以根据目标消息所在项目，确定出现错误的消息队列是哪些，而非是所有队列可以接收所有消息，从而无法定位出出现错误导致消息无法正常传输的消息队列定位难度大的问题，从而有利于目标消息在传递过程中错误定位的简化。

在一些实施例中，所述方法还包括：

分项目记录消息队列的队列状态信息，该队列状态信息可以用于指示对应消息队列的设置的最大长度、平均占用的队列长度等；如此，后续可以根据队列状态信息，调整对应项目所对应的队列参数，此处的队列参数包括但不限于：队列条数、单个消息队列的最大长度等，以满足不同项目传输消息所需的消息队列。

在一些实施例中，所述方法还包括：

在一个项目的消息传输异常时，可以根据该项目所对应消息队列的所述队列状态消息，确定异常是出现在消息队列还是出现在消息接收的消费者，如此，所述队列状态信息还可以用于定位异常。若所述队列状态信息指示该项目对应的消息队列正常，无溢出现象时出现了消息传输失败，则可能异常出现在消费者，而非在消息队列上。

在一些实施例中，如图3所示，所述方法还包括：

步骤S210：获取所述目标消息的属性信息；

步骤S220：根据所述属性信息，确定是否追踪所述目标消息；

步骤S230：若确定追踪所述目标消息，将所述目标消息的消息记录和/或链路轨迹信息记录到元数据中。

所述属性信息可以根据目标消息的消息头进行确定，也可以根据目标消息的上一处理节点的属性进行确定。例如，中间件可以根据生产者的属性进行确定，不同的生产者属于不同的服务或不同的项目，如此，可以根据生产者的属性确定目标消息的属性信息。

在一些实施例中，有一些消息是需要追踪的，而有一些信息是可以不追踪的。例如，重要的信息进行追踪，而不重要的信息可以不进行追踪，如此相对于追踪所有的目标消息，可以减少追踪负荷，简化处理。

所述消息记录包括但不限于：

消息的更新记录；此处的消息的更新记录包括：消息的封装体的更新、消息的内容的更新记录。所述消息的封装体的更新包括但不限于：消息的封装、解封装的相关记录。所述消息内容的更新记录包括：消息内容的添加、删除和/或替换等操作的记录。

在一些实施例中，所述消息记录还包括：

消息的收发状态，例如，消息从一个节点传输到下一个节点的传输时间、传输成功与否等信息。

所述链路轨迹信息，用于指示消息传输的路径；根据所述链路轨迹信息可以知道消息的生产者、传输者及接收者。

通过上述消息记录和/或链路轨迹信息的记录，可以方便后续在消息传输失败的过程中，进行出错分析，该出错分析包括但不限于：出错节点的定位、出错原因的定位等。

在本实施例中，所述消息记录和/或链路轨迹信息存储在元数据中，利用元数据的记录功能，可以实现消息的持久记忆。

在一些实施例中，所述步骤S210可包括：

根据追踪模式，获取所述目标消息的属性信息。

不同的追踪模块所需的属性信息不同。该追踪模式可以是根据用户指示进行设置，也可以是根据项目的属性进行设置的。

由于不同的追踪模式，需要获取不同的目标消息的属性信息，来判断是否需要追踪该目标消息。因此，在步骤S210中是根据当前设定的追踪模式，从目标消息自身或者收发节点来获取所述属性信息。

在一些实施例中，所述步骤S210具体可包括以下之一：

根据项目模式，获取所述目标消息的项目信息；

根据路由模式，获取所述目标消息的路由信息；

根据队列模式，获取所述目标消息的队列信息。

在本实施例中，所述追踪模式可以根据不同粒度的划分。例如，若是项目模式，则需要追踪项目的所有目标消息都需要追踪，则此时在判断一条目标消息是否需要追踪时，首先需要获取当前目标消息的项目信息。

将获取的项目信息与需要追踪项目的项目信息进行匹配，若匹配一致，可确定出当前目标消息是需要追踪的消息。

路由模式下可以用于限定追踪通过特定路由路径传输的信息的追踪。若当前追踪模式为路由模式，则需要获取所述目标消息的路由信息。在获取当前目标消息的路由信息之后，与需要追踪路由的路由消息进行匹配，若匹配一致，可确定出当前目标消息是需要追踪的目标消息。

若当前追踪模式是以队列为粒度的队列模式，则可以获取目标消息需要压入队列的队列信息，将该队列信息与预先确定需要追踪队列的队列信息进行匹配，若匹配一致，则可认为当前目标消息是需要追踪的目标消息。

在一些实施例中，所述追踪模式不限于所述项目模式、路由模式、队列模式，还可以包括以服务为粒度的服务模式。在服务模式下，可以获取目标消息所在服务的服务信息，通过与需要追踪服务的服务信息的匹配，若匹配一致则确定对应的目标消息为需要追踪的目标消息。

所述追踪模式有多种，在一些特定情况下多种追踪模式可以并存，但是若一条消息同时命中多种追踪模式时，仅进行一次追踪，不涉及重复冗余追踪。例如，当前追踪模式同时包括队列模式和项目模式，若一条目标消息同时需要追踪的项目和队列，则可以认为该目标消息是需要追踪的，但是仅进行一次追踪，不在两种模式下同时追踪。

总之，所述步骤S220可包括：将所述属性信息与追踪设定的属性信息进行匹配；若匹配成功，确定追踪所述目标消息的消息记录和/或链路轨迹信息。

所述消息记录和所述链路轨迹信息的相关描述具体参见前述部分，此处就不再重复了。

在本实施例中，在追踪所述目标消息时获得的消息记录和/或链路轨迹信息等各种追踪信息，可记录在元数据中，实现长久记录，也方便查询。

在一些实施例中，所述步骤S220可具体包括以下至少之一：

在项目模式下，若确定追踪所述目标消息，将包含所述目标消息的路由信息、队列信息、路由键、消息内容、消息的生产者、消息的接收者、消息的收发情况信息的至少其中之一，记录到所述元数据中；

在路由模式下，若确定追踪所述目标消息，将包含所述目标消息的发送者、接收者、消息内容及消息收发情况信息的至少其中之一，记录到所述元数据中；

在队列模式下，若确定追踪所述目标消息，将包含所述消息的消息内容、消息的生产者、消息的接收者、消息的收发情况信息、消息的项目信息的至少其中之一，记录到所述元数据中。

在项目模式下，会将描述目标消息的路由路径的路由信息，目标消息压入队列的队列信息、路由时使用的路由键、消息内容、消息的生产者、消息的接收者，以及在各个中转路由节点上收发情况信息等信息中的一个或多个，都记录到元数据中。

所述收发情况信息可包括以下至少之一：

指示是否成功接收到所述目标消息的收发状况信息；

指示接收所述目标消息的第一时间信息；

指示发送所述目标消息的第二时间信息。

在所述路由模式下，且对应的目标消息需要追踪，则会将该目标消息的生产者、接收者、收发情况信息中的一个或多个都记录到元数据中。

在队列模式下，可以将包括消息的生产者、消息的接收者及消息的项目信息的至少其中之一写入到元数据中。

在还有一些实施例中，在所述队列模式下还可以将所述目标消息的路由信息和/或服务消息也写入到所述元数据中。

在一些实施例中，在所述项目模式、路由模式及队列模式的任意一个下，还可以将处理所述目标消息的中间件的标识信息、处理所述目标消息的资源信息、处理所述待处理信息的节点信息、传输端口的端口信息等信息中的一种或多种写入到所述元数据。

所述资源信息可包括：计算资源的资源标识、存储资源的存储标识、带宽资源的带宽标识。所述节点信息用于指示处理所述待处理信息的物理节点和/或虚拟节点的节点标识。所述物理节点包括但不限于主机或集群。所述虚拟节点包括但不限于虚拟机或虚拟机集群。

在一些实施例中，所述元数据存储的目标消息的消息记录和/或链路轨迹信息，至少用于确定出容易出错路由路段的路径信息，或者，可以用于确定出目标消息的完整路由路径的路由信息。

如此，方便后续根据错误分析中错误排除的分析所需的各种信息。

在一些实施例中，所述步骤S220还包括：

根据所述属性信息，确定所述目标消息的追踪优先级；

根据所述追踪优先级，确定追踪所述目标消息的记录方式。

在本实施例中，还根据目标消息的属性信息，确定所述目标消息的追踪优先级。

不同的属性信息的目标消息具有不同的追踪优先级，追踪优先级越高，则采用越加详细的记录方式进行目标消息的记录方式；如此，实现了优先级高的目标消息的详细追踪。

如此，可以根据用户设置或者消息的重要性，采用对应的记录方式进行追踪信息的记录，减少不必要的追踪信息的获取和/或记录。

在一些实施例中，所述记录方式有多种，以下提供几种可选方式：

信息info方式；

错误error方式；

除错debug方式。

在本实施例中，错误方式的记录详细程度高于信息方式；除错方式的记录详细程度高于错误方式。

例如，在一些情况下，信息方式仅记录目标消息追踪过程中的一些通用信息；而错误方式除了会记录通用信息以外，还会记录错误信息，例如，出错的路由节点，错误类型等错误信息。所述除错方式除了记录通用信息、错误信息以外，还会记录一些描述信息，这些描述信息是对通用信息和/或错误信息中一个或多个信息点的进一步详细描述，或者，通用信息和/或错误信息以外的其他信息的详细信息。

所述通用信息包括但不限于：队列信息、路由信息、项目信息、消息类型、消息所在的服务等。

在另一些实施例中，所述方法还包括：

若所述目标消息的消息队列所在第一集群异常，将所述消息队列和/或进行消息处理的中间件切换到与所述第一集群互为备份的第二集群上。

在本实施例中，为了减少单一中间件或单一消息队列异常导致的信息无法正常传输的问题，在本实施例中，所述中间件和消息队列都形成有备份。例如，将主中间件和主消息队列配置在第一集群，将备份中间件和备份消息队列配置在第二集群，若第一集群异常，则自动切换到第二集群上的中间件和备份消息队列上进行消息处理。

在一些实施例中，所述备份中间件和备份消息队列是预先配置在第二集群上的，但在一些情况下，也可以是在检测到主中间件和主消息队列异常时临时在预设的第二集群上配置的。

在一些实施例中，中间件和消息队列的备份，可以以项目为粒度。例如，不同的项目使用不同的中间件和消息队列时，若项目A出现传输异常，可以对整个项目A的消息传输迁移到备份的第二集群上。

在还有一些实施例中，一个中间件可能处理多个项目的目标消息，而消息队列是分项目的，此时，可以仅对消息队列和中间件的主备份切换是分离的。

判断第一集群异常的方式有很多种，以下提供几种可选方式：

第一节点发送的消息在第二节点超时未接收到，例如，客户端发送的消息，接收端在60秒等设定时间内没有接收到；

消息重传率达到重传阈值。

在一些实施例中，所述方法还包括：

若所述第一集群异常，根据所述目标消息所在项目的恢复机制，将所述目标消息所在项目处理异常的消息通过所述第二集群进行恢复。

在本实施例中，为了正常提供服务，各项目都可以设置恢复机制，如项目中某一个服务的消息未成功传输，则在等待特定时间之后或者一旦确定出传输异常之后，就启动恢复机制自动重传等。如此，将中间件和/或消息队列迁移到第二集群上之后，可以基于恢复机制实现异常时间段内未提供服务的补充提供。

在本实施例中，所述元数据设置了不同的数据对象。不同的记录方式可以从一个或多个数据对象来进行目标消息的消息记录和/或链路轨迹信息等追踪信息的记录。所述元数据包括以下数据对象的至少之一：

队列对象；

请求对象；

路由对象；

资源对象。

所述数据对象至少包括一个字段。

不同的数据对象可包括一个不同的字段。

例如，述队列对象包括以下字段的至少之一：

消息标识、路由键、消息头、消息体、消息的生产者、消息的目的。

所述消息标识用于记录消息的序号等唯一标识消息的信息。

路由键可为进行消息的路由查询的关键字。

所述消息头可包括：目标消息的包头。

所述消息体可包括：目标消息的正文。

所述消息的生产者可为消息的来源。

消息的目的可为消息的接收者或消费者。

所述请求对象包括以下字段的至少之一：

标识，所述标识包括以下之一：请求标识、项目标识、队列标识、路由标识、消息标识；

创建时间。

此处的创建时间字段可以用于存储创建元数据中各种数据对象的时间。

所述路由对象包括以下字段的至少之一：

路由标识；

路由名称；

项目名称；

队列名称；

所述资源对象包括以下字段的至少之一：

中间件的资源标识；

主机资源所在的节点位置；

队列的资源信息；

服务资源所在的服务信息；

端口信息。

在一些实施例中，所述方法还包括：基于查询请求，查询所述元数据获得待追踪消息的消息记录和/或链路轨迹信息；根据所述消息记录和/或链路轨迹信息，进行信息处理。

进行了追踪之后就会利用元数据记录各种追踪信息，后续可以基于查询请求查询所述元数据，从而获得所需的信息进行信息处理。

具体的如，所述根据所述消息记录和/或链路轨迹信息，进行信息处理，包括：根据所述消息记录和/或链路轨迹信息，进行一个项目的消息数量的统计、单位时间内传递的消息条数的统计、处理消息的消息服务器的服务能力的评估；根据所述消息记录和/或链路轨迹信息，进行错误节点定位、出错服务的定位、错误原因定位的至少其中之一。

如图4所示，本实施例提供一种消息处理装置，包括：

第一接收模块110，用于接收目标消息；

第一确定模块120，用于确定所述目标消息的项目信息；

传输模块130，用于根据所述项目信息及消息策略，利用与所述项目信息对应的消息队列进行所述目标消息的传输。

在一些实施例中，所述第一接收模块110、第一确定模块120及传输模块130均可为程序模块；所述程序模块被处理器执行后，能够实现前述的目标消息的接收、项目信息的确定及目标消息的传输等操作。

在另一些实施例中，所述第一接收模块110、第一确定模块120及传输模块130可为软硬结合模块；所述软硬结合模块可包括各种可编程阵列，所述可编程阵列可为复杂可编程阵列或现场可编程阵列等。

在还有一些实施例中，所述第一接收模块110、第一确定模块120及传输模块130可为纯硬件模块；所述纯硬件模块包括但不限于专用集成电路。

在一些实施例中，所述装置还包括：

第一获取模块，用于获取所述目标消息的属性信息；

第二确定模块，用于根据所述属性信息，确定是否追踪所述目标消息；

记录模块，用于若确定追踪所述目标消息，将所述目标消息的消息记录和/或链路轨迹信息记录到元数据中。

在一些实施例中，所述第一获取模块，用于根据追踪模式，获取所述目标消息的属性信息。

在一些实施例中，所述第一获取模块，具体用于执行以下之一：

根据项目模式，获取所述目标消息的项目信息；

根据路由模式，获取所述目标消息的路由信息；

根据队列模式，获取所述目标消息的队列信息。

在一些实施例中，所述第二确定模块，用于将所述属性信息与追踪设定的属性信息进行匹配；若匹配成功，确定追踪所述目标消息的消息记录和/或链路轨迹信息。

在一些实施例中，所述记录模块，具体用于执行以下之一：

在项目模式下，若确定追踪所述目标消息，将包含所述目标消息的路由信息、队列信息、路由键、消息内容、消息的生产者、消息的接收者、消息的收发情况信息的至少其中之一，记录到所述元数据中；

在路由模式下，若确定追踪所述目标消息，将包含所述目标消息的发送者、接收者、消息内容及消息收发情况信息的至少其中之一，记录到所述元数据中；

在队列模式下，若确定追踪所述目标消息，将包含所述消息的消息内容、消息的生产者、消息的接收者、消息的收发情况信息、消息的项目信息的至少其中之一，记录到所述元数据中。

在一些实施例中，所述装置还包括：

第三确定模块，用于根据所述属性信息，确定所述目标消息的追踪优先级；

第四确定模块，用于根据所述追踪优先级，确定追踪所述目标消息的记录方式。

在一些实施例中，所述记录方式包括以下至少之一：

信息info方式；

错误error方式；

除错debug方式。

在一些实施例中，所述装置还包括：

切换模块，用于若所述目标消息的消息队列所在第一集群异常，将所述消息队列和/或进行消息处理的中间件切换到与所述第一集群互为备份的第二集群上。

在一些实施例中，所述装置还包括：

恢复模块，用于若所述第一集群异常，根据所述目标消息所在项目的恢复机制，将所述目标消息所在项目处理异常的消息通过所述第二集群进行恢复。

在一些实施例中，所述元数据包括以下数据对象的至少之一：

队列对象；

请求对象；

路由对象；

资源对象。

在一些实施例中，所述队列对象包括以下字段的至少之一：

消息标识、路由键、消息头、消息体、消息的生产者、消息的目的；

所述请求对象包括以下字段的至少之一：

标识，所述标识包括以下之一：请求标识、项目标识、队列标识、路由标识、消息标识；

创建时间；

所述路由对象包括以下字段的至少之一：

路由标识；

路由名称；

项目名称；

队列名称；

所述资源对象包括以下字段的至少之一：

中间件的资源标识；

主机资源所在的节点位置；

队列的资源信息；

服务资源所在的服务信息；

端口信息。

在一些实施例中，所述装置还包括：

查询模块，用于基于查询请求，查询所述元数据获得待追踪消息的消息记录和/或链路轨迹信息；

处理模块，用于根据所述消息记录和/或链路轨迹信息，进行信息处理。

在一些实施例中，所述处理模块，用于执行以下至少之一：

根据所述消息记录和/或链路轨迹信息，进行一个项目的消息数量的统计、单位时间内传递的消息条数的统计、处理消息的消息服务器的服务能力的评估；

根据所述消息记录和/或链路轨迹信息，进行错误节点定位、出错服务的定位、错误原因定位的至少其中之一。

以下结合上述任意实施例提供几个具体示例：

示例1：

本示例提出的一种消息队列的策略，是基于中间件技术和中间件的通知消息的能力联合使用的。

本示例提出的云平台消息策略的系统架构如图5所示，主要包括四部分，分别是云平台、消息策略、中间件、消息服务器。

云平台是提供服务的平台，包含消费者(Consumer)、产生者(Producer)两个执行主体。

中间件，是封装消息在云平台和消息服务器传递接口层。

消息服务器，指提供消息存储转发的消息服务器。

在初始化的过程中，首先云平台的服务启动，充当Consumer的角色，建立到消息服务器的通道，并通知消息服务器建立路由、队列等信息；然后监听对应的队列，此时服务启动完成了，可以提供服务。

当用户通过云平台发起请求的时候，客户端借助云平台中的生产者(Publisher)对象，向对应的服务队列发送消息。因此，当服务启动完成后，消息在上述框架中的流动过程，如图5的步骤；具体的步骤可如下：

步骤1：生产者(Publisher)建立到消息服务器的连接，消息通过中间件接口；

步骤2：中间件基于消息策略进行消息处理的筛选；

步骤3：再发送给消息服务器；

步骤4：消息服务器将消息通过路由之后压入到消息队列；

步骤5：云平台服务监听到队列中有消息到来，中间件将消息从消息队列拉取出来，会经过消息策略的筛选；

步骤6，消息经过中间件的接口，最后传递到对应的云平台服务，由服务完成对消息的处理。

本示例提出的消息策略的详细设计框架图，如图6所示。消息策略部分，以插件(Plugin)的方式，加入到Openstack框架等云平台中，这样可以兼容之前版本的消息使用方式，灵活方便。

可配置的插件主要设计了两部分内容，元数据(Metadata)和策略(Policy)。

Metadata用于收集生产者、消费者连接中的元数据信息，并需要存储到可持久化存储中去。

Policy用于设定策略，如指定项目或者指定队列或者指定服务等。

而上述两部分内容需要依据Openstack平台中的通知技术及本示例提出的追踪(Trace)插件的支持。依据这两项技术，是为了充分发掘有价值的信息，并实现消息的探索，从而能够分析出消费者的服务能力。

通知技术是Openstack平台下的一项通知能力，能够记录用户操作行为，并分类进行。追踪(Trace)插件会根据用户设定的模式，将记录所有指定到模式行为的消息链路完整记录下来，包括消息的路由、路由键、发送队列、接发消息等。

在本示例中，提出的Metadata的设计，包括4个对象，分别是队列(queue)、请求(request)、路由(router)、资源(resource)，如图7所示。队列对象包括：Id消息id，routing_key消息路由键，headers消息头，body消息体，from_id消息的生产者，to_id接收的消息资源，type接收或者发送消息类型。

request对象包括：id请求对象的唯一标志，这个值对应openstack项目中的请求id，如果没有的话，则随机生成，queue_id对应的队列id，对应queue对象中的id，msg_id消息中包含的消息唯一id，create_time请求的创建时间，这个值可以依据时间段对消息进行分析。

router对象包括：id路由的唯一id，exchange_name路由名称，project_name项目名称，queue_name队列名称，有了这些设计，可以按照项目的内容，统计出队列资源的信息。

resource对象包括：id内部资源的id标志，host资源出现的节点位置，service资源所在的服务，port服务监听的端口，有了这个对象的设计，可以随时统计出消息的完整链路轨迹。

本示例提出的policy的概念，是策略的核心内容。Policy可以根据用户的需求设定策略，设计为统计消息队列、追踪Notification的优先级、追踪指定项目的路由、追踪某一时间所有消息收发、查询消息链路、消息集群的主备切换。

本示例的具体实现步骤是根据用户设定的policy策略，然后统计出资源的metadata信息，再由元数据信息做出系统反应。在本示例中提到的policy的策略，是依据收集到的有价值信息进行处理，这些价值信息按照metadata设计的格式进行存储。

在本示例中，Policy中的统计消息队列，如图5所示，现有的技术方案是不包括消息策略部分的，即云平台中的服务在启动后，监听消息服务器中的队列，当有消息到达的时候，进行处理，这其中云平台有很多项目，并且各项目的服务也有很多。因此，消息服务器中的队列数目将会达到很多，显示不直观，用户无法直接确认各队列的所属情况。

本示例中提出的消息策略，主要实现是通过在元数据中的router对象进行记录，云平台中的服务，通过consumer对象，建立到消息队列的连接，进行初始化的工作，由云平台的服务发起建立队列、路由等信息的操作。由中间件从上下文中提取项目信息、路由信息、队列信息，记录到router对象的数据中，但是不会记录重复的数据，此时收集到的队列信息，就被保存在了metadata层，从而系统可以依据metadata的持久化数据存储，根据项目名称或者队列名称，查询到相应的信息，即系统可以具备划分队列的能力，使得消息的定位变得直观而简单。

在本示例中，Policy中的追踪Notification的优先级，具体方案是根据Openstack项目设定的记录级别，包括info、error、debug等几个部分，用户可以自行设定策略，如error级别，这样可以收集到系统所有出错的消息记录，及完整的链路轨迹信息，这些轨迹通过本示例设计的trace模块完成，有了这些消息，用户可以快速查询消息出错的位置、出错的服务、找出根本原因。具体实现过程如下：

Notification是云平台现有的通知消息的一种能力，并且可以按照消息的类型进行记录，比如错误操作的消息，会发送到错误记录队列，但是相关技术，只会在队列中存储消息的内容，并且由于其它原因造成的消息丢失，并不会进行记录或者告知。本示例设计的trace模块的执行者是中间件，设置了三种模式，包括项目、消息路由、队列名称3种模式，如果设定了项目模式，则会根据当前云平台的publisher对象发送的消息中的项目信息，与当前设定的trace项目进行对比，如果是，则继续后面的中间件内容的追踪，将publisher到消息服务器中的消息路由、消息队列、路由键、消息内容、消息的生产者、消息的接收者、收发情况等完整路径记录在metadata层中，反之，则不记录。

如果设定的是队列模式，publisher对象发送的消息会分发到指定消息的队列，查看当前设定的trace队列和pulisher发送的消息队列是否一致，如果一致，则通过中间件，在metadata层中，提取消息的相关内容，包括消息内容，消息的生产者，消息的接收者，消息的收发情况，消息的所属项目等信息。

如果设定的是队列路由模式，pulisher对象发送的消息，在消息服务器中，都会有对应的消息路由信息，通过这个路由信息和当前设置的trace队列路由是否相同，如果相同，则记录下所有通过这条路由的消息，并且记录消息的发送者、接收者、消息内容、消息的收发情况，反之，则不记录。

有了metadata层中对于消息的记录，用户可以查询消息出错的位置、出错的服务、找出根本原因。

举例如下，在metadata中，根据trace的模式，特定的消息内容被记录在metadata的几个对象中，用户可以根据请求id或者消息的id，查询消息的链路及出错的服务位置。如用户查询指定消息的id，通过metadata中的request对象中的msg_id的内容，找到对应的queue对象，queue对象中记录消息的路由键、消息内容、消息来源id等信息，根据消息来源id，对应到resouce对象中的id，即可以找到消息的服务，从而得知服务所在的节点、端口等信息，便于定位问题。

在本示例中，Policy中的追踪某一时间所有消息的收发，这是根据trace模块，统计所有消息的收发及消息的链路，主要是用于统计系统的压力上限，便于架构师合理安排部署节点及服务。举例，在Openstack项目中，项目上线之前，需要做系统压力测试，这个功能就体现了用处，可以设计8个小时的时间维度的统计，所有经过消息服务器的消息都被记录下来，并且存储在metadata层的几个对象中，可以依据metadata的request对象中的create_time这个字段，做一个区间筛查，可以找到这个区间下消息的数量，并根据消息id，对应到metadata对象中的queue对象，得到来源id，再对应resource对象，找到对应的服务，从而得知项目的压力时间，压力位置等信息。

在本示例中，Policy中的查询消息链路，指的是根据metadata层收集到的消息的记录，按照消息ID或者请求ID的方式，找到queue对象，并进一步根据消息的生产者id，找到resource对象中的服务信息，将这些信息呈现给用户，通过这个功能，可以方便用户定位请求出错的原因。

在本示例中，Policy中的追踪指定项目的路由，根据metadata中的router对象，找到相关的路由信息，再通过trace模块监听这些路由消息，记录下消息中的内容、路由、队列、及相关的服务的信息，服务的内容记录在metadata层的resource对象中，有了这些数据可以实现对于项目的能力的检测、统计，可以为用户或者开发者提供有价值的分析数据，trace检测到的信息，可以按照时间序列进行大数据分析。以下举例说明具体的实现过程，设定追踪Openstack平台中nova项目的所有路由，trace模块会记录所有通过这个项目所有路由的消息链路，有了这些消息的内容，可以统计出nova项目核心服务的消息数量，可以量化为每小时多少条，有了这个数据，可以大致估算出服务的能力大小，体现为每个服务在单位时间内处理的请求条数。

最后，本示例提出，Policy中提供集群主备切换，在Openstack项目中，给消息队列集群划分多种资源池，互为主备，并且这些资源池的控制权交由policy负责，Openstack项目中的消息队列参数配置为集群的VIP地址，每当正在使用的集群出了问题，能够自动切换到备集群上，然后出问题的集群能够完成自我的修复，这些修复的能力依赖于一些监控脚本，等到集群恢复正常，又再次加入到被集群中，等待下次的继续使用。具体的实现方法如下：

在Openstack云平台项目中，每一个项目的服务，可以设置消息队列服务器的地址，本示例提出的方案，如图8所示，将消息服务器的地址，增加策略控制，将多个主备集群，用虚拟IP(Virtual Internet Protocol，VIP)地址设计，并且当云平台中的某一类服务出现了连接不上或者消息阻塞在某一个集群的情况下，能够实时切换到另一个集群，判定的方法是服务在启动过程中或者客户端在连接消息队列的过程中，出现的连接不上集群或者客户端在发送消息后超时(默认是等待60s)，就认为服务连接的集群出现了问题。Policy策略能够实时检测出问题，并从集群中重新给服务分配一个集群，但是需要注意的是云平台之前与消息服务器的连接，由于切换集群，就需要重连接。但是之前集群中的队列的内容不需要同步过来，有以下几点原因：云平台上的项目存在retry机制，即丢失的消息，可以重复再发送；队列也不需要同步，重建连接的过程，即相当于服务重建的过程，会自动创建队列、路由等相关信息。除此之外，policy策略中需要清除上一个集群中的问题队列。以保证上一个集群，后续能够继续被循环使用。具体的清理方法，需要借助后端消息服务器的API接口。在图8中展示有集群1至集群n，一个项目的主备份中间件和消息队列，可以布置在集群1至集群n的任意两个集群上。

本实施例提供一种消息处理设备，包括：

存储器；

处理器，与所述处理器连接，用于通过执行存储在所述存储器上的计算机可执行指令，能够实现前述任意技术方案提供的消息处理方法，例如，如图2、图3或图5所示的消息处理方法。

本发明实施例提供了一种计算机存储介质，所述计算机存储介质存储有计算机可执行指令；所述计算机可执行指令被处理器执行后，能够实现前述任意技术方案提供的消息处理方法，例如，能够执行图2、图3及图5所示的消息处理方法中的一个或多个。

本实施例提供的计算机存储介质可为非瞬间存储介质。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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