CN113918357A - 业务处理方法及装置、存储介质、电子设备 - Google Patents

Abstract

本公开属于计算机技术领域，涉及一种业务处理方法及装置、存储介质、电子设备。该方法包括：当监听到消息队列时，拉取与消息队列对应的目标过滤规则和目标业务处理类；解析消息队列得到解析队列，并利用目标过滤规则对解析队列进行过滤处理得到目标消息；通过目标业务处理类执行目标消息的业务逻辑。本公开一方面，提供了多种过滤方式，丰富了消息队列的应用场景，解决了大型促销活动或者新业务试运行等场景下的过滤处理问题；另一方面，拉取到的目标过滤规则和目标业务处理类可以实时更改，无需重启服务器，满足了实际场景中判断逻辑不断更新的需求，也可以实现对同一组的服务器进行差异化的配置。

Description

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

技术领域

本公开涉及计算机技术领域，尤其涉及一种业务处理方法与业务处理装置、计算机可读存储介质及电子设备。

背景技术

消息队列具有异步处理、安全、稳定等特性，已经广泛应用到互联网的各个领域。其中，生产者可以将产生的消息放入消息队列，消息者可以监听消息队列，并消费消息队列中的消息。

在消费者监听和消费消息队列时，无法实时修改已上线的程序的判断逻辑，也无法满足同一组服务器端执行不同判断逻辑的需求。

鉴于此，本领域亟需开发一种新的业务处理方法及装置。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种业务处理方法、业务处理装置、计算机可读存储介质及电子设备，进而至少在一定程度上克服由于相关技术的限制而导致的无法实时修改判断逻辑和无法对同一组服务器执行不同判断逻辑的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本发明实施例的第一个方面，提供一种业务处理方法，应用于客户端，所述方法包括：当监听到消息队列时，拉取与所述消息队列对应的目标过滤规则和目标业务处理类；解析所述消息队列得到解析队列，并利用所述目标过滤规则对所述解析队列进行过滤处理得到目标消息；通过所述目标业务处理类执行所述目标消息的业务逻辑。

在本发明的一种示例性实施例中，所述拉取与所述消息队列对应的目标过滤规则和目标业务处理类，包括：拉取与所述消息队列对应的配置信息；在所述配置信息中确定目标过滤规则和目标业务处理类。

在本发明的一种示例性实施例中，所述配置信息，包括：首次配置信息和更新配置信息；所述拉取与所述消息队列对应的配置信息，包括：当所述配置信息为更新配置信息时，拉取与所述消息队列对应的更新配置信息；缓存所述更新配置信息。

在本发明的一种示例性实施例中，所述在所述配置信息中确定目标过滤规则和目标业务处理类，包括：确定所述配置信息中的过滤器类型为串行过滤器，并获取所述串行过滤器的多个串行过滤规则；确定所述多个串行过滤规则为目标过滤规则，并确定与所述目标过滤规则对应的业务处理类为目标业务处理类。

在本发明的一种示例性实施例中，所述在所述配置信息中确定目标过滤规则和目标业务处理类，包括：确定所述配置信息中的过滤器类型为决策过滤器，并确定所述决策过滤器中多个子过滤器；获取与所述多个子过滤器对应的多个过滤规则以及与所述决策过滤器对应的多个业务处理类；确定所述多个过滤规则中的一个为目标过滤规则，并确定所述多个业务处理类中的一个为目标业务处理类。

在本发明的一种示例性实施例中，所述在所述配置信息中确定目标过滤规则和目标业务处理类，包括：确定所述配置信息中的过滤器类型为降级过滤器，并获取所述降级过滤器中的目标过滤规则；确定与所述目标过滤规则对应的业务处理类为目标业务处理类。

在本发明的一种示例性实施例中，所述拉取与所述消息队列对应的目标过滤规则和目标业务处理类，包括：发送所述客户端的令牌和客户端标识，以确定所述客户端是否有拉取权限；若所述客户端有拉取权限，拉取与所述消息队列对应的目标过滤规则和目标业务处理类。

