CN110515748A - 一种消息处理的方法及相关装置 - Google Patents

Abstract

本申请公开了一种消息处理的方法及相关装置，用于将消息生产逻辑通过独立于业务应用程序之外的消息应用程序来实现，使得在业务应用程序中只需要开发核心业务逻辑，降低开发者的工作量。本申请方法应用于第一网络设备，第一网络设备部署有第一应用程序以及第二应用程序，第一应用程序与第二应用程序之间建立有通信连接，该方法具体应用于第一应用程序，该方法包括：接收第二应用程序发送的消息；根据消息在消息队列集合中确定目标消息队列；将消息加入至目标消息队列中；根据目标消息队列向第二网络设备发送消息。

Description

一种消息处理的方法及相关装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种消息处理的方法及相关装置。

背景技术

随着互联网技术的发展，越来越多的用户通过互联网来购物、浏览资讯、观看视频以及交流等等。随着用户的日益增长，伴随而来的是海量的数据行为需求，用户终端与服务器之间以及用于配合实现不同业务的服务器与服务器之间通常需要频繁地收发消息，以实现数据的交换。

对于一些会产生较多消息的业务程序来说，开发者通常会在开发该业务程序的时候，在业务程序中耦合进相应的消息生产逻辑，即在业务程序代码中直接使用不同消息队列的生产应用程序接口(application programming interface，API)，然后自定义消息的处理逻辑来进行消息的生产。

通常来说，为了应对复杂的网络环境，开发者需要在核心业务逻辑外进行大量额外的开发工作，以实现在业务程序中耦合进能够与业务程序相互配合的消息生产逻辑，增加了开发者的额外工作量。

发明内容

本申请实施例提供了一种消息处理的方法及相关装置，通过在同一个网络设备上部署专门用于进行消息生产的应用程序，由该应用程序获取业务应用程序所生成的消息，然后将该消息加入消息队列中进行处理，实现消息的生产，将消息生产逻辑通过独立于业务应用程序之外的消息应用程序来实现，使得在业务应用程序中只需要开发核心业务逻辑，降低了开发者的工作量。

本申请实施例第一方面提供一种消息处理的方法，方法应用于第一网络设备，第一网络设备部署有第一应用程序以及第二应用程序，第一应用程序与第二应用程序之间建立有通信连接，方法应用于第一应用程序，方法包括：

接收第二应用程序发送的消息；

根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

将消息加入至目标消息队列中；

根据目标消息队列向第二网络设备发送消息。

本申请实施例第二方面提供一种消息处理的装置，该消息处理的装置应用于第一应用程序，第一应用程序部署于第一网络设备，第一网络设备部署还部署有第二应用程序，第一应用程序与第二应用程序之间建立有通信连接，该消息处理的装置包括：

接收单元，用于接收第二应用程序发送的消息；

确定单元，用于根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

加入单元，用于将消息加入至目标消息队列中；

发送单元，用于根据目标消息队列向第二网络设备发送消息。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，还包括存储单元；

确定单元，用于确定目标消息队列中的消息数目；

存储单元，用于若目标消息队列中的消息数目大于或等于阈值，则将消息存储于存储空间中；

加入单元，还用于若目标消息队列中的消息数目小于阈值，则将消息加入至目标消息队列中。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，还包括获取单元和删除单元；

获取单元，用于获取第三网络设备发送的配置信息；

删除单元，用于若配置信息中指示对消息进行删除，则删除消息；

存储单元，还用于若配置信息中指示对消息进行存储，则将消息存储于存储空间中。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，

确定单元，还用于确定目标消息队列中的消息数目；

加入单元，还用于若目标消息队列中的消息数目小于阈值，则将存储空间中的消息加入至目标消息队列中。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，

确定单元，还用于确定第二网络设备的异常情况；

发送单元，还用于若第二网络设备异常，则向与第二网络设备对应的备用网络设备发送消息；

发送单元，还用于若第二网络设备正常，则向第二网络设备发送消息。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，

获取单元，还用于获取第三网络设备发送的配置信息；

确定单元，还用于根据配置信息确定目标消息队列的类型；

确定单元，还用于根据目标消息队列的类型确定目标消息队列。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，还包括处理单元

获取单元，还用于获取第三网络设备发送的配置信息；

确定单元，还用于根据配置信息确定消息的编码方式和加密方式；

处理单元，用于根据编码方式和加密方式对消息进行编码和加密，得到处理后的消息；

发送单元，还用于向第二网络设备发送处理后的消息。

在一种可能的设计中，在本申请实施例的第二方面的一种实现方式中，

确定单元，还用于根据消息和目标消息队列确定消息生产指标信息，消息生产指标信息包括消息接收速率、消息生产速率和队列消息数目中的一种或几种；

发送单元，还用于向第三网络设备发送消息生产指标信息，以使得第三网络设备根据消息生产指标信息生成告警信息。

本申请实施例第三方面提供一种网络设备，网络设备部署有第一应用程序以及第二应用程序，网络设备包括：存储器、收发器、处理器以及总线系统；

其中，存储器用于存储第一应用程序和第二应用程序，第一应用程序和第二程序之间建立有通信连接；

处理器用于执行存储器中的第一程序，包括如下步骤：

通过第一应用程序接收第二应用程序发送的消息；

通过第一应用程序将消息加入至目标消息队列中；

通过第一应用程序根据目标消息队列向第二网络设备发送消息；

