CN110309002A - 消息处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开是关于一种消息处理方法、装置、电子设备及存储介质，该消息处理方法包括：中间层接收业务消息；中间层识别业务消息的目标消息类型；中间层根据预存的消息类型与业务模块之间的对应关系，查找与目标消息类型对应的目标业务模块；中间层通过预设消息处理接口，将业务消息发送至目标业务模块，以使目标业务模块处理业务消息。本公开的中间层设置有统一的预设消息处理接口，不需要关心业务模块对消息处理的业务逻辑，降低了中间层与业务模块的耦合度，易于中间层的后续扩展维护。

Description

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

技术领域

本公开涉及互联网技术领域，尤其涉及一种消息处理方法、装置、电子设备及存储介质。

背景技术

随着互联网技术的不断发展，应用程序(APP，Application)的功能也越来越丰富。因此，一款APP往往分为多个业务模块，每个业务模块都会产生业务消息。

目前，应用程序在处理业务消息时，主要是通过在应用程序的业务层中设置统一的中间层，该中间层耦合与各个业务模块，并负责处理各个业务模块与服务端之间的交互；此外，该中间层还负责集中处理各个业务模块的业务消息。

显然，上述技术方案会使中间层承载过多的业务逻辑，造成中间层与业务模块耦合严重的问题。那么后续如果业务模块存在修改调整，或者接入新的业务模块，都需要对中间层进行修改，大幅提高了中间层的扩展难度和维护难度。

因此，相关技术的业务消息的处理方案普遍存在着中间层与业务层耦合严重的问题。

公开内容

本公开提供一种消息处理方法、装置、电子设备及存储介质，以至少解决相关技术中业务消息的处理方案所存在的中间层与业务层耦合严重的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种消息处理方法，应用于包括中间层和业务模块的客户端，所述方法包括：

所述中间层接收业务消息；

所述中间层识别所述业务消息的目标消息类型；

所述中间层根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；

所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

在一种可能的实施方式中，所述中间层根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块之前，所述消息处理方法还包括：

所述中间层通过预设注册接口，接收所述业务模块的注册请求，其中，所述注册请求包括所述业务模块的标识信息、所述业务模块请求处理的消息的消息类型；

所述中间层根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系。

在一种可能的实施方式中，所述中间层根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系之后，所述消息处理方法还包括：

按照注册时间从早到晚的顺序，依次保存所述消息类型与所述业务模块之间的多组对应关系；

所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息，包括：

若所述目标业务模块的数量为多个，则所述中间层按照多个所述目标业务模块对所述目标消息类型的所述注册时间从早到晚的顺序，通过预设消息处理接口，将所述业务消息依次发送给多个所述目标业务模块，以使多个所述目标业务模块分别处理所述业务消息。

在一种可能的实施方式中，所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息之前，所述消息处理方法还包括：

所述中间层判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码；

若所述目标业务模块配置有实现所述预设消息处理接口的消息处理代码，则所述中间层判断所述消息处理代码是否包括与所述目标消息类型对应的目标消息处理代码；

若所述消息处理代码包括与所述目标消息类型对应的目标消息处理代码，则所述中间层执行所述通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息的步骤；

若所述目标业务模块未配置有实现所述预设消息处理接口的消息处理代码，或，若所述消息处理代码不包括与所述目标消息类型对应的目标消息处理代码，则所述中间件将所述对应关系中所述目标消息类型与所述目标业务模块之间的对应关系删除。

在一种可能的实施方式中，所述预设消息处理接口包括消息属性字段，所述业务消息携带有消息属性信息，所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息，包括：

所述中间层调用由所述目标业务模块实现的预设消息处理接口，并将所述消息属性信息传递至所述预设消息处理接口；

所述目标业务模块从所述预设消息处理接口获取所述消息属性信息；

所述目标业务模块根据所述消息属性信息，识别所述业务消息的所述目标消息类型；

所述目标业务模块从预先配置的实现所述预设消息处理接口的消息处理代码中，获取与所述目标消息类型对应的目标消息处理代码；

所述目标业务模块利用所述消息属性信息，按照所述目标消息处理代码，对所述业务消息进行处理。

在一种可能的实施方式中，所述中间层根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块之前，所述消息处理方法还包括：

所述中间层判断所述业务消息是否合法；

若所述中间层判定所述业务消息合法，则所述中间层执行所述根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块的步骤。

根据本公开实施例的第二方面，提供一种消息处理装置，应用于客户端，所述消息处理装置包括：

第一接收模块，被配置为执行接收业务消息；

识别模块，被配置为执行识别所述业务消息的目标消息类型；

查找模块，被配置为执行根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；

发送模块，被配置为执行通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

在一种可能的实施方式中，所述消息处理装置还包括：

第二接收模块，被配置为执行通过预设注册接口，接收所述业务模块的注册请求，其中，所述注册请求包括所述业务模块的标识信息、所述业务模块请求处理的消息的消息类型；

生成模块，被配置为执行根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系。

在一种可能的实施方式中，所述消息处理装置还包括：