根据本发明实施例的第二个方面，提供一种业务处理装置，所述装置包括：数据拉取模块，被配置为当监听到消息队列时，拉取与所述消息队列对应的目标过滤规则和目标业务处理类；过滤处理模块，被配置为解析所述消息队列得到解析队列，并利用所述目标过滤规则对所述解析队列进行过滤处理得到目标消息；业务处理模块，被配置为通过所述目标业务处理类执行所述目标消息的业务逻辑。

根据本发明实施例的第三个方面，提供一种电子设备，包括：处理器和存储器；其中，存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现上述任意示例性实施例的业务处理方法。

根据本发明实施例的第四个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意示例性实施例中的业务处理方法。

由上述技术方案可知，本发明示例性实施例中的业务处理方法、业务处理装置、计算机存储介质及电子设备至少具备以下优点和积极效果：

在本公开的示例性实施例提供的方法及装置中，一方面，通过拉取到的目标过滤规则对消息队列进行过滤处理，提供了多种过滤方式，丰富了消息队列的应用场景，解决了大型促销活动或者新业务试运行等场景下的过滤处理问题；另一方面，拉取到的目标过滤规则和目标业务处理类可以实时更改，无需重启服务器，满足了实际场景中判断逻辑不断更新的需求，还可以实现同一组的服务器进行差异化的配置。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出相关技术中消费消息队列的第一种处理逻辑的流程示意图；

图2示意性示出相关技术中消费消息队列的第二种处理逻辑的流程示意图；

图3示意性示出相关技术中消费消息队列的第三种处理逻辑的流程示意图；

图4示意性示出本公开示例性实施例中一种业务处理方法的流程图；

图5示意性示出本公开示例性实施例中验证客户端拉取权限的方法的流程示意图；

图6示意性示出本公开示例性实施例中拉取配置信息的方法的流程示意图；

图7示意性示出本公开示例性实施例中拉取更新配置信息的方法的流程示意图；

图8示意性示出本公开示例性实施例中第一种确定目标过滤规则和目标业务处理类的方法的流程示意图；

图9示意性示出本公开示例性实施例中第二种确定目标过滤规则和目标业务处理类的方法的流程示意图；

图10示意性示出本公开示例性实施例中第三种确定目标过滤规则和目标业务处理类的方法的流程示意图；

图11示意性示出本公开示例性实施例中应用场景下业务处理方法的流程示意图；

图12示意性示出本公开示例性实施例中一种业务处理装置的结构示意图；

图13示意性示出本公开示例性实施例中一种用于实现业务处理方法的电子设备；

图14示意性示出本公开示例性实施例中一种用于实现业务处理方法的计算机可读存储介质。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。

在相关技术中，生产者可以将产生的消息放入消息队列，消费者可以监听该消息队列并消费消息。

其中，生产者是消息的提供者和发送者，是一个节点，而并非一个自然人。而消费者是消息的接收者和使用者，也是一个节点。

当消费消息队列时，可能会出现图1、图2和图3所示的三种处理逻辑。

图1示出了相关技术中消费消息队列的第一种处理逻辑的流程示意图，如图1所示，在接收到消息队列之后，通过三层判断逻辑验证该消息队列中的消息是否需要处理。

图2示出了相关技术中消费消息队列的第二种处理逻辑的流程示意图，如图2所示，在接收到消息队列之后，通过多个不同的逻辑判断才能确定要执行的业务逻辑。

图3示出了相关技术中消费消息队列的第三种处理逻辑的流程示意图，如图3所示，针对一些大型促销场景，可能会对某些消息队列进行降级处理；或者是在新业务上线时，会做灰度发布验证的操作。这些降级方式都需要配置好对应的判断逻辑。

在这三种处理逻辑中，可能会存在两种问题。一方面是无法对已上线的程序进行动态热变更处理，以修改判断逻辑；另一方面，同一组服务器无法执行不同的判断逻辑。

虽然第二个问题可以通过对每个服务器单独配置解决，但是这样不仅操作复杂麻烦，投入的人力物力较大，而且对代码逻辑的侵入性也极高。

针对相关技术中存在的问题，本公开提出了一种业务处理方法，应用于客户端。图4示出了业务处理方法的流程图，如图4所示，业务处理方法至少包括以下步骤：

步骤S410.当监听到消息队列时，拉取与消息队列对应的目标过滤规则和目标业务处理类。