总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。

本申请实施例第四方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一方面的方法。

本申请实施例第五方面提供了一种包含指令的计算机程序产品，当其在计算机或者处理器上运行时，使得计算机或者处理器执行上述任一方面的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例提供了一种消息处理的方法及相关装置，通过在同一个网络设备上部署专门用于进行消息生产的应用程序，由该应用程序获取业务应用程序所生成的消息，然后将该消息加入目标消息队列中进行处理，实现消息的生产，将消息生产逻辑通过独立于业务应用程序之外的消息应用程序来实现，使得在业务应用程序中只需要开发核心业务逻辑，降低了开发者的工作量。

附图说明

图1为本申请实施例中消息处理的系统的一个架构示意图；

图2为本申请实施例提供的一种消息处理的方法的示例图；

图3为本申请实施例提供的一种目标消息队列的选择示例图；

图4为本申请实施例提供的一种消息生产指标上报的示例图；

图5为本申请实施例提供的一种展示统计报表的示例图；

图6为本申请实施例提供的一种告警信息的界面示例图；

图7为本申请实施例提供的一种消息处理的方法的流程示例图；

图8为本申请实施例提供的一种消息处理的装置的结构示意图；

图9为本申请实施例提供的一种网络设备结构示意图。

具体实施方式

本申请实施例提供了一种消息处理的方法及相关装置，用于降低开发者的工作量。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前，随着越来越多的用户使用互联网，带来了海量的数据行为需求。例如，对于一个用户终端来说，用户终端上的应用程序在一定时间内可能需要向服务器发送大量的消息，例如发送不同的业务请求、上报不同的指标数据以及返回不同的响应消息等等，即应用程序在基于本身的业务逻辑生成大量的消息数据之后，还需要将这些消息数据有效地发送出去。又例如，对于一个服务器来说，服务器上的应用程序可能需要处理大量的请求信息，并且基于请求信息生成大量的响应消息，这些响应消息都要发送至对应的用户终端或者其他的服务器上。一般来说，由于通信上的限制，有效地发送一个消息通常需要一定的时间，而在消息并发量较大的时候(即应用程序在短时间内生成了大量的消息)，大量的消息容易被积压而无法有效处理。为了应对消息并发量大的情况，消息队列应运而生。其中，消息队列指的是在消息的传输过程中用于保存消息的容器，消息队列能够在消息的生成源头到消息的目标之间充当中间者，其主要目的是提供路由并且保证消息的有效传递；如果发送消息时接收者不可用，那么消息队列将会保留消息直至能够有效地进行传递。以网络购物为例，在一些秒杀活动或者抢购活动中，服务器A上的订单系统会在短时间内接收到大量的用户订单，服务器A对这些用户订单进行处理，生成大量的订单消息，并且将订单消息写入到消息队列中，然后基于消息队列中订单消息的顺序，向服务器B上的库存系统发送订单消息，以避免订单消息暴增时，给服务器B上的库存系统带来过大的处理压力，甚至是导致库存系统崩溃。

对于一些会产生较多消息的业务程序来说，开发者通常会在开发该业务程序的时候，在业务程序中耦合进相应的消息生产逻辑，即在业务程序代码中直接使用不同消息队列的生产API(API是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。目的是为应用程序提供一些预先设定好的功能)，然后自定义消息的处理逻辑来进行消息的生产(其中，消息的生产通常指的是实现消息的可靠传输)。具体地，在实际应用环境下，业务程序的开发者通常需要开发以下功能以保障消息生产的可运营性：

1)业务程序需要针对各个消息队列分别开发负载均衡、流量控制、重试逻辑、安全加密等生产逻辑，并通过配置文件进行生产参数调整；

2)业务程序需要开发指标上报功能，以开发对应的展示报表，同时还需要根据各个消息队列的特征选择对应的告警方案；

3)业务程序需要开发高可用方案，如使用主备消息队列集群切换机制以应对单集群异常的情况，开发熔断或落盘逻辑以应对消息生产过载带来的雪崩效应。

显然，为了应对复杂的网络环境，开发者需要在核心业务逻辑外进行大量额外的开发工作，以实现在业务程序中耦合进能够与业务程序相互配合的消息生产逻辑，这就增加了开发者的额外工作量。此外，由于消息生产逻辑与业务程序耦合，当生产API或者是消息队列对应的服务端需要进行升级时，还需要对业务程序的相关代码进行修改或者是重启业务程序的进程，影响了业务核心服务的正常运行。

有鉴于此，本申请实施例提供了一种消息处理的方法，通过在同一个网络设备上部署一个专门用于进行消息生产的应用程序，由该应用程序获取业务应用程序所生成的消息，然后将该消息加入消息队列中来进行消息的生产处理，也就是说，将消息生产逻辑通过独立于业务应用程序之外的应用程序来实现，这样便可以使得开发者在开发业务应用程序的过程中只需要开发核心业务逻辑，而不需要再在业务应用程序的基础上开发与业务应用程序耦合的消息生产逻辑，大大地降低了开发者的工作量。

应理解，本申请实施例应用于消息生产场景，具体地，可以应用于业务应用程序的消息生产场景，其中，业务应用程序可以包括但不限于游戏相关业务的应用程序、广告相关业务的应用程序、金融相关业务的应用程序、即时通讯相关业务的应用程序以及影音娱乐相关业务的应用程序等具有消息生产需要的应用程序。