保存模块，被配置为执行按照注册时间从早到晚的顺序，依次保存所述消息类型与所述业务模块之间的多组对应关系；

所述发送模块，还被配置为执行若所述目标业务模块的数量为多个，则按照多个所述目标业务模块对所述目标消息类型的所述注册时间从早到晚的顺序，通过预设消息处理接口，将所述业务消息依次发送给多个所述目标业务模块，以使多个所述目标业务模块分别处理所述业务消息。

在一种可能的实施方式中，所述消息处理装置还包括：

第一判断模块，被配置为执行判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码；

第二判断模块，被配置为执行若所述目标业务模块配置有实现所述预设消息处理接口的消息处理代码，则判断所述消息处理代码是否包括与所述目标消息类型对应的目标消息处理代码；

所述发送模块，还被配置为执行若所述消息处理代码包括与所述目标消息类型对应的目标消息处理代码，则通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息；

删除模块，被配置为执行若所述目标业务模块未配置有实现所述预设消息处理接口的消息处理代码，或，若所述消息处理代码不包括与所述目标消息类型对应的目标消息处理代码，则将所述对应关系中所述目标消息类型与所述目标业务模块之间的对应关系删除。

在一种可能的实施方式中，所述预设消息处理接口包括消息属性字段，所述业务消息携带有消息属性信息，所述发送模块包括：

调用子模块，被配置为执行调用由所述目标业务模块实现的预设消息处理接口，并将所述消息属性信息传递至所述预设消息处理接口；

第一获取子模块，被配置为执行从所述预设消息处理接口获取所述消息属性信息；

识别子模块，被配置为执行根据所述消息属性信息，识别所述业务消息的所述目标消息类型；

第二获取子模块，被配置为执行从预先配置的实现所述预设消息处理接口的消息处理代码中，获取与所述目标消息类型对应的目标消息处理代码；

处理子模块，被配置为执行利用所述消息属性信息，按照所述目标消息处理代码，对所述业务消息进行处理。

在一种可能的实施方式中，所述消息处理装置还包括：

第三判断模块，被配置为执行判断所述业务消息是否合法；

所述查找模块，还被配置为执行若判定所述业务消息合法，则根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块。

根据本公开实施例的第三方面，提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现上述任一项所述的消息处理方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如上述任一项所述的消息处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包含可读程序代码，当所述可读程序代码在计算设备上运行是，可使所述计算设备执行上述任意一种实施方式中所述的消息处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

这样，本公开实施例通过中间层设置有统一的预设消息处理接口，以及保存消息类型和消息处理者之间的对应关系，那么通过该预设消息处理接口和该对应关系，就可以将接收到的消息分发给指定的消息处理者，即目标业务模块。其中，中间层不需要关心业务模块对消息处理的业务逻辑，降低了中间层与业务模块的耦合度，易于中间层的后续扩展维护。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种客户端的结构框图；

图2是根据一示例性实施例示出的一种客户端与服务端之间的交互示意图；

图3是根据一示例性实施例示出的一种消息处理方法的流程图；

图4是根据一示例性实施例示出的客户端与服务端之间的交互示意图；

图5是根据一示例性实施例示出的一种消息处理方法的流程图；

图6是根据一示例性实施例示出的一种消息处理方法的流程图；

图7是根据一示例性实施例示出的一种消息处理装置的结构框图；

图8是根据一示例性实施例示出的一种用于消息处理的装置800的框图；

图9是根据一示例性实施例示出的一种用于消息处理的装置1900的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1示出了本公开一个实施例的客户端的结构框图。

如图1所示，客户端从上到下依次包括业务层(这里示出了业务A模块、业务B模块、业务C模块)、中间层、以及位于中间层下层的网络层和基础服务层(包括但不限于存储层、基础工具层等)，其中，网络层和基础服务层属于同一层级。

其中，中间层负责对各个业务模块的业务消息进行统一管理，以及对从接收自服务端的业务消息，向各个业务模块进行分发，以使业务模块处理业务消息。

由于业务消息可以是供客户端提示用户的红点消息(即提示消息)，也可以是非提示消息，而中间层处理的业务消息可以包括红点消息和非红点消息，当处理的消息为红点消息时，则该中间层可以实施为红点服务层，当处理的消息为非红点消息，则该中间层可以实施为非红点服务层。那么为了便于理解，后文以中间层为红点服务层为例来对红点消息的处理过程进行详细阐述。

具体的，所述中间层可以接收业务消息；识别所述业务消息的目标消息类型根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

以中间层为红点服务层为例，继续参照图2，图2示出了本公开实施例的客户端与服务端之间的交互示意图。

客户端的不同业务模块在与服务端的业务模块交互时，借助于服务端的红点服务层和客户端的红点服务层，来实现客户端与服务端的业务模块之间的交互。

本公开实施例通过在客户端和服务端分别增加红点消息服务层，从而使得客户端与服务端通过两个红点服务层建立长连接，从而使得一次连接可以保持客户端与服务端的长期通信，而不需要客户端与服务端之间建立多个连接，从而解决客户端的业务模块与服务端的业务模块直接通信，所导致的网络连接开销过大的问题。并且，客户端与服务端之间使用同一套红点服务层的接口进行通信，可以解决客户端的业务模块与服务端的业务模块直接通信多导致的接口爆炸的问题。