步骤S420.解析消息队列得到解析队列，并利用目标过滤规则对解析队列进行过滤处理得到目标消息。

步骤S430.通过目标业务处理类执行目标消息的业务逻辑。

在本公开的示例性实施例中，一方面，通过拉取到的目标过滤规则对消息队列进行过滤处理，提供了多种过滤方式，丰富了消息队列的应用场景，解决了大型促销活动或者新业务试运行等场景下的过滤处理问题；另一方面，拉取到的目标过滤规则和目标业务处理类可以实时更改，无需重启服务器，满足了实际场景中判断逻辑不断更新的需求，还可以实现对同一组的服务器进行差异化的配置。

下面对业务处理方法的各个步骤进行详细说明。

在步骤S410中，当监听到消息队列时，拉取与消息队列对应的目标过滤规则和目标业务处理类。

在本公开的示例性实施例中，消息队列是用来异步处理一系列消息的通信方式。举例而言，消息队列可以是下单的消息队列，可以是出库的消息队列，或者是订单已完成的消息队列等，本示例性实施例对此不做特殊限定。

其中，消息可以是数据或者管理指令等。

对消息队列的监听可以是通过全局处理程序(GlobalHandler)实现的。具体的，可以将GlobalHandler注册到Spring容器中，以实现监听消息队列的功能。

通常调用各层级对象的时候，需要不断创建对象，一次访问就需要创建两个对象。如果使用Spring容器将不同层级的对象放入容器中，每次使用的时候调用容器中的对象，就不需要创建很多对象，以通过Sprin g容器达到节约内存空间的目的。

在监听到消息队列时，可以首先验证客户端的拉取权限。

在可选的实施例中，图5示出了验证客户端拉取权限的方法的流程示意图，如图5所示，该方法至少包括以下步骤：在步骤S510中，发送客户端的令牌和客户端标识，以确定客户端是否有拉取权限。

其中，令牌(token)是服务器端生成的一串字符串，以作客户端请求的。当客户端在服务器端首次登录后，服务器端生成一个token返回给客户端，以便客户端后续请求数据时，只需带上该token即可。

具体的，token可以是服务器端进行加密处理生成的字符串，也可以是自行设置其他规则生成的字符串，或者是其他可以保证token唯一性的方式生成的，本示例性实施例对此不做特殊限定。

客户端标识也可以唯一标识客户端，以作为请求数据的权限验证的依据。

举例而言，客户端标识可以是通用唯一识别码(Universally UniqueIdentifier，简称UUID)，也可以是其他标识信息，本示例性实施例对此不做特殊限定。

将令牌和客户端标识发送至服务器端，服务器端可以对该令牌和客户端标识进行验证，以根据验证结果确定该客户端是否有拉取权限。

在步骤S520中，若客户端有拉取权限，拉取与消息队列对应的目标过滤规则和目标业务处理类。

当服务器端对令牌和客户端标识验证通过时，表明该客户端具有拉取权限，可以拉取目标过滤规则和目标业务处理类。

具体的，可以通过拉取与消息队列对应的配置信息获取目标过滤规则和目标业务处理类。

该配置信息可以是服务器端按照业务规则进行配置的信息。

举例而言，该配置信息可以包括业务名称信息，该业务名称信息可以便于查看和记录日志，并且可以作为配置信息的标识信息。

除此之外，还可以包括消息队列的主体名称，亦即该消息队列的分类名称，也可以包括执行分片信息。该执行分片信息是客户端在启动时，向服务器端注册的客户端的机器信息。因此，在配置的时候，服务器端可以选择执行当前业务逻辑的客户端。

在可选的实施例中，图6示出了拉取配置信息的方法的流程示意图，如图6所示，该方法至少包括以下步骤：在步骤S610中，拉取与消息队列对应的配置信息。

在可选的实施例中，配置信息包括首次配置信息和更新配置信息，图7示出了拉取更新配置信息的方法的流程示意图，如图7所示，该方法至少包括以下步骤：在步骤S710中，当配置信息为更新配置信息时，拉取与消息队列对应的更新配置信息。

其中，首次配置信息可以是客户端启动服务器端时拉取到的配置信息。