为了便于理解，以下将对本申请实施例提出的消息处理的方法所应用的系统进行详细的介绍，具体地，该方法应用于图1所示的消息处理的系统，请参阅图1，图1为本申请实施例中消息处理的系统的一个架构示意图，如图所示，第一网络设备通过网络与第二网络设备建立通信连接，第一网络设备上部署有业务应用程序以及消息生产程序，业务应用程序与消息生产程序之间具有通信连接，业务应用程序在生成了消息之后，消息生产程序从业务应用程序获取到消息，根据消息确定目标消息队列，并且将消息加入至目标消息队列中，最后基于目标消息队列向第二网络设备发送相应的消息。

需要说明的是，在本申请实施例中，第一网络设备可以是终端，第二网络设备可以是服务器；或者，第一网络设备是服务器，第二网络设备是服务器；又或者是，第一网络设备是服务器，第二网络设备是终端，在此并不做具体限定，在图1中，仅仅是以第一网络设备为终端，第二网络设备为服务器来进行示例说明。具体地，终端可以包括但不限于个人电脑、智能手机、笔记本电脑、掌上电脑或平板电脑。

以下将结合图2对本申请实施例提供的消息处理的方法进行详细的介绍，请参阅图2，图2为本申请实施例提供的一种消息处理的方法的示例图。

本申请实施例提供了一种消息处理的方法，该方法应用于第一网络设备，第一网络设备部署有第一应用程序以及第二应用程序(为了便于理解，以下将第一应用程序称为消息生产应用程序，第二应用程序称为业务应用程序)，业务应用程序与消息生产应用程序之间建立有通信连接，方法应用于业务应用程序。

具体地，消息生产应用程序与业务应用程序部署于同一个第一网络设备上，并且消息生产应用程序是以边车模式(sidecar pattern)部署于第一网络设备上的，因此，消息生产应用程序也可以成为“边车程序”。其中，边车模式也可以称作挎斗模式，是架构中的一种设计模式的，因为其非常类似于生活中的边三轮摩托车而得名。边车模式主要是通过给应用程序加上一个“边车”的方式来拓展应用程序现有的功能，边车就是加装在摩托车旁来达到拓展功能目的的一个挎斗，比如使得行驶更加稳定、可以拉更多的人和货物或者坐在边车上的人可以给驾驶员指路等。通过边车模式来设置应用程序能够起到给目标应用服务加装一个边车程序来达到控制和逻辑的分离的作用。

在本申请实施例中，通过将消息生产这个在业务服务中不需要实现的控制面功能交给边车程序来实现，可以使得业务服务只需要专注于实现业务逻辑即可，就好像驾驶摩托车的驾驶员只需要管好开车的工作就行，而指挥打仗的事情交给摩托车边车上的指挥官就行。

在实际应用中，首先可以由运维人员在第一网络设备(即业务应用程序所在的网络设备)上部署消息生产应用程序，具体地，运维人员可以通过在网络管理端上通过预先提供的相关页面快速在第一网络设备上安装消息生产应用程序。在消息生产应用程序安装完毕之后，当业务应用程序启动时，业务应用程序可以通过unix套接字(unix socket)与消息生产应用程序进行通信，以将其所生成的消息传输给消息生产应用程序，由消息生产应用程序实现消息的生产。

其中，unix socket是在socket架构上发展起来的用于同一台主机的进程间通讯，socket是一种独立于协议的网络编程接口，应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。通过unix socket进行通信不需要经过网络协议栈，不需要对消息数据打包拆包、计算校验和、维护序列号应答等，消息数据既不会丢失也不会顺序错乱，只是简单地将应用层数据从一个进程拷贝到另一个进程。

具体地，本申请实施例提供的一种消息处理的方法，包括：

201、接收第二应用程序发送的消息；

在本实施例中，在业务应用程序的正常运行过程中，当业务应用程序生成了需要向其他的网络设备发送的消息时，可以由消息生产应用程序通过unix socket获取到业务应用程序生成的消息。其中，业务应用程序可以包括但不限于游戏相关业务的应用程序、广告相关业务的应用程序、金融相关业务的应用程序、即时通讯相关业务的应用程序以及影音娱乐相关业务的应用程序等具有消息生产需要的应用程序。该消息具体可以是业务请求消息、待上报的指标数据消息或者是响应消息等等，在此并不做具体限定。

202、根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

在本实施例中，在获得第二应用程序发送的消息之后，可以基于消息的类型、消息的发送目的地或者是消息队列中集合中消息队列的空闲状态等信息，在消息队列集合中确定用于处理该消息的目标消息队列。其中，消息队列中包括有多个消息队列，这些消息队列可以是不同类型的消息队列，也可以是相同类型的消息队列，在此不做具体限定。

203、将消息加入至目标消息队列中；

204、根据目标消息队列向第二网络设备发送消息。

在本实施例中，由于业务应用程序生成的消息是有先后顺序的，并且由于业务应用程序与消息生产应用程序之间是通过unix socket通信的，业务应用程序发送至消息生辰应用程序的消息既不会丢失也不会顺序错乱，因此，消息生产应用程序可以根据获取到的消息的先后顺序将消息加入至目标消息队列中，然后根据目标消息队列中消息的排列顺序依次向该消息对应的第二网络设备发送消息。