本公开实施例通过在客户端设置独立与业务层的红点消息服务层，该红点消息服务层可以对客户端的业务消息进行管理以及对接收自服务端的业务消息向各个业务模块进行分发，降低了客户端的红点服务层与业务层之间的耦合度，并实现了对各个业务模块的业务消息的统一管理，减少了逻辑冗余。

图3是根据一示例性实施例示出的一种消息处理方法的流程图，如图3所示，所述消息处理方法可以用于如图1和图2所示的客户端，该客户端包括业务模块以及中间层，其中，客户端的红点服务层是所述中间层的一种实现方式。下面结合图1和图2，来对本公开实施例的客户端的消息处理方法进行详细阐述，该方法可以包括以下步骤：

步骤101，中间层接收业务消息；

其中，中间层可以从服务端接收到业务消息，该业务消息可以是供客户端提示用户的红点消息(即提示消息)，也可以是由客户端的业务模块进行处理的非提示消息，后文以红点消息为例，来对本公开实施例的消息处理方法进行详细阐述，当然，当业务消息为非红点消息时，该消息处理方法的流程也是类似的，因此不再一一赘述。

图4以图2中的业务模块A为例，示出了本公开实施例的客户端与服务端之间的交互示意图。

如图4所示，服务端的业务模块A检测到需要提示给用户的消息后，可以将红点消息(即图4示出的新消息1、新消息2)通过服务端的红点服务层，将消息1和消息2推送至客户端的中间层(这里为客户端的红点服务层)。这样，中间层就接收到了业务消息，后文以消息1为例进行说明。

步骤102，所述中间层识别所述业务消息的目标消息类型；

示例地，客户端的红点服务层接收到消息1后，可以识别该消息1的消息类型。

其中，该消息1携带了消息属性信息，例如包括但不限于消息类型、消息数量，在一种可能的实施方式中，还可以包括消息内容。

由于消息1为红点消息，客户端只需要对该红点消息进行提示，因此，该红点消息可以不携带消息内容，只携带需要提醒的消息数量，以及被提醒的消息的消息的类型。

示例地，红点消息可以为存在数据更新的、且需要用户看到的消息，针对这类消息，需要提示给用户，例如以红点的方式进行提示，或者以消息数量的图标的方式进行提示等等。

由于各个业务模块所处理的消息的类型不同，因此，为了实现中间层对接收到的该消息1的准确分发，这里中间层需要识别消息1的消息类型。

步骤103，所述中间层根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；

示例性地，在客户端启动后，可以生成消息类型与业务模块之间的对应关系，该对应关系可以是一个注册表，该注册表可以包括一对一、多对一、一对多、多对多等任意一种或几种对应关系。也就是说，一个业务模块可以处理一种或多种消息类型，一种消息类型的消息也可以由一个或多个业务模块分别进行独立处理。

那么本步骤中，就可以根据该注册表，来查找对应该消息1的消息类型的目标业务模块，其中该目标业务模块可以是一个或多个。

步骤107，所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

在一种可能的实施方式中，所述预设消息处理接口可以定义消息属性字段(例如消息类型、消息数量、消息内容等)，在一种可能的实施方式中，还可以定义空的消息处理方法。

由于该预设消息处理接口为一个接口，因此，其内部定义的方法没有实现，而是由各个业务模块配置了对该消息处理方法的实现代码。

这样，各个业务模块可以根据自身的业务需求，来灵活配置各自对具有相应消息属性的消息处理的业务逻辑，而中间层并不需要包括对消息的处理逻辑，只需要调用该预设消息处理接口，即可分发业务消息给目标业务模块，并由目标业务模块对该业务消息进行处理，使得中间层不包含业务逻辑，降低了中间层与业务层的耦合度。

图4中，中间层通过查注册表可知，消息1和消息2的消息类型对应的消息处理者均为业务模块A，则可以通过预设消息处理接口将消息1和消息2均分发给客户端的业务模块A进行处理，客户端的业务模块A可以按照预先配置的处理逻辑，来对两个消息分别进行独立的处理。

需要说明的是，本例中，服务端的业务模块A分发的消息，传递给客户端的业务模块A进行处理为例进行的说明，但是同一个业务消息的消息来源者和消息处理者并不一定是相同业务的模块，也就是说，服务端的业务模块A分发的业务消息，可以由客户端的除业务模块A之外的其他业务模块进行处理，并非一定为业务模块A进行处理，具体由客户端的哪个业务模块进行处理，取决于客户端的哪个业务模块在注册表中注册了对相应消息类型的对应关系。

这样，本公开实施例通过中间层设置有统一的预设消息处理接口，以及保存消息类型和消息处理者之间的对应关系，那么通过该预设消息处理接口和该对应关系，就可以将接收到的消息分发给指定的消息处理者，即目标业务模块。其中，中间层不需要关心业务模块对消息处理的业务逻辑，降低了中间层与业务模块的耦合度，易于中间层的后续扩展维护。