具体的，当拉取到配置时，可以根据配置中的消息队列分类名称进行分组，并且将分类名称一致的配置存储到同一个哈希表中。

哈希表是根据键值对(Key-value)而直接进行访问的数据结构。也就是说，它通过把键值对映射到表中的一个位置来访问记录，以加快查找的速度。其中，该映射函数叫做散列函数，存放记录的数组叫做散列表。

在该哈希表中value处存储的为与消息队列对应的配置信息，可以包括业务处理类、过滤器类型和过滤规则。

更新配置信息可以是对首次配置信息进行调整得到的配置信息，也可以是通过用户操作更新的配置信息，本示例性实施例对此不做特殊限定。

当要拉取的配置信息为更新配置信息时，当前注册的客户端拉取到的配置信息即为更新配置信息。

在步骤S720中，缓存更新配置信息。

为了防止同时拉取的客户端过多，造成服务器端的负载过大，因此可以设置预设时长的数据缓存，将更新配置信息缓存下来。该预设时长可以为1分钟或者40秒，本示例性实施例对此不做特殊限定。

除此之外，也可以通过定时触发的方式拉取首次配置信息和更新配置信息。该定时时长可以为30分钟，也可以为其他时长，本示例性实施例对此不做特殊限定。

在本示例性实施例中，通过拉取更新配置信息时进行缓存，可以缓解服务器端的负载压力，提升拉取配置信息的效率。

在步骤S620中，在配置信息中确定目标过滤规则和目标业务处理类。

由于不同的过滤器类型确定目标过滤规则和目标业务处理类的方式不同，因此可以分别对不同的确定方式进行说明。

其中，过滤器可以是服务器端设置的消息过滤器，用于将消息队列中预定类型的消息过滤掉，或者是仅保留消息队列中预定类型的消息。

进一步的，图8、图9和图10分别是三种确定目标过滤规则和目标业务处理类的方法的流程示意图。其中，图8是过滤器类型为串行过滤器时，确定目标过滤规则和目标业务处理类的方法的流程示意图；图9是过滤器类型为决策过滤器类型时，确定目标过滤规则和目标业务处理类的方法的流程示意图；图10是过滤器类型为降级过滤器时，确定目标过滤规则和目标业务处理类的方法的流程示意图。

值得说明的是，每种过滤器中的各层都可以通过单独的Groovy代码段实现。

其中，Groovy是一种基于Java虚拟机的敏捷开发语言，它结合了P ython、Ruby和Smalltalk的许多强大的特性，Groovy代码能够与Java代码很好地结合，也能用于扩展现有代码。

在可选的实施例中，图8示出了第一种确定目标过滤规则和目标业务处理类的方法的流程示意图，如图8所示，该方法至少包括以下步骤：在步骤S810中，确定配置信息中的过滤器类型为串行过滤器，并获取串行过滤器的多个串行过滤规则。

串行过滤器可以是服务器端添加的多层过滤器。并且，多层过滤器中的每一层都设置有对应的过滤规则。亦即，串行过滤器对应有多个串行过滤规则。并且，多个串行过滤规则可以通过多层过滤器的每一层的开关状态确定是否要进行过滤。

并且，当串行过滤器的开关打开时，消息队列中的消息只有满足上一层的过滤规则，才能继续进行下一层过滤规则的判断。

在步骤S820中，确定多个串行过滤规则为目标过滤规则，并确定与目标过滤规则对应的业务处理类为目标业务处理类。

当过滤器类型为串行过滤器时，串行过滤器的多个串行过滤规则共同组成目标过滤规则。

并且，由于串行过滤器配置的业务处理类为一个，因此，确定该配置好的业务处理类为串行过滤器的目标业务处理类。

值得说明的是，该目标业务处理类为类的全路径。类的全路径是该业务处理类的存储地址，也就是该目标业务处理类所在位置的包名。由于在不同的包中允许存在名称一样的业务处理类，因此需要指明全路径，以便于找到目标业务处理类。

在本示例性实施例中，确定串行过滤器的目标过滤规则和目标业务处理类，为完成消息过滤提供了一种过滤类型，并且确定方式简单准确，适用性极强。