本申请实施例中，通过在同一个网络设备上部署一个专门用于进行消息生产的应用程序，由该应用程序获取业务应用程序所生成的消息，然后将该消息加入目标消息队列中来进行消息的生产处理，也就是说，将消息生产逻辑通过独立于业务应用程序之外的应用程序来实现，这样便可以使得开发者在开发业务应用程序的过程中只需要开发核心业务逻辑，而不需要再在业务应用程序的基础上开发与业务应用程序耦合的消息生产逻辑，大大地降低了开发者的工作量。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，将消息加入至目标消息队列中之前，方法还包括：确定目标消息队列中的消息数目；若目标消息队列中的消息数目大于或等于阈值，则将消息存储于存储空间中；若目标消息队列中的消息数目小于阈值，则将消息加入至目标消息队列中。

在本实施例中，由于消息生产应用程序将消息加入至目标消息队列中并且在目标消息队列中进行消息的处理是在第一网络设备的内存中进行的，在目标消息队列中的消息量过大的时候，势必会占用大量的内存空间。其中，内存是计算机中重要的部件之一，计算机中所有程序的运行都是在内存中进行的，其作用是用于暂时存放CPU中的运算数据，以及与硬盘等外部存储器交换的数据。只要计算机在运行中，CPU就会把需要运算的数据调到内存中进行运算，当运算完成后CPU再将结果传送出来，内存的运行也决定了计算机的稳定运行。在内存的大量空间被占用时，显然会影响到第一网络设备正在执行的业务进程。

因此，为了保证第一网络设备能够正常执行相应的业务进程，可以为目标消息队列能够容纳的消息数量设置一个阈值，在获取到新的消息时，先确定当前目标消息队列中已有的消息的数量，当目标消息队列中的消息数量达到该阈值的时候，不再往目标消息队列中加入新的消息，而是将新的消息写入至第一网络设备的硬盘等存储空间中(通常也称为“落盘”)；当目标消息队列中的消息数量没有达到该阈值的时候，可以往目标消息队列中加入新的消息。具体地，该阈值可以根据第一网络设备的性能配置(即第一网络设备本身所拥有的的内存容量)以及消息所占的存储容量来确定，在第一网络设备的性能配置较高的情况下(即第一网络设备的内存容量较大时)，阈值可以设置为一个较大的值；当单个消息所占的存储容量普遍较小的时候，阈值也可以设置为一个较大的值；此外，还可以根据不同的时间段来实时调整阈值的大小，在第一网络设备的业务处理压力较小时，可以上调阈值，在第一网络设备的业务处理压力较大时，则可以下调阈值，以保证第一网络设备处理相关业务的速率。

在本实施例中，通过在获取到消息之后，先确定目标消息队列中的消息数目，并且在目标消息队列中的消息数目达到阈值时，将消息写入到硬盘中，避免了第一网络设备的内存中积压有大量的消息，而影响了第一网络设备的正常运行。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，将消息存储于存储空间中之前，方法还包括：获取第三网络设备发送的配置信息；若配置信息中指示对消息进行删除，则删除消息；若配置信息中指示对消息进行存储，则将消息存储于存储空间中。

需要说明的是，在第一网络设备上安装消息生产应用程序时，可以对消息生产应用程序预先进行配置，以使得消息生产应用程序从第一网络设备上启动之后，消息生产应用程序可以自动注册至作为控制端的第三网络设备上，并生成一个唯一的代理ID。第三网络设备可以根据消息生产应用程序对应的代理ID，对部署于不同的网络设备上的消息生产应用程序进行控制。例如，第三网络设备可以向消息生产应用程序下发配置信息，或者对消息生产应用程序上的配置信息进行修改；消息生产应用程序也可以间隔一定的时间通过拉取超文本传输安全协议(hyper text transfer protocol over secure socket layer，https)接口的形式(即通过以安全为目标的http通过)从第三网络设备上获取其最新的配置信息，从而实现其配置的热更新。也就是说，在复杂的现网环境(即面对用户的网络环境)下，运维人员可以根据实际情况灵活地调整相应的配置信息，并且对不同的网络设备上的消息生产应用程序的配置信息进行修改，或者由消息生产应用程序自主获取最新的配置信息来实现配置信息的更改，全程无需对业务应用程序进行修改变动，不会影响业务应用程序的正常运行。

基于此，在本实施例中，可以根据第三网络设备预先定义的配置信息，来确定在目标消息队列中的消息数量达到阈值时，到底是将无法进入目标消息队列中的消息删除，还是将这部分消息写入到存储空间中保存起来。具体地，在确定目标消息队列中的消息数量达到阈值时，获取第三网络设备最新下发的配置信息，根据该配置信息确定无法进入到目标消息队列中的消息的处理方式，如果配置信息指示丢弃该消息，则将该消息进行丢弃操作(即删除该消息)，如果配置信息指示将该消息落盘，则将该消息写入至硬盘空间中。

值得注意的是，该配置信息具体可以是指示所有的无法进入到目标消息队列中的消息，即若配置信息中的指示为若目标消息队列已满时，则将后续的消息进行丢弃，那么，在每次确定得到目标消息队列已满时，都将后续无法进入到目标消息队列中的消息进行丢弃，显然，在这种情况下，只需要读取一次配置信息，便可以确定后续在目标消息队列已满时，对于每个消息的操作。例如，对于一些电商业务中的抢购活动，由于抢购活动限定了可抢购商品的数量，而抢购的人数可能远大于可抢购商品的数量，在这种情况下，可以根据可抢购商品的数量设置目标消息队列可容纳消息的数量，先进入到目标消息队列中的订单消息可以认为是成功抢购到商品的订单信息，而在目标消息队列中消息已满时，后续的订单消息则无法再进入到目标消息队列中，并且后续的这些订单消息可以认为是无效的订单消息，即无法抢购到商品的订单消息，因此，可以将后续的这些订单消息进行丢弃。