此外，由于客户端的各个业务模块通过统一的接口，即预设消息处理接口，来与服务端进行通信，从而可以避免各个业务模块单独与服务端的各个业务模块进行通信所导致的接口爆炸的问题，大幅降低了通信接口数量，且减少了逻辑冗余，降低了维护成本；另外，客户端的各个业务模块无需与服务端的各个业务模块进行分别建立通信连接，而客户端的各个业务模块只需要与客户端的中间层建立通信连接，从而避免了客户端与服务端的连接过多，连接开销过大的问题，降低了网络连接的开销。

在一种可能的实施方式中，在步骤103之前，根据本公开实施例的消息处理方法还可以包括：

S201，所述中间层通过预设注册接口，接收所述业务模块的注册请求，其中，所述注册请求包括所述业务模块的标识信息、所述业务模块请求处理的消息的消息类型；

在一种可能的实施方式中，用于处理业务消息的各个业务模块可以预先配置实现所述预设消息处理接口的消息处理代码，那么实现了该预设消息处理接口的各个业务模块，就可以对其所注册的消息类型的业务消息进行处理，并且在进行处理时，是按照其配置的消息处理代码进行处理的。

对于各个业务模块向中间层发起注册请求的时机而言，可以是在客户端启动后、也可以是在业务模块被加载完成之后，具体的时机取决于各个业务模块，该时机可以根据不同的应用场景进行灵活配置，本公开对此不做限制。也因为注册时机的不同，所以，S201可以在步骤101之前执行，也可以在步骤101之后执行，或者同时执行，本公开对于S201与步骤101之间的执行顺序不做限制。但是，需要注意的是，在执行步骤101时，中间层已经生成了所述注册表，只要该注册表中存在一个对应关系，就可以执行步骤101，而在中间层从服务端接收业务消息的过程中，各个业务模块也可以向中间层进行注册，即发起注册请求。

这里以该发起注册请求的时机为客户端启动后为例进行说明，在客户端启动运行起来后，以图4为例，客户端的业务模块A可以通过预设注册接口，来向客户端的红点服务层发出注册请求，其中，所述注册请求可以包括所述业务模块A的标识信息、所述业务模块A请求处理的消息的消息类型。

由于一个业务模块可以处理一种或多种消息类型的消息，因此，该注册请求中的消息类型可以是一个或多个。

S202，所述中间层根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系。

例如业务模块A的注册请求包括消息类型1和消息类型2、ID1，则可以生成ID1与消息类型1和消息类型2的对应关系；

例如生成如表1所示的注册表：

业务模块ID	消息类型
		ID1	消息类型1、消息类型2

表1

该对应关系在图3实施例中已经详细描述，这里不再赘述。

本公开实施例中，客户端侧的业务模块只需要向中间层发起对其所处理的消息类型的注册请求，本公开实施例的中间层就可以根据该注册请求，生成各个消息类型与其处理者之间的对应关系，使得中间层能够利用该对应关系，来对接收自服务端的业务消息进行统一管理，且在分发业务消息时，不需要设置与业务相关的逻辑代码，只需要查找该对应关系，就可以实现对业务消息的准确分发，使得中间层既实现了对业务消息的统一管理，又避免了与业务模块的耦合。本公开实施例的中间层与业务层之间的交互(例如业务消息的注册、业务消息的分发)依赖接口的方式，实现了服务层与业务模块的解耦。

需要说明的是，在客户端运行期间，业务模块对一个消息类型的消息发起过注册请求后，就无需再重复注册，当其需要对新的消息类型进行注册时，再发起注册请求即可；

在一种可能的实施方式中，该注册表(即上述对应关系)可以保存在内存中，因此，当客户端关闭之后，该内存中的注册表会被清空，所以，待客户端再次运行后，各个业务模块需要重新发起注册请求，即便在上一次的客户端运行期间，该业务模块已经向中间层发起过注册请求。

通过将注册表保存在内存中，可以减少对存储空间的占用，且中间层对注册表的查表过程的逻辑也更加简单，无需读取存储空间；此外，随着客户端的不断更新和修补，客户端的各个业务模块的功能会存在变化，且来自服务端的业务消息也是不断变化的，因此，如果将该注册表保存在本地存储空间中，为了避免无效数据对存储空间的长期占用，还需要设置哪个消息类型的对应关系的过期时间，从而对过期的对应关系进行及时清理，这将徒增中间层很多的处理逻辑，从而降低系统性能，因此，本公开实施例的方法，可以将该注册表保存在内存中，以避免上述问题。

在一种可能的实施方式中，S202之后，根据本公开实施例的方法还可以包括：

S203，按照注册时间从早到晚的顺序，依次保存所述消息类型与所述业务模块之间的多组对应关系。

如图2所示，由于客户端的业务模块不止一个，且一个业务模块如果能够处理多种消息类型的消息，则同一个业务模块，也可以发起多次注册请求，因此，为了对各个注册请求对应的消息类型与业务模块之间的对应关系进行独立存储，可以按照接收到的注册请求的时间(即注册时间)从早到晚的顺序，来依次保存多组对应关系。