在可选的实施例中，图9示出了第二种确定目标过滤规则和目标业务处理类的方法的流程示意图，如图9所示，该方法至少包括以下步骤：在步骤S910中，确定配置信息中的过滤器类型为决策过滤器，并确定过滤器中的多个子过滤器。

决策过滤器可以是服务器添加的多层过滤器，并且每层过滤器设置有对应的过滤规则。当满足其中一层的过滤规则时，可以执行与该过滤规则对应的业务处理类。

其中，在决策过滤器中的每层过滤器均为决策过滤器中的一个子过滤器。因此，一个决策过滤器对应有多个子过滤器。

在步骤S920中，获取与多个子过滤器对应的多个过滤规则以及与决策过滤器对应的多个业务处理类。

在确定决策过滤器中的多个子过滤器之后，可以获取各个子过滤器对应的过滤规则。并且，由于一个决策过滤器需要配置多个业务处理类，因此还可以获取到多个业务处理类。

值得说明的是，该业务处理类为类的全路径。类的全路径是该业务处理类的存储地址，也就是该业务处理类所在位置的包名。由于在不同的包中允许存在名称一样的业务处理类，因此需要指明全路径，以便于找到目标业务处理类。

在步骤S930中，确定多个过滤规则中的一个为目标过滤规则，并确定多个业务处理类中的一个为目标业务处理类。

当消息列表中的消息满足多个过滤规则中的一个时，可以确定该过滤规则为目标过滤规则，并且确定与该过滤规则对应的业务处理类为目标业务处理类。

在本示例性实施例中，确定决策过滤器的目标过滤规则和目标业务处理类，为完成消息过滤提供了另一种过滤类型，并且确定方式简单准确，适用性极强。

在可选的实施例中，图10示出了第三种确定目标过滤规则和目标业务处理类的方法的流程示意图，如图10所示，该方法至少包括以下步骤：在步骤S1010中，确定配置信息中的过滤器类型为降级过滤器，并获取降级过滤器中的目标过滤规则。

降级过滤器可以是服务器添加的一层过滤器，并且该过滤器中可以设置降级参数。举例而言，该降级参数可以是百分比的形式，也可以是其他形式，本示例性实施例对此不做特殊限定。

并且，依据降级参数设置的规则配置即为目标过滤规则。

除此之外，降级过滤器的目标过滤规则还可以通过其他方式实现降级过滤的目的，本示例性实施例对此不做特殊限定。

在步骤S1020中，确定与目标过滤规则对应的业务处理类为目标业务处理类。

由于降级过滤器配置一个业务处理类，因此当过滤器的类型为降级过滤器时，确定该业务处理类为目标业务处理类即可。

值得说明的是，该业务处理类为类的全路径。类的全路径是该业务处理类的存储地址，也就是该业务处理类所在位置的包名。由于在不同的包中允许存在名称一样的业务处理类，因此需要指明全路径，以便于找到目标业务处理类。

在本示例性实施例中，确定降级过滤器的目标过滤规则和目标业务处理类，为完成消息过滤提供了再一种过滤类型，并且确定方式简单准确，适用性极强。

值得说明的是，当客户端有多个时，还可以通过Redis等其他中间件实现降级过滤的功能。

Redis是一个开源的支持网络，且基于内存的键值对(key-value)存储数据库，支持多种数据类型和多种操作，具有强大的管理数据的功能。Redis支持存储的value类型包括字符串(string)、链表(list)、集合(s et)和有序集合(zset)。这些数据类型都支持更为丰富的操作，而且这些操作都是原子性的。

在步骤S420中，解析消息队列得到解析队列，并利用目标过滤规则对解析队列进行过滤处理得到目标消息。

在本公开的一种示例性实施例中，对消息队列的解析方式可以是对加密的消息队列进行解密处理，也可以是将json格式的消息队列转化成对象，还可以是其他解析方式，本示例性实施例对此不做特殊限定。

在对消息队列进行解析处理之后，可以得到解析队列。并且，利用目标过滤规则拦截解析队列中的消息。

举例而言，当目标过滤规则是降级参数为10％的降级过滤器对应的过滤规则时，可以拦截消息队列中10％的消息，剩余的90％的消息队列中的消息为目标消息。

在步骤S430中，通过目标业务处理类执行目标消息的业务逻辑。