此外，该配置信息还可以是根据无法进入到目标消息队列中的消息对应的类型来决定该消息的处理方式，即在配置信息中定义了在消息无法进入到目标消息队列中时，哪一些类型的消息需要写入到硬盘空间中，哪一些类型的消息则可以丢弃；那么，基于该配置信息，对于每一条无法进入到目标消息队列中的消息，都可以先确定该消息的类型，然后根据配置信息中的定义，来确定该消息是要被写入到硬盘空间中还是要被丢弃。这样一来，在目标消息队列已满时，可以对一些较为重要的消息进行落盘，而对于一些不重要的消息则进行丢弃，以保证不影响消息的正常处理的基础上，尽可能地降低第一网络设备的处理资源开销。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，将消息存储于存储空间中之后，方法还包括：确定目标消息队列中的消息数目；若目标消息队列中的消息数目小于阈值，则将存储空间中的消息加入至目标消息队列中。

在本实施例中，在将消息存储于存储空间之后，为了保证这些消息能够正常被发送，可以实时或者定时获取目标消息队列中已存放消息的情况，当目标消息队列中的消息数目小于阈值之后，可以重新将写入到硬盘空间中的消息加入至目标消息队列中，以保证该消息的发送，也就是说，当目标消息队列不再是已满状态时，则从硬盘空间中取出消息，并恢复该消息的发送。可以理解的是，在成功地发送该消息之后，则可以将该消息从硬盘空间中删除，以节省硬盘空间资源。

在本实施例中，通过消息生产应用程序的消息熔断(即在目标消息队列已满时删除后续的消息)、消息落盘(即在目标消息队列已满时将后续的消息写入至硬盘中)以及恢复消息的发送(即将写入至硬盘空间中的消息重新加入至目标消息队列中进行发送)等机制，可以避免消息生产应用程序在通信异常时遭遇消息写入阻塞的情况，最大程序地保障了消息生产应用程序的稳定性。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，根据目标消息队列向第二网络设备发送消息之前，方法还包括：

确定第二网络设备的异常情况；若第二网络设备异常，则向与第二网络设备对应的备用网络设备发送消息；若第二网络设备正常，则向第二网络设备发送消息。

在本实施例中，在一些情况下，第一网络设备上待发送的消息所对应的第二网络设备可能由于设备故障或网络故障等原因而发生了异常，此时，为了保证消息能够被处理，可以将消息发送给接替第二网络设备的备用网络设备，由备用网络设备对后续的消息进行处理。可以理解的是，在大部分的业务场景下，为了避免由于设备故障或网络故障等因素而造成网络设备故障所带来的负面影响，对于大部分的网络设备(例如服务器)来说，均设置由备用网络设备，以在主网络设备异常的情况下，由备用网络设备来继续进行业务的处理。

具体地，在一些业务场景下，第二网络设备可以是一个服务器，即由一个服务器处理第一网络设备所发送的消息；在一些业务场景下，例如在对计算机的处理能力有较高要求，一个计算机可能无法胜任业务处理的场景下，第二网络设备还可以是一个集群，其中，集群指的是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理，以通过多个计算机的协作来完成业务的处理。在第一网络设备与集群相互作用时，集群可以看作是一个独立的服务器。一般来说，为了保证集群的高可用性，通常会设置有主集群和备用集群，主集群主要用于处理正常场景下的业务需求，备用集群则用于在主集群异常的情况下，接替主集群进行业务的处理，以保证业务的正常运行。

其中，第二网络设备可以为主集群，该主集群包括有多个区块链节点服务器，即主集群中的服务器均为区块链上的区块节点设备；第二网络设备对应的备用网络设备为备用集群，该备用集群包括多个区块链节点备用服务器。其中，多个区块链节点服务器和多个区块链节点备用服务器均可以接入到同一个区块链上，通过将构成主集群和备用集群的服务器接入到区块链中，能够有效地利用区块链的去中心化以及数据不可篡改的特性，保证了在主集群和备用集群上存储消息的可靠性。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，该方法还包括：获取第三网络设备发送的配置信息；根据配置信息确定目标消息队列的类型；根据目标消息队列的类型确定目标消息队列。

可以理解的是，在不同的业务场景下，对于目标消息队列的需求可能会存在有较大的差异，例如，在一些业务场景下，可以需要使用到偏向于吞吐性能的开源消息队列kafka或者pulsar，在一些业务场景下，则可能需要使用到可靠性较高的消息队列hippo，在一些业务场景下，则可能需要用到稳定性和可靠性较高的消息队列RabbitMQ。

因此，在本实施例中，为了便于运维人员的管理，可以在消息生产应用程序中预置有多种消息类型，在实际应用时，可以根据消息生产应用程序所服务的业务应用程序的需求，通过下发相应的配置信息来决定消息生产应用程序在处理消息时所采用的目标消息队列。这样一来，对于执行不同业务的网络设备，运维人员可以在这些网络设备上统一安装上相同的消息生产应用程序，然后在对这些网络设备进行控制管理的过程中，根据网络设备所执行的业务的需求下发不同的配置信息，以使得不同的网络设备中的消息生产应用程序能够根据网络设备中所执行的业务的实际需求选择对应的目标消息队列来进行消息的处理。具体地，下发给消息生产应用程序的配置信息中所包括的目标消息队列的类型包括但不限于kafka、pulsar、hippo和RabbitMQ中的一种或者多种。