举例来说，客户端在接收到业务模块A的注册请求之后，又依次接收到了业务模块B和业务模块C的注册请求，其中，业务模块A的注册请求如上述举例所述，这里不再赘述，业务模块B的注册请求包括ID2、消息类型1、消息类型3；业务模块C的注册请求包括ID3、消息类型2、消息类型4；

那么上述表1所述的注册表中已经存储了业务模块A的注册记录，这里需要按照注册时间从早到晚的顺序，继续向注册表中增加记录，且后增加的记录需要存储在注册时间较早的记录之后，从而得到如表2所示的注册表：

业务模块ID	消息类型
		ID1	消息类型1、消息类型2
ID2	消息类型1、消息类型3
		ID3	消息类型2、消息类型4

表2

注册表的结构并不限于表1和表2所示的举例，即按照注册时间从早到晚的顺序依次存储各个对应关系；

在一种可能的实施方式中，S202之后，根据本公开实施例的方法还可以包括：

S204，对所述对应关系对应的注册时间进行保存；

例如，注册表中的键值还可以是消息类型。

其中，如表2所示的注册表中还可以增加注册时间的字段，从而使得中间层通过查询该注册表中的注册时间的信息，可以得知各个对应关系的注册时间顺序。

其中，中间层对S203和S204择一执行即可。

在一种可能的实施方式中，在本实施例中，在执行步骤104时，若所述目标业务模块的数量为多个，则所述中间层可以按照多个所述目标业务模块对所述目标消息类型的所述注册时间从早到晚的顺序，通过预设消息处理接口，将所述业务消息依次发送给多个所述目标业务模块，以使多个所述目标业务模块分别处理所述业务消息。

在图4的实施例中，消息1的消息类型为消息类型1，消息2的消息类型为消息类型2；

那么中间层在分发消息1时，通过查找如表2所示的注册表可以查找到两个业务模块，分别为业务模块ID为ID1的业务模块1和业务模块ID为ID2的业务模块2，且先查找到业务模块1，后查找到业务模块2，因为，业务模块1对消息类型1的注册时间早于业务模块2对消息类型1的注册时间，因此，中间层通过该预设消息处理接口先向业务模块1分发消息1，然后，再向业务模块2分发该消息1，以使业务模块1和业务模块2分别处理消息1。

这样，本公开实施例的注册表中的多组对应关系是按照注册时间顺序排列的，或者，注册表中还保存了各个对应关系的注册时间，那么当存在多个业务模块均注册了同一个消息类型时，中间层在分发业务消息时，可以按照注册时间从早到晚的顺序依次分发该业务消息给各个消息处理者，即在注册表中与该目标消息类型存在对应关系的各个业务模块。考虑到注册时间较早的业务模块，对所注册的消息类型的处理请求的优先级较高，因此，可以按照注册时间从早到晚的顺序分发同一个消息类型的消息，也降低了中间层的处理压力。

在一种可能的实施方式中，如图5所示，步骤107之前，根据本公开实施例所述的方法还可以包括：

步骤104，所述中间层判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码；

由于业务模块向中间层注册其处理的消息类型的注册过程中，中间层不需要对业务模块进行审核，因此，可能存在以下情况：注册成为消息处理者的业务模块未对预设消息处理接口进行实现，或者，注册成为消息处理者的业务模块对该预设消息处理接口进行了实现，但是其实现的消息处理代码中不包括其请求注册的消息类型的消息处理代码。

因此，中间层在分发业务消息前，需要对被待分发业务消息的消息处理者(即目标业务模块)的处理权限进行判断，避免程序报错的情况。

本步骤中，所述中间层可以判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码。检查一个业务模块是否配置了实现该预设消息处理接口的消息处理代码的具体方法，可以采用任意一种传统检查方法，这里不再赘述。

若否，则步骤105，所述中间件将所述对应关系中所述目标消息类型与所述目标业务模块之间的对应关系删除；

其中，若否，则说明该目标业务模块未对中间层设置的统一的预设消息处理接口进行实现，因此，其无法处理任何类型的业务消息，所以，为了避免程序报错，可以将注册表中关于目标消息类型与该目标业务模块之间的对应关系删除。

若是，则步骤106，所述中间层继续判断所述消息处理代码是否包括与所述目标消息类型对应的目标消息处理代码，若是，则执行所述步骤107，若否，则执行所述步骤105。

其中，若是，则说明该目标业务模块对预设消息处理接口进行了代码实现，则需要判断其是否实现了即将分发的消息1的消息类型1的消息处理代码，即专门针对该消息类型1进行处理的目标消息处理代码，若是，则执行步骤107，若否，则执行步骤105。

这样，本公开实施例在分发业务消息至目标业务模块之前，可以对目标业务模块是否对预设消息处理接口进行了消息处理代码的实现进行检查，在通过检查的情况下，还对该目标业务模块实现的消息处理代码，检查是否包括针对目标消息类型的目标消息处理代码，在双重检查的情况下，可以确保分发业务消息至的目标业务模块能够对该业务消息进行处理，避免程序出错的情况。