在本公开的一种示例性实施例中，当过滤处理得到目标消息时，可以利用目标业务处理类执行该目标消息的业务逻辑。

具体的，可以是在Spring容器中加载出该目标业务处理类，并且调用该目标业务处理类的execute()方法执行该目标消息的业务逻辑。

下面结合一应用场景对本公开实施例中的业务处理方法做出详细说明。

图11示出了在应用场景下的业务处理方法的流程示意图，如图11所示，在步骤S1110中，通过GlobalHandler统一监听消息队列。

其中，消息队列可以包括下单的消息队列、出库的消息队列和订单完成的消息队列等，本示例性实施例对此不做特殊限定。

在步骤S1120中，拉取与消息队列对应的配置信息。

该配置信息可以包括首次配置信息和更新配置信息。

其中，首次配置信息可以是客户端启动服务器端时拉取到的配置信息。

具体的，当拉取到配置时，可以根据配置中的消息队列分类名称进行分组，并且将分类名称一致的配置存储到同一个哈希表中。

该哈希表是根据键值对而直接进行访问的数据结构。也就是说，它通过把键值对映射到表中的一个位置来访问记录，以加快查找的速度。其中，该映射函数叫做散列函数，存放记录的数组叫做散列表。

在该哈希表中value处存储的为与消息队列对应的配置信息，可以包括业务处理类、过滤器类型和过滤规则。

在步骤S1121中，当配置信息为首次配置信息时，在客户端的缓存模块中拉取首次配置信息。

在步骤S1122中，当配置信息为更新配置信息时，通过配置功能在配置信息为更新配置信息时，通知客户端拉取更新配置信息。

该更新配置信息可以是对首次配置信息进行调整得到的配置信息，也可以是通过用户操作更新的配置信息，本示例性实施例对此不做特殊限定。

值得说明的是，拉取配置信息还同时支持Quartz触发，亦即定时拉取。

举例而言，该定时时长可以为30分钟，也可以为其他根据实际场景设置的时长，本示例性实施例对此不做特殊限定。

除此之外，在步骤S1130中，在客户端启动服务器端时，服务器端会启动注册客户端信息的功能。

并且，服务器端会注册当前客户端的信息，以便于在配置的时候选择执行业务逻辑的客户端。

进一步的，在步骤S1140中，当拉取到配置信息时，可以在配置信息中确定出目标过滤规则和目标业务处理类。

对目标过滤规则和目标业务处理类的确定方式与图8、图9和图10相同，在此不再赘述。

通过目标过滤规则可以过滤消息队列中的消息得到目标消息。

值得说明的是，当消息队列是加密的，或者是json格式时，可以先对消息队列进行解析处理。

在步骤S1150中，调用业务处理类执行目标消息的业务逻辑。

具体的，可以是在Spring容器中加载出该目标业务处理类，并且调用该目标业务处理类的execute()方法执行该目标消息的业务逻辑。

其中，该更新配置信息可以是对首次配置信息进行调整得到的配置信息，也可以是通过用户操作更新的配置信息，本示例性实施例对此不做特殊限定。

在本公开的示例性实施例中，一方面，通过拉取到的目标过滤规则对消息队列进行过滤处理，提供了多种过滤方式，丰富了消息队列的应用场景，解决了大型促销活动或者新业务试运行等场景下的过滤处理问题；另一方面，拉取到的目标过滤规则和目标业务处理类可以实时更改，无需重启服务器，满足了实际场景中判断逻辑不断更新的需求，还可以实现对同一组的服务器进行差异化的配置。

此外，在本公开的示例性实施例中，还提供一种业务处理装置。图12示出了业务处理装置的结构示意图，如图12所示，业务处理装置1200可以包括：数据拉取模块1210、过滤处理模块1220和业务处理模块1230。其中：

数据拉取模块1210，被配置为当监听到消息队列时，拉取与消息队列对应的目标过滤规则和目标业务处理类；过滤处理模块1220，被配置为解析消息队列得到解析队列，并利用目标过滤规则对解析队列进行过滤处理得到目标消息；业务处理模块1230，被配置为通过目标业务处理类执行目标消息的业务逻辑。