值得注意的是，对于同一个网络设备中的业务应用程序，该业务应用程序可能生成有不同类型的消息，这些不同类型的消息可能需要采用不同的目标消息队列来进行处理，基于此，在下发给同一个消息生产应用程序的配置信息中也可以包括有多种目标消息队列的类型，该配置信息中指示有不同的目标消息队列的类型所对应的消息，在实际应用中，消息生产应用程序可以根据当前业务应用程序所生成的消息的类型来确定对应的目标消息队列，从而实现目标消息队列的灵活调整，保障消息的高效处理。

具体地，如图3所示，图3为本申请实施例提供的一种目标消息队列的选择示例图。图3中，在第一网络设备上部署有业务应用程序和消息生产应用程序，消息生产应用程序以边车模式进行部署，且消息生产应用程序与业务应用程序之间建立有通信连接；第一网络设备与第三网络设备之间也建立有通信连接，第三网络设备上的控制模块可以生成配置信息，并且将该配置信息下发给第一网络设备中的消息生产应用程序。具体地，在业务应用程序生成消息之后，业务应用程序将该消息发送给消息生产应用程序，消息生产应用程序在获得该消息之后，根据第三网络设备所下发的配置信息确定用于处理该消息的消息处理，然后再将该消息加入至对应的目标消息队列中，其中，目标消息队列的类型包括有kafka、pulsar和hippo等等，最后，消息生产应用程序在目标消息队列中对消息进行处理后，将该消息发送给第二网络设备，完成消息的传输。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，根据目标消息队列向第二网络设备发送消息之前，方法还包括：获取第三网络设备发送的配置信息；根据配置信息确定消息的编码方式和加密方式；根据编码方式和加密方式对消息进行编码和加密，得到处理后的消息；向第二网络设备发送处理后的消息。

可以理解的是，在消息的传输过程中，为了保证消息传输的可靠性以及安全性，通常会对消息进行编码以及加密。同样地，在不同的业务场景下，对消息进行编码的方式以及加密的方式也可能是不一样的。因此，在本实施例中，针对于不同的业务应用程序，可以向相应的消息生产应用程序下发与之配合的配置信息，以使得消息生产应用程序根据配置信息确定消息的编码方式以及加密方式，并且在对消息进行处理时，采用所确定的编码方式和加密方式来对消息进行编码以及加密。其中，对消息进行编码以及加密均为现有常见的技术，在此不再赘述。

可以理解的是，在本实施例中，运维人员还可以通过下发配置信息至消息生产应用程序来实现负载均衡、流量控制、重试逻辑以及安全加密等消息生产逻辑以及通过修改下发的配置信息来完成消息生产逻辑的实时更新。

可选地，在上述图2对应的一个实施例的基础上，本申请实施例提供的消息处理的方法一个可选实施例中，该方法还包括：根据消息和目标消息队列确定消息生产指标信息，消息生产指标信息包括消息接收速率、消息生产速率和队列消息数目中的一种或几种；向第三网络设备发送消息生产指标信息，以使得第三网络设备根据消息生产指标信息生成告警信息。

在本实施例中，为了保证消息生产的正常进行，在消息生产的过程中，可以由消息生产应用程序根据当前消息生产的情况，对消息进行简单的统计，例如对一定时间内所接收的消息数量进行统计，得到消息接收速率，即单位时间内从业务应用程序所接收的消息的数量；或者对一定时间内所生产(处理)的消息数量进行统计，得到消息生产速率，即单位时间内成功发送的消息的数量；或者对一定时间内目标消息队列中消息数量的变化情况进行统计，得到不同时间下的队列消息数目。在统计得到一定时间内的消息生产指标信息之后，可以定期向作为控制端的第三网络设备上报消息生产指标信息，以使得第三网络设备能够对消息生产应用程序的消息生产情况进行监控。

具体地，如图4所示，图4为本申请实施例提供的一种消息生产指标上报的示例图。在第一网络设备上，部署有业务应用程序和消息生产应用程序，消息生产应用程序可以从业务应用程序中获取到消息，并且对消息进行生产处理。此外，第三网络设备上的控制模块可以向消息生产应用程序下发配置信息，该配置信息用于指示消息生产应用程序通过统计的方式获取相应的消息生产指标(例如消息接收速率、消息生产速率或队列消息数目等)，然后消息生产应用程序在根据配置信息的指示统计得到相应的消息生产指标之后，定期向第三网络设备上报消息生产指标；第三网络设备上的指标统计模块可以根据消息生产应用程序所上报的消息生产指标进行自动统计，并且生成可视化的报表，以供运维人员进行统计和分析。此外，第三网络设备上的告警模块还可以基于指标统计模块统计得到的结果，自动生成告警信息，包括消息生产速率过快或者消息掉零(即一段时间内(比如五分钟内)没有生产消息)等等，以提示运维人员及时处理异常情况。