在一种可能的实施方式中，一个业务模块可以预先配置对预设消息处理接口的多套实现代码，每套实现代码用于对一种消息类型的业务消息进行处理，不同消息类型的业务消息的处理逻辑可以存在差异。

在一种可能的实施方式中，所述预设消息处理接口包括消息属性字段，所述业务消息携带有消息属性信息。

如上文所述，该预设消息处理接口只负责定义消息属性字段和空的消息处理方法，其定义的字段类型可以包括消息类型字段、消息数量字段、在一种可能的实施方式中，消息内容字段；而中间层从服务端接收到的业务消息也会携带上述消息属性的具体内容，例如消息类型为M类型，消息数量为5条。

在一种可能的实施方式中，在执行步骤107时，可以通过如图6所示的流程来实现：

S301，所述中间层调用由所述目标业务模块实现的预设消息处理接口，并将所述消息属性信息传递至所述预设消息处理接口；

示例地，例如中间层定义的预设消息处理接口为Message()，通过查询注册表可知消息1的处理者为业务模块1(例如业务模块1对象为handle1)和业务模块2(例如业务模块2对象为handle2)，例如业务消息携带的消息属性信息包括消息类型1(例如a)、消息数量(例如3个)；那么中间层可以调用handle1.Message(a,3)来将消息属性信息发送至业务模块1；此外，中间层可以调用handle2.Message(a,3)来将消息属性信息发送至业务模块2。

以handle1.Message(a,3)为例进行说明，由于业务模块1实现了接口Message()，因此，handle1.Message()可以在代码层面执行成功，且handle1.Message()代表业务模块1所实现的预设消息处理接口，由于接口不包括代码实现，因此，中间层调用的不论是Message()，还是handle1.Message()，中间层都不需要关系业务层的业务逻辑，只需要将业务消息的属性信息传递给调用的接口handle1.Message()即可，从而呈现前文所述的中间层可以调用handle1.Message(a,3)，其中，业务消息的属性信息(a,3)也被传递至该预设消息处理接口。

S302，所述目标业务模块从所述预设消息处理接口获取所述消息属性信息；

其中，handle1可以从handle1.Message(a,3)获取到消息属性信息(a,3)。

S303，所述目标业务模块根据所述消息属性信息，识别所述业务消息的所述目标消息类型；

其中，handle1可以对获取到的消息属性信息中，识别出目标消息类型，即消息类型1(即a)

S304，所述目标业务模块从预先配置的实现所述预设消息处理接口的消息处理代码中，获取与所述目标消息类型对应的目标消息处理代码；

由于handle1可以配置实现该接口Message()的对应不同消息类型的多组消息处理代码，因此，这里业务模块1可以从多组消息处理代码中，获取到与目标消息类型对应的目标消息处理代码，即专门用于对消息类型为消息类型1的消息进行处理的逻辑代码。

S305，所述目标业务模块利用所述消息属性信息，按照所述目标消息处理代码，对所述业务消息进行处理。

其中，目标业务模块可以按照预先配置的所述目标消息处理代码，来对消息类型1的消息1进行处理。由于本例中以业务消息为红点消息为例进行的说明，因此，这里的处理逻辑为红点消息的处理逻辑，例如在客户端的应用图标上显示数字3，来达到提示消息类型1的消息的3条更新消息的目的。当然，对该红点消息的处理逻辑，并不限于这里举例的显示数字3，还可以是显示红点，以达到提示用户的目的。

若该业务消息为非红点消息，则该目标消息处理代码，则包括对非红点消息的处理逻辑，具体处理逻辑取决于业务需求，这里不做限制。

这样，本公开实施例的中间层通过消息处理接口，来将业务消息的属性信息传递给实现了该消息处理者接口的目标业务模块，使得目标业务模块可以从该消息处理接口获取到目标消息类型，并获取到与该目标消息类型对应的实现该消息处理接口的目标消息处理代码，最后，所述目标业务模块利用所述消息属性信息，按照所述目标消息处理代码，对所述业务消息进行处理。在分发业务消息的过程中，中间层不需要关系业务逻辑，只需要将业务消息的属性信息通过预设消息处理接口发送给目标业务模块，降低了中间层与业务层的耦合度，利于中间层的扩展和维护。而当业务模块配置有对多种消息类型的消息处理代码时，则业务模块可以从该消息处理接口获取到目标消息类型，从采用与目标消息类型对应的目标消息处理代码，来对业务消息进行处理，使得不同类型的业务消息的处理逻辑的差异不在中间层体现，而是在各个业务模块预先配置的消息处理代码中体现，简化了中间层的处理逻辑。

在一种可能的实施方式中，在步骤103之前，根据本公开实施例的消息处理方法还可以包括：

所述中间层判断所述业务消息是否合法；

其中，合法性的校验可以参照客户端与服务端约定的业务消息的合法性规则，例如消息数量不可以是负数。

若所述中间层判定所述业务消息合法，则执行所述步骤103。