上述业务处理装置1200的具体细节已经在对应的业务处理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及业务处理装置1200的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

下面参照图13来描述根据本发明的这种实施例的电子设备1300。图13显示的电子设备1300仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图13所示，电子设备1300以通用计算设备的形式表现。电子设备1300的组件可以包括但不限于：上述至少一个处理单元1310、上述至少一个存储单元1320、连接不同系统组件(包括存储单元1320和处理单元1310)的总线1330、显示单元1340。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1310执行，使得所述处理单元1310执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

存储单元1320可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)1321和/或高速缓存存储单元1322，还可以进一步包括只读存储单元(ROM)1323。

存储单元1320还可以包括具有一组(至少一个)程序模块1325的程序/实用工具1324，这样的程序模块1325包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1330可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1300也可以与一个或多个外部设备1500(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1300交互的设备通信，和/或与使得该电子设备1300能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1350进行。并且，电子设备1300还可以通过网络适配器1360与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1360通过总线1330与电子设备1300的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

参考图14所示，描述了根据本发明的实施例的用于实现上述方法的程序产品1400，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

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

Claims (10)

1.一种业务处理方法，应用于客户端，其特征在于，所述方法包括：

当监听到消息队列时，拉取与所述消息队列对应的目标过滤规则和目标业务处理类；

解析所述消息队列得到解析队列，并利用所述目标过滤规则对所述解析队列进行过滤处理得到目标消息；

通过所述目标业务处理类执行所述目标消息的业务逻辑。

2.根据权利要求1所述的业务处理方法，其特征在于，所述拉取与所述消息队列对应的目标过滤规则和目标业务处理类，包括：

拉取与所述消息队列对应的配置信息；

在所述配置信息中确定目标过滤规则和目标业务处理类。

3.根据权利要求2所述的业务处理方法，其特征在于，所述配置信息，包括：首次配置信息和更新配置信息；

所述拉取与所述消息队列对应的配置信息，包括：

当所述配置信息为更新配置信息时，拉取与所述消息队列对应的更新配置信息；

缓存所述更新配置信息。

4.根据权利要求2所述的业务处理方法，其特征在于，所述在所述配置信息中确定目标过滤规则和目标业务处理类，包括：

确定所述配置信息中的过滤器类型为串行过滤器，并获取所述串行过滤器的多个串行过滤规则；

确定所述多个串行过滤规则为目标过滤规则，并确定与所述目标过滤规则对应的业务处理类为目标业务处理类。

5.根据权利要求2所述的业务处理方法，其特征在于，所述在所述配置信息中确定目标过滤规则和目标业务处理类，包括：

确定所述配置信息中的过滤器类型为决策过滤器，并确定所述决策过滤器中多个子过滤器；

获取与所述多个子过滤器对应的多个过滤规则以及与所述决策过滤器对应的多个业务处理类；

确定所述多个过滤规则中的一个为目标过滤规则，并确定所述多个业务处理类中的一个为目标业务处理类。

6.根据权利要求2所述的业务处理方法，其特征在于，所述在所述配置信息中确定目标过滤规则和目标业务处理类，包括：

确定所述配置信息中的过滤器类型为降级过滤器，并获取所述降级过滤器中的目标过滤规则；

确定与所述目标过滤规则对应的业务处理类为目标业务处理类。

7.根据权利要求1所述的业务处理方法，其特征在于，所述拉取与所述消息队列对应的目标过滤规则和目标业务处理类，包括：

发送所述客户端的令牌和客户端标识，以确定所述客户端是否有拉取权限；

若所述客户端有所述拉取权限，拉取与所述消息队列对应的目标过滤规则和目标业务处理类。

8.一种业务处理装置，其特征在于，包括：

数据拉取模块，被配置为当监听到消息队列时，拉取与所述消息队列对应的目标过滤规则和目标业务处理类；

过滤处理模块，被配置为解析所述消息队列得到解析队列，并利用所述目标过滤规则对所述解析队列进行过滤处理得到目标消息；

业务处理模块，被配置为通过所述目标业务处理类执行所述目标消息的业务逻辑。

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

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

处理器；

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

其中，所述处理器被配置为经由执行所述可执行指令来执行权利要求1-7中任意一项所述的业务处理方法。

Images