请参阅图5和图6，图5为本申请实施例提供的一种展示统计报表的示例图；图6为本申请实施例提供的一种告警信息的界面示例图。图5中，第三网络设备上的指标统计模块可以根据消息生产应用程序所上报的消息生产指标进行自动统计，并且生成了可视化的报表，该报表中形成了多个指标对应的折线图，分别包括有接收消息量、主队列消息量、从队列消息量、接收异常消息量以及写入硬盘消息量等，运维人员在通过第三网络设备查看报表时，可以从上述的多个指标中进行切换，以查看各个指标对应的折线图。在图5中，显示的是接收消息量对应的折线图，该折线图中展示了在不同的时间下所接收的消息量的变化情况，由图可以看出，从0点到4点的时间段内，接收消息量是递减的，而从4点到10点的时间段内，接收消息量则是递增的；此外，运维人员还可以通过选择折线图上的某一个点来查看具体某一时刻下的接收消息量。如图6所示，图6表示的是在统计得到消息生产速率超过预设的速率时，在第三网络设备进行实时报警的界面显示。其中，运维人员可以在界面的左侧选择相应的消息指标参数进行查看，例如消息生产速率、消息处理速率、队列消息数目、历史报警信息等，而在某一指标参数的超过预设的指标值时，则在界面的正中央进行突出显示，以提醒运维人员及时查看相关信息。

为了便于理解，以下将结合具体例子对本申请实施例提供的消息处理的方法进行详细的介绍。如图7所示，图7为本申请实施例提供的一种消息处理的方法的流程示例图，图7中所提供的消息处理的方法具体如下：

S1、由消息生产应用程序从业务应用程序中获取待处理的消息；

S2、消息生产应用程序检测消息队列是否已满，即检测消息队列中的消息数量是否已经达到预先设定的阈值；

S3、如果消息队列未满，即消息队列中的消息数量还没有达到预先设定的阈值，则将消息加入至消息队列中进行处理；

S4、如果消息队列已满，即消息队列中的消息数量已经达到预先设定的阈值，则根据下发的配置信息判断是否需要丢弃该消息；

S5、如果根据配置信息得到不需要丢弃该消息，则将消息进行落盘，即将该消息写入至硬盘中；

S6、如果根据配置信息得到需要丢弃该消息，则将该消息丢弃，即删除该消息；

S7、在消息进入消息队列之后，判断用于接收该消息的主集群是否正常；

S8、如果主集群正常，则将该消息发送至主集群，完成消息的生产处理；

S9、如果主集群不正常，则可以根据配置信息确定与主集群对应的备用集群，并且将该消息发送至备用集群，完成消息的生产处理；

S10、在消息生产应用程序对消息进行处理的过程中，对消息相关的一些指标进行统计(例如消息接收速率、消息生产速率和队列消息数目等等)，并且间隔一定的周期向作为控制端的网络设备上报其统计的指标信息。