也就是说，本公开实施例的中间层不仅具备对业务模块向处理的消息类型的注册功能、对注册有消息类型的业务模块的业务消息的分发功能，还具备对业务消息的统一管理功能，统一管理功能可以包括但不限于处理网络请求(例如服务端与客户端之间的网络请求)、业务消息的合法性校验、业务消息的数据缓存、业务消息的异常上报等。

本实施例中，描述了中间层对业务消息的合法性校验的管理功能，在查找注册表之前，本公开实施例的中间层可以对接收到的业务消息的合法性进行校验，在确认该业务消息合法的情况下，才会执行后续的消息分发步骤，确保分发的业务数据的安全性。

在一种可能的实施方式中，在判定所述业务消息合法的情况下，在执行步骤104之前，本公开实施例的方法还可以将该业务消息缓存。那么在中间层接收到多个业务消息的情况下，或者，一个业务消息需要分发给多个消息处理者时，则可以通过消息缓存的方式，来实现中间层对业务消息的分布式处理，确保业务消息的均衡处理。

在一种可能的实施方式中，对于上述业务消息的异常上报功能而言：客户端的中间层从服务段接收到业务消息后，将该业务消息分发给目标业务模块，例如业务消息的属性信息中包括消息数量，中间层分发业务消息给目标业务模块A时，携带的消息数量为8，即中间层告诉业务模块A这里有8条新消息；业务模块A接收到该业务消息后，如果经过检查发现接收到9条新消息，则业务模块可以通知客户端的中间层业务模块A接收到9条新信息，那么客户端的中间层发现消息数量不一致，则可以生成异常日志，上报给服务端的中间层，服务端的中间层将该日志记录在数据库，供开发人员统计异常。

本公开实施例的客户端的中间层通过设置异常上报功能，实现了消息管理功能与业务层的解耦，且能够通过异常上报功能，确保业务消息的准确分发。

图7是根据一示例性实施例示出的一种消息处理装置的结构框图，应用于客户端。参照图7，该装置包括：

第一接收模块701，被配置为执行接收业务消息；

识别模块702，被配置为执行识别所述业务消息的目标消息类型；

查找模块703，被配置为执行根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；

发送模块704，被配置为执行通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

在一种可能的实施方式中，所述消息处理装置还包括：

第二接收模块，被配置为执行通过预设注册接口，接收所述业务模块的注册请求，其中，所述注册请求包括所述业务模块的标识信息、所述业务模块请求处理的消息的消息类型；

生成模块，被配置为执行根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系。

在一种可能的实施方式中，所述消息处理装置还包括：

保存模块，被配置为执行按照注册时间从早到晚的顺序，依次保存所述消息类型与所述业务模块之间的多组对应关系；

所述发送模块704，还被配置为执行若所述目标业务模块的数量为多个，则按照多个所述目标业务模块对所述目标消息类型的所述注册时间从早到晚的顺序，通过预设消息处理接口，将所述业务消息依次发送给多个所述目标业务模块，以使多个所述目标业务模块分别处理所述业务消息。

在一种可能的实施方式中，所述消息处理装置还包括：

第一判断模块，被配置为执行判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码；

第二判断模块，被配置为执行若所述目标业务模块配置有实现所述预设消息处理接口的消息处理代码，则判断所述消息处理代码是否包括与所述目标消息类型对应的目标消息处理代码；

所述发送模块704，还被配置为执行若所述消息处理代码包括与所述目标消息类型对应的目标消息处理代码，则通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息；

删除模块，被配置为执行若所述目标业务模块未配置有实现所述预设消息处理接口的消息处理代码，或，若所述消息处理代码不包括与所述目标消息类型对应的目标消息处理代码，则将所述对应关系中所述目标消息类型与所述目标业务模块之间的对应关系删除。

在一种可能的实施方式中，所述预设消息处理接口包括消息属性字段，所述业务消息携带有消息属性信息，所述发送模块704包括：

调用子模块，被配置为执行调用由所述目标业务模块实现的预设消息处理接口，并将所述消息属性信息传递至所述预设消息处理接口；

第一获取子模块，被配置为执行从所述预设消息处理接口获取所述消息属性信息；

识别子模块，被配置为执行根据所述消息属性信息，识别所述业务消息的所述目标消息类型；

第二获取子模块，被配置为执行从预先配置的实现所述预设消息处理接口的消息处理代码中，获取与所述目标消息类型对应的目标消息处理代码；

处理子模块，被配置为执行利用所述消息属性信息，按照所述目标消息处理代码，对所述业务消息进行处理。

在一种可能的实施方式中，所述消息处理装置还包括：

第三判断模块，被配置为执行判断所述业务消息是否合法；

所述查找模块703，还被配置为执行若判定所述业务消息合法，则根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图8是根据一示例性实施例示出的一种用于消息处理的装置800的框图。例如，装置800可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图8，装置800可以包括以下一个或多个组件：处理组件802，存储器804，电力组件806，多媒体组件808，音频组件810，输入/输出(I/O)的接口812，传感器组件814，以及通信组件816。

处理组件802通常控制装置800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在设备800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件806为装置800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电力相关联的组件。

多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当设备800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当装置800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。

I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到设备800的打开/关闭状态，组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。