其中，本申请实施例中下发至第一网络设备的配置信息(符号“#”后面的信息为对相关配置信息的注释)具体可以如下所示：

以上为对本申请实施例提供的一种消息处理的方法所进行的介绍，以下将对本申请实施例提供的一种消息处理的装置进行详细的介绍。请参阅图8，图8为本申请实施例提供的一种消息处理的装置的结构示意图。

本申请实施例提供了一种消息处理的装置80，该消息处理的装置80应用于第一应用程序，第一应用程序部署于第一网络设备，第一网络设备部署还部署有第二应用程序，第一应用程序与第二应用程序之间建立有通信连接，该消息处理的装置80包括：

接收单元801，用于接收第二应用程序发送的消息；

确定单元802，用于根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

加入单元803，用于将消息加入至目标消息队列中；

发送单元804，用于根据目标消息队列向第二网络设备发送消息。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，还包括存储单元805；

确定单元802，用于确定目标消息队列中的消息数目；

存储单元805，用于若目标消息队列中的消息数目大于或等于阈值，则将消息存储于存储空间中；

加入单元803，还用于若目标消息队列中的消息数目小于阈值，则将消息加入至目标消息队列中。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，还包括获取单元806和删除单元807；

获取单元806，用于获取第三网络设备发送的配置信息；

删除单元807，用于若配置信息中指示对消息进行删除，则删除消息；

存储单元805，还用于若配置信息中指示对消息进行存储，则将消息存储于存储空间中。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，

确定单元802，还用于确定目标消息队列中的消息数目；

加入单元803，还用于若目标消息队列中的消息数目小于阈值，则将存储空间中的消息加入至目标消息队列中。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，

确定单元802，还用于确定第二网络设备的异常情况；

发送单元804，还用于若第二网络设备异常，则向与第二网络设备对应的备用网络设备发送消息；

发送单元804，还用于若第二网络设备正常，则向第二网络设备发送消息。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，

获取单元806，还用于获取第三网络设备发送的配置信息；

确定单元802，还用于根据配置信息确定目标消息队列的类型；

确定单元802，还用于根据目标消息队列的类型确定目标消息队列。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，还包括处理单元808；

获取单元806，还用于获取第三网络设备发送的配置信息；

确定单元802，还用于根据配置信息确定消息的编码方式和加密方式；

处理单元808，用于根据编码方式和加密方式对消息进行编码和加密，得到处理后的消息；

发送单元804，还用于向第二网络设备发送处理后的消息。

可选地，在图8对应的实施例的基础上，本申请实施例提供的消息处理的装置80的另一实施例中，

确定单元802，还用于根据消息和目标消息队列确定消息生产指标信息，消息生产指标信息包括消息接收速率、消息生产速率和队列消息数目中的一种或几种；

发送单元804，还用于向第三网络设备发送消息生产指标信息，以使得第三网络设备根据消息生产指标信息生成告警信息。

图9为本申请实施例提供的一种网络设备结构示意图，该网络设备900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对网络设备中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在网络设备900上执行存储介质930中的一系列指令操作。

网络设备900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

在本申请实施例中，该网络设备900部署有第一应用程序以及第二应用程序，该网络设备900所包括的CPU 922还具有以下功能：

通过第一应用程序接收第二应用程序发送的消息；

通过第一应用程序根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

通过第一应用程序将消息加入至目标消息队列中；

通过第一应用程序根据目标消息队列向第二网络设备发送消息。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种消息处理的方法，其特征在于，所述方法应用于第一网络设备，所述第一网络设备部署有第一应用程序以及第二应用程序，所述第一应用程序与所述第二应用程序之间建立有通信连接，所述方法应用于所述第一应用程序，所述方法包括：

接收所述第二应用程序发送的消息；

根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

将所述消息加入至所述目标消息队列中；

根据所述目标消息队列向第二网络设备发送所述消息。

2.根据权利要求1所述的消息处理的方法，其特征在于，所述将所述消息加入至目标消息队列中之前，所述方法还包括：

确定所述目标消息队列中的消息数目；

若所述目标消息队列中的消息数目大于或等于阈值，则将所述消息存储于存储空间中；

若所述目标消息队列中的消息数目小于所述阈值，则将所述消息加入至所述目标消息队列中。

3.根据权利要求2所述的消息处理的方法，其特征在于，所述将所述消息存储于存储空间中之前，所述方法还包括：

获取第三网络设备发送的配置信息；

若所述配置信息中指示对所述消息进行删除，则删除所述消息；

若所述配置信息中指示对所述消息进行存储，则将所述消息存储于所述存储空间中。

4.根据权利要求2或3所述的消息处理的方法，其特征在于，所述将所述消息存储于存储空间中之后，所述方法还包括：

确定所述目标消息队列中的消息数目；

若所述目标消息队列中的消息数目小于所述阈值，则将所述存储空间中的所述消息加入至所述目标消息队列中。

5.根据权利要求1所述的消息处理的方法，其特征在于，所述根据所述目标消息队列向第二网络设备发送所述消息之前，所述方法还包括：

确定所述第二网络设备的异常情况；

若所述第二网络设备异常，则向与所述第二网络设备对应的备用网络设备发送所述消息；

若所述第二网络设备正常，则向所述第二网络设备发送所述消息。

6.根据权利要求1所述的消息处理的方法，其特征在于，所述根据所述目标消息队列向第二网络设备发送所述消息之前，所述方法还包括：

获取第三网络设备发送的配置信息；

根据所述配置信息确定所述目标消息队列的类型；

根据所述目标消息队列的类型确定所述目标消息队列。

7.根据权利要求1所述的消息处理的方法，其特征在于，所述根据所述目标消息队列向第二网络设备发送所述消息之前，所述方法还包括：

获取第三网络设备发送的配置信息；

根据所述配置信息确定所述消息的编码方式和加密方式；

根据所述编码方式和所述加密方式对所述消息进行编码和加密，得到处理后的消息；

向所述第二网络设备发送所述处理后的消息。

8.根据权利要求1所述的消息处理的方法，其特征在于，所述方法还包括：根据所述消息和所述目标消息队列确定消息生产指标信息，所述消息生产指标信息包括消息接收速率、消息生产速率和队列消息数目中的一种或几种；

向所述第三网络设备发送所述消息生产指标信息，以使得所述第三网络设备根据所述消息生产指标信息生成告警信息。

9.根据权利要求5所述的消息处理的方法，其特征在于，所述第二网络设备为主集群，所述主集群包括多个区块链节点服务器；

所述备用网络设备为备用集群，所述备用集群包括多个区块链节点备用服务器。

10.一种消息处理的装置，其特征在于，所述消息处理的装置应用于第一应用程序，所述第一应用程序部署于第一网络设备，所述第一网络设备部署还部署有第二应用程序，所述第一应用程序与所述第二应用程序之间建立有通信连接，所述消息处理的装置包括：

接收单元，用于接收所述第二应用程序发送的消息；

确定单元，用于根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

加入单元，用于将所述消息加入至目标消息队列中；

发送单元，用于根据所述目标消息队列向第二网络设备发送所述消息。

11.一种网络设备，其特征在于，所述网络设备部署有第一应用程序以及第二应用程序，所述网络设备包括：存储器、收发器、处理器以及总线系统；

其中，所述存储器用于存储所述第一应用程序和所述第二应用程序，所述第一应用程序和所述第二程序之间建立有通信连接；

所述处理器用于执行所述存储器中的第一程序，包括如下步骤：

通过所述第一应用程序接收所述第二应用程序发送的消息；

通过所述第一应用程序根据所述消息在消息队列集合中确定目标消息队列，所述消息队列集合包括多个消息队列，所述目标消息队列属于所述消息队列集合；

通过所述第一应用程序将所述消息加入至目标消息队列中；通过所述第一应用程序根据所述目标消息队列向第二网络设备发送所述消息；

所述总线系统用于连接所述存储器以及所述处理器，以使所述存储器以及所述处理器进行通信。

12.一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至9中任一项所述的方法。