在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述任意一种实施方式中所述的消息处理方法。

在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。在一种可能的实施方式中，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种包括指令的应用程序，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品，包含可读程序代码，当所述可读程序代码在计算设备上运行是，可使所述计算设备执行上述任意一种实施方式中所述的消息处理方法。

图9是根据一示例性实施例示出的一种用于消息处理的装置1900的框图。例如，装置1900可以被提供为一服务器。参照图9，装置1900包括处理组件1922，其进一步包括一个或多个处理器，以及由存储器1932所代表的存储器资源，用于存储可由处理组件1922的执行的指令，例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1922被配置为执行指令，以执行上述方法……

装置1900还可以包括一个电源组件1926被配置为执行装置1900的电源管理，一个有线或无线网络接口1950被配置为将装置1900连接到网络，和一个输入输出(I/O)接口1958。装置1900可以操作基于存储在存储器1932的操作系统，例如Windows ServerTM，MacOS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种消息处理方法，其特征在于，应用于包括中间层和业务模块的客户端，所述方法包括：

所述中间层接收业务消息；

所述中间层识别所述业务消息的目标消息类型；

所述中间层根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；

所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

2.根据权利要求1所述的消息处理方法，其特征在于，所述中间层根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块之前，所述消息处理方法还包括：

所述中间层通过预设注册接口，接收所述业务模块的注册请求，其中，所述注册请求包括所述业务模块的标识信息、所述业务模块请求处理的消息的消息类型；

所述中间层根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系。

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

所述中间层根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系之后，所述消息处理方法还包括：

按照注册时间从早到晚的顺序，依次保存所述消息类型与所述业务模块之间的多组对应关系；

所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息，包括：

若所述目标业务模块的数量为多个，则所述中间层按照多个所述目标业务模块对所述目标消息类型的所述注册时间从早到晚的顺序，通过预设消息处理接口，将所述业务消息依次发送给多个所述目标业务模块，以使多个所述目标业务模块分别处理所述业务消息。

4.根据权利要求1所述的消息处理方法，其特征在于，

所述中间层通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息之前，所述消息处理方法还包括：

所述中间层判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码；

若所述目标业务模块配置有实现所述预设消息处理接口的消息处理代码，则所述中间层判断所述消息处理代码是否包括与所述目标消息类型对应的目标消息处理代码；

若所述消息处理代码包括与所述目标消息类型对应的目标消息处理代码，则所述中间层执行所述通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息的步骤；

若所述目标业务模块未配置有实现所述预设消息处理接口的消息处理代码，或，若所述消息处理代码不包括与所述目标消息类型对应的目标消息处理代码，则所述中间件将所述对应关系中所述目标消息类型与所述目标业务模块之间的对应关系删除。

5.一种消息处理装置，其特征在于，应用于客户端，所述消息处理装置包括：

第一接收模块，被配置为执行接收业务消息；

识别模块，被配置为执行识别所述业务消息的目标消息类型；

查找模块，被配置为执行根据预存的消息类型与业务模块之间的对应关系，查找与所述目标消息类型对应的目标业务模块；

发送模块，被配置为执行通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息。

6.根据权利要求5所述的消息处理装置，其特征在于，所述消息处理装置还包括：

第二接收模块，被配置为执行通过预设注册接口，接收所述业务模块的注册请求，其中，所述注册请求包括所述业务模块的标识信息、所述业务模块请求处理的消息的消息类型；

生成模块，被配置为执行根据所述注册请求，生成所述消息类型与所述业务模块之间的对应关系。

7.根据权利要求6所述的消息处理装置，其特征在于，所述消息处理装置还包括：

保存模块，被配置为执行按照注册时间从早到晚的顺序，依次保存所述消息类型与所述业务模块之间的多组对应关系；

所述发送模块，还被配置为执行若所述目标业务模块的数量为多个，则按照多个所述目标业务模块对所述目标消息类型的所述注册时间从早到晚的顺序，通过预设消息处理接口，将所述业务消息依次发送给多个所述目标业务模块，以使多个所述目标业务模块分别处理所述业务消息。

8.根据权利要求5所述的消息处理装置，其特征在于，所述消息处理装置还包括：

第一判断模块，被配置为执行判断所述目标业务模块是否配置有实现所述预设消息处理接口的消息处理代码；

第二判断模块，被配置为执行若所述目标业务模块配置有实现所述预设消息处理接口的消息处理代码，则判断所述消息处理代码是否包括与所述目标消息类型对应的目标消息处理代码；

所述发送模块，还被配置为执行若所述消息处理代码包括与所述目标消息类型对应的目标消息处理代码，则通过预设消息处理接口，将所述业务消息发送至所述目标业务模块，以使所述目标业务模块处理所述业务消息；

删除模块，被配置为执行若所述目标业务模块未配置有实现所述预设消息处理接口的消息处理代码，或，若所述消息处理代码不包括与所述目标消息类型对应的目标消息处理代码，则将所述对应关系中所述目标消息类型与所述目标业务模块之间的对应关系删除。

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

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至4中任一项所述的消息处理方法。

10.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至4中任一项所述的消息处理方法。