一种异步消息处理方法、装置、电子设备及存储介质与流程

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

背景技术：

随着互联网技术的发展，各行各业越来越依赖互联网提供服务。尤其是微服务和容器(docker)技术的出现，使得服务应用的发展更是与日俱增。

服务系统之间会产生、交互和处理大量的业务消息。其中，业务消息在服务系统之间交互可以采用同步和异步两种模式。同步模式是指第一服务系统处理完来自第二服务系统的一个业务消息，并反馈给第二服务系统之后，第一服务系统才能处理下一个业务消息。这种模式的吞吐量和处理能力比较低。相比之下，异步模式中第二服务系统无需等待第一服务系统处理业务消息的结果，可以直接产生大量的业务消息，第一服务系统按照自身实际情况处理业务消息即可。异步模式大大提高了吞吐量和处理能力，因此得到业内的青睐。

在异步模式下，业务消息通常为独立的消息，消息之间不具有关联关系，难以满足有关联关系的业务场景。而业务系统之间往往是通过单独部署第三方服务器以及配套软件来实现异步消息的处理，比如kafka、rabbitmq等等。如果直接对单独部署的第三方服务器进行开发来满足有关联关系的业务场景的需求，其开发和运行成本都将比较高。

技术实现要素：

针对上述现有技术，本发明实施例公开一种异步消息处方法，可以克服现有技术中异步消息无法满足有关联关系的业务场景需求的缺陷，达到满足有关联关系业务场景需求的目的。

鉴于此，本申请实施例提出一种异步消息处理方法，具体包括：

系统中间件接收业务系统产生的业务消息，所述系统中间件是所述业务系统内部集成的中间件，所述业务消息为独立的异步消息；

所述系统中间件根据设置的业务规则对所述业务消息进行调度处理，使得无需关联的业务消息保持为无关联关系的业务消息，需要关联的业务消息则成为有关联关系的业务消息；

所述系统中间件将经过调度处理的业务消息重新反馈给所述业务系统，由所述业务系统进行业务处理。

进一步地，

所述系统中间件根据设置的业务规则对所述业务消息进行调度处理的步骤包括：

将所述业务消息推送到建立的消息队列中；

在启动消息消费时，从所述消息队列中获取所述业务消息；

针对无需关联的业务消息，直接将其作为调度处理后的业务消息，并执行所述系统中间件将经过调度处理的业务消息重新反馈给所述业务系统的步骤；

针对需要关联的业务消息，则根据设置的业务规则判断当前是否可以执行，如果可以执行，则直接将其作为调度处理后的业务消息，并执行所述系统中间件将经过调度处理的业务消息重新反馈给所述业务系统的步骤；否则，将其重新推送到所述消息队列中等待。

进一步地，

所述将业务消息推送到建立的消息队列中的步骤包括：

根据设置的业务规则判断所述业务消息的类型，将非阻塞类型的业务消息推送到建立的非阻塞队列中，所述非阻塞类型的业务消息为所述无需关联的业务消息；将阻塞类型的业务消息推送到建立的阻塞队列中，所述阻塞类型的业务消息为需要关联的业务消息。

所述从消息队列中获取所述业务消息的步骤包括：

从所述非阻塞队列中获取无需关联的业务消息，从所述阻塞队列中获取需要关联的业务消息。

进一步地，

所述系统中间件是采用接口部分、抽象部分和实现部分的架构的中间件，所述接口部分表示中间件实现功能的定义，所述抽象部分表示中间件实现功能的抽象类，所述实现部分表示从所述抽象部分继承的具体实现中间件功能的子类。

本发明实施例公开一种异步消息处装置，可以克服现有技术中异步消息无法满足有关联关系的业务场景需求的缺陷，达到满足有关联关系业务场景需求的目的。

本申请实施例提出的一种异步消息处理的装置，包括：

接收模块，用于系统中间件接收业务系统产生的业务消息，所述系统中间件是所述业务系统内部集成的中间件，所述业务消息为独立的异步消息；

调度模块，用于所述系统中间件根据设置的业务规则对所述业务消息进行调度处理，使得无需关联的业务消息保持为无关联关系的业务消息，需要关联的业务消息则成为有关联关系的业务消息；

输出模块，用于所述系统中间件将经过调度处理的业务消息重新反馈给所述业务系统，由所述业务系统进行业务处理。

进一步地，

所述调度模块包括：

消息存取模块，用于将所述业务消息推送到建立的消息队列中；在启动消息消费时，从所述消息队列中获取所述业务消息；

无关联消息调度模块，针对无需关联的业务消息，直接将其作为调度处理后的业务消息，并传输给所述输出模块；

有关联消息调度模块，针对需要关联的业务消息，则根据设置的业务规则判断当前是否可以执行，如果可以执行，则直接将其作为调度处理后的业务消息，并传输给所述输出模块；否则，将其重新推送到所述消息队列中等待。

本发明实施例公开一种业务系统，可以克服现有技术中异步消息无法满足有关联关系的业务场景需求的缺陷，达到满足有关联关系业务场景需求的目的。

该业务系统至少集成有系统中间件，所述系统中间件可实现上述任一项所述的异步消息处理方法。

本申请实施例还公开一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时可实现上述任一项所述的异步消息处理方法的步骤。

本申请实施例还公开一种电子设备，该电子设备包括：

处理器；

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

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述任一项所述的异步消息处理方法。

综上所述，本申请实施例开发了系统中间件，且系统中间件是集成在业务系统内部的中间件，无需在第三方服务器中单独部署，可以大大降低开发和运行成本。本申请实施例中的业务消息仍然为异步消息，在系统中间件的调度控制下，会将需要关联的业务消息控制为有关联关系的业务消息。那么，在保持异步消息高吞吐率和高处理能力的基础上，还可以达到了同步消息才能达到的关联效果。

附图说明

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

图1是本申请方法实施例一的流程图。

图2是本申请方法实施例二的流程图。

图3是本申请实施例中系统中间件的架构示意图。

图4是本申请方法实施例三的流程图。

图5是本申请装置实施例一的结构图。

图6是本申请装置实施例二的结构图。

图7是本申请实施例中的业务系统的结构示意图。

图8是本申请实施例中电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

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

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

本申请实施例在保持异步模式的基础下，开发了可以实现异步消息处理的中间件，将中间件集成于业务系统内部，即本申请后续实施例所述的系统中间件。在业务系统产生业务消息时，由系统中间件对异步模式的业务消息进行调度处理，根据业务需求，使无需关联的业务消息仍然可以保持无关联关系的异步消息，而需要关联的业务消息则可以通过调度控制成为有关联关系的业务消息。

本申请实施例所述的“无关联关系”是指异步消息是彼此独立的，无需考虑执行的先后顺序，也无需考虑一个业务消息执行获得结果后，另一个业务消息再开始执行。相反，“有关联关系”是指异步消息本身虽然是彼此独立的，但由于业务的特殊需求，需要考虑执行的先后顺序，一个业务消息执行获得结果后，另一个业务消息再开始执行。

基于此，本申请公开以下具体实施方式。

图1是本申请实现异步消息处理的方法实施例一的流程图。如图1所示，该方法包括：

步骤101：系统中间件接收业务系统产生的业务消息，系统中间件是所述业务系统内部集成的中间件，业务消息为独立的异步消息。

如上所述，本申请实施例开发了可以实现异步消息处理的中间件，即这里所述的“系统中间件”。由于是直接集成在业务系统内部，这类中间件属于轻量级的中间件，而并非kafka或rabbitmq这类需要单独部署在第三方服务器上重量级的中间件。另外，本申请实施例中，不管是系统中间件调度处理前，还是系统中间件调度处理后，业务消息本身均为异步消息。

步骤102：系统中间件根据设置的业务规则对业务消息进行调度处理，使得无需关联的业务消息保持为无关联关系的业务消息，需要关联的业务消息成为有关联关系的业务消息。

在实际的业务系统中，产生的大多数业务消息彼此之间是无需关联关系的，仅在某些特殊情况下才具备关联关系。比如：

由于业务消息为异步消息，现有技术通常对异步消息不加区分，在线程可以启动执行的情况下，是按照顺序直接获取业务消息进行处理。而本步骤在对业务消息处理之前，先进行调度处理。这里所述“调度处理”的含义可以理解为系统中间件控制业务消息处理的先后顺序，避免线程对其进行无区别对待。总之，经过系统中间件的调度处理，无需关联的业务消息仍然可以保持为无关联的业务消息，而需要关联的业务消息则成为有关联关系的业务消息。需要注意的是，这里的“有关联关系”并不会改变业务消息本身为异步消息的属性，其关联性完全由系统中间件进行控制。

步骤103：系统中间件将经过调度处理的业务消息重新反馈给业务系统，由业务系统进行业务处理。

本申请实施例中的系统中间件仅对业务消息进行调度处理，对业务消息本身的业务处理部分仍然由业务系统现有的功能进行处理。至于业务系统如何进行业务处理，与实际的业务系统需要达到的功能相关，此处不再赘述。

由于本申请实施例中的系统中间件是集成在业务系统内部的中间件，无需在第三方服务器中单独部署，可以大大降低开发和运行成本。另外，本申请实施例中的业务消息为异步消息，但在系统中间件的调度控制下，需要关联的业务消息会成为有关联关系的业务消息。因此，在保持异步消息高吞吐率和高处理能力的基础上，还达到了同步消息才能达到的关联效果。

本申请还公开一种异步消息处理的方法实施例二。与上述方法实施例一相同，方法实施例二开发了可以实现异步消息处理的系统中间件，并直接集成在业务系统内部。图2是本申请实现异步消息处理的方法实施例二的流程图。如图2所示，该方法包括：

步骤201：系统中间件接收业务系统产生的业务消息，系统中间件是所述业务系统内部集成的中间件，业务消息为独立的异步消息。

本步骤与方法实施例一中的步骤101相同。

下述步骤202～205是系统中间件根据设置的业务规则对业务消息进行调度处理的具体实施方式，即步骤102的较佳实施方式。

本申请方法实施例二设置了消息队列，将业务系统产生的业务消息推送到消息队列中。当需要消费业务消息时，可以将业务消息从消息队列中拉取。由于业务消息的产生和处理彼此独立，因此本申请实施例二中的中间件仍然维护了异步消息的特点，不影响其吞吐率和处理能力。具体如下：

步骤202：将业务消息推送到建立的消息队列中。

步骤203：在启动消息消费时，从消息队列中获取业务消息。

本申请实施例中，业务系统具有产生业务消息和消费业务消息的功能，并通过设置的消息队列实现。实际应用中，两个以上的业务系统还可以相互发送业务消息，一个业务系统收发并处理来自于另一个业务系统的业务消息。也就是说，两个以上的业务系统都可以集成本申请实施例提出的系统中间件。

步骤204：针对无需关联的业务消息，直接将其作为调度处理后的业务消息，并执行步骤206。

步骤205：针对需要关联的业务消息，则根据设置的业务规则判断当前是否可以执行，如果可以执行，则直接将其作为调度处理后的业务消息，并执行步骤206；否则，将其重新推送到消息队列中等待。

上述步骤204和步骤205是针对无关联关系和有关联关系两种业务消息的调度方式。特别地，对于有关联关系的业务消息，步骤205如果判断出当前不可以执行，会将其重新推送到消息队列中等待，以控制业务消息的处理顺序。比如：某个业务消息a和业务消息b都在消息队列中，业务消息a在前，而业务消息b在后。系统中间件从消息队列中先获取业务消息a，根据业务规则判断出业务消息a需要等待业务消息b执行结果再执行。此时，系统中间件不会将在前的业务消息a反馈给业务系统，而是将其重新推送会消息队列中等待。系统中间件从消息队列中后获取业务消息b，不需要等待立即执行，将业务消息b反馈给业务系统。当系统中间件再次从消息队列中获取到业务消息a时，由于此时业务消息b已经执行，从而可以将业务消息a反馈给业务系统处理。也就是说，系统中间件对于原本无关联关系的业务消息a和业务消息b，利用自身的调度功能，改变了两者的顺序，建立了二者的关联关系，达到了同步消息才具备的效果，保证了业务的顺序进行。

步骤206：系统中间件将经过调度处理的业务消息重新反馈给业务系统，由业务系统进行业务处理。

本步骤与方法实施例一中的步骤103相同。

同样，本申请方法实施例二中的系统中间件是集成在业务系统内部的中间件，无需在第三方服务器中单独部署，可以大大降低开发和运行成本。本申请实施例中的业务消息为异步消息，利用建立的消息队列来保存和获取业务消息。在系统中间件的调度控制下，需要关联的业务消息会成为有关联关系的业务消息。因此，在保持异步消息高吞吐率和高处理能力的基础上，还达到了同步消息才能达到的关联效果，可以更好地满足业务的实际需求。

本申请还公开一种异步消息处理的方法实施例三。与上述方法实施例一和方法实施例二相同，方法实施例三开发了可以实现异步消息处理的系统中间件，并直接集成在业务系统内部。另外，本申请方法实施例三建立了两种消息队列，其中一种为非阻塞队列，另一种为阻塞队列。非阻塞队列用于保存无需关联的业务消息，阻塞队列用于保存需要关联的业务消息。

另外，如图3所示，本申请方法实施例三中的系统中间件采用接口部分-抽象部分-实现部分的架构。其中，接口部分表示中间件实现功能的定义，抽象部分表示中间件实现功能的抽象类，实现部分表示从所述抽象部分继承的具体实现中间件功能的子类。也就是说，假设系统中间件需要实现队列操作、消息查询、消息执行等功能，其中，“队列操作”表示将业务消息推送到消息队列以及从消息队列中获取业务消息；“消息查询”表示判断业务消息是否可以立即执行；“消息执行”表示将业务消息反馈给业务系统进行实现。

可以先在接口部分先定义这些动作，再利用抽象部分描述这些动作的算法模板，然后利用实现部分具体实现这些动作。

例如：

接口部分可以表示为：

interfaceaction{

……}；

其中，“interface”表示接口，“action”表示接口名；

抽象部分可以表示为：

abstractclassabsworker{

……}；

其中，“abstract”表示抽象类，“absworker”表示类名；

实现部分可以表示为：

classrealactionextendsabsworker{

……}；

其中，“realaction”表示子类，“extends”表示从抽象类“absworker”继承。

在本申请上述的架构下，由于实现部分是从抽象部分继承的子类，可以对其中的方法进行改写或者说重新开发，比如对“消息查询”进行改写。这样，不同的业务系统可以根据自身的业务规则改写“消息查询”，使得本申请的系统中间件可以集成到不同的业务系统中使用，增加其使用的灵活性。

在上述系统中间件的架构基础上，本申请还公开了下述实现异步消息处理方法实施例三。图4是本申请方法实施例三的流程图。如图4所示，该方法包括：

步骤401：系统中间件接收业务系统产生的业务消息，系统中间件是业务系统内部集成的中间件，业务消息为独立的异步消息。

本步骤与方法实施例二的步骤201相同

步骤402：根据设置的业务规则判断业务消息的类型。

本申请实施例三为业务消息设置了两类消息队列，一类是非阻塞队列，另一类是阻塞队列。根据具体的业务性质将业务消息分别推送给非阻塞队列和阻塞队列中。例如：某个业务系统为电子商城系统，包括库存部分、商城部分和报表部分等，会产生库存消息、商城消息和报表消息。其中，当库存信息添加到库存部分后，为了业务信息的一致性，还需要通知商城部分和报表部分。由于商城部分和报表部分之间在业务处理上没有关联性，因此可以将产生的库存消息、商城消息和报表消息推送到非阻塞队列中。

再比如：某个业务系统涉及报名缴费的流程，需要实现注册、报名以及缴费等功能，会产生注册消息、报名消息和缴费消息。那么，产生的这三种消息之间有关联性，需要按照顺序处理，因此需要将其推送到阻塞队列中。

步骤403：将非阻塞类型的业务消息推送到建立的非阻塞队列中，非阻塞类型的业务消息为无需关联的业务消息。

步骤404：将阻塞类型的业务消息推送到建立的阻塞队列中，所述阻塞类型的业务消息为需要关联的业务消息。

上述步骤402～步骤404是将业务消息推送到建立的消息队列中的具体实施方法，即方法实施例二的步骤202的具体实现。显然，按照本申请实施例三提出的系统中间件架构，本步骤所述的阻塞队列和非阻塞队列，以及将业务消息推送到阻塞队列和非阻塞队列均已在系统中间件的接口部分进行了定义，在抽象部分进行了抽象描述，并在实现部分进行具体实现。

步骤405：启动调度线程。

本申请实施例三采用线程技术实施对消息的消费，这里所述调度线程即实现从消息队列中取出业务消息，并判断是否可以执行等功能的线程。本领域技术人员知道，当消息队列为空时，线程处于阻塞状态；当消息队列不为空时，线程将被自动唤醒，从消息队列中获取业务消息。线程一旦被唤醒，只要阻塞队列或非阻塞队列不为空，该线程将循环执行，持续从消息队列中获取业务消息，直到消息队列为空，再次进入阻塞状态。

步骤406：从非阻塞队列中获取无需关联的业务消息。

本申请实施例三按照队列先进先出(fifo)的特性遍历非阻塞队列，从非阻塞队列中获取业务消息。由于非阻塞队列中保存的均为无需关联的业务消息，不必考虑与其他业务消息之间的相关性。在业务消息大部分为无需关联的业务消息时，可以保持高吞吐率和处理能力。

步骤407：针对无需关联的业务消息，直接将其作为调度处理后的业务消息，并执行步骤410。

步骤408：从阻塞队列中获取需要关联的业务消息。

同样，本申请实施例三也按照队列fifo的特性，从阻塞队列中获取业务消息。由于阻塞队列中保存的均为需要关联的业务消息，因此需要考虑与其他业务消息之间的相关性，达到同步消息的效果。

步骤409：针对需要关联的业务消息，则根据设置的业务规则判断当前是否可以执行，如果可以执行，则直接将其作为调度处理后的业务消息，并执行步骤410；否则，将其重新推送到阻塞队列中等待。

本申请实施例三中，如果业务消息a与其他业务消息b存在关联关系，且业务消息a当前不能不能执行时，可以将其重新推送到阻塞队列的队尾等待。等到与其相关的业务消息b执行后，调度线程重新从阻塞队列中取出业务消息a时，再开始执行业务消息a。

上述步骤405～步骤410是调度线程实施的部分。同样，按照本申请实施例三提出的系统中间件架构，调度线程中实现“消息查询”(check)和“消息执行”(handler)等已在系统中间件的接口部分进行了定义，在抽象部分进行了抽象描述，并在实现部分进行具体实现。由于系统中间件采用接口部分、抽象部分和实现部分这样的架构，不同的业务系统可以在实现部分中对抽象部分中的“消息查询”进行改写。也就是说，不同的系统业务的开发人员可以自行根据业务特点确定哪些情况下业务消息可以执行，哪些不可以执行，从而根据实际情况灵活地进行调度，有利于系统中间件集成在不同的第三方业务系统中。

步骤410：系统中间件将经过调度处理的业务消息重新反馈给所述业务系统，由所述业务系统进行业务处理。

本步骤与方法实施例二中的步骤206相同。实际应用，系统中间件利用“消息执行”(handler)为业务消息提供消费的入口，然后由业务系统根据实际情况进行业务处理。

本申请实施例三在保持异步消息高吞吐率和高处理能力的基础上，达到了同步消息才能达到的关联效果，可以更好地满足业务的实际需求。此外，由于系统中间件采用接口部分-抽象部分-实现部分的架构模式，实现部分可以对抽象部分中的方法进行改写，有利于开发人员对系统中间件进行二次开发。

基于上述方法实施例，本申请还公开一种异步消息处理的装置。该装置实际上是实现异步消息处理的中间件，将中间件集成于业务系统内部，即系统中间件。在业务系统产生业务消息时，由系统中间件对异步模式的业务消息进行调度处理，根据业务需求，无需关联的业务消息仍然可以保持无关联关系的异步消息，而需要关联的业务消息则可以通过调度成为有关联关系的业务消息。

图5是本申请实现异步消息处理的装置实施例一的结构图。如图5所示，该装置包括：接收模块501、调度模块502和输出模块503。其中：

接收模块501，用于系统中间件接收业务系统产生的业务消息，系统中间件是所述业务系统内部集成的中间件，业务消息为独立的异步消息。

调度模块502，用于系统中间件根据设置的业务规则对所述业务消息进行调度处理，使得无需关联的业务消息保持为无关联关系的业务消息，需要关联的业务消息则成为有关联关系的业务消息。

输出模块503，用于系统中间件将经过调度处理的业务消息重新反馈给所述业务系统，由业务系统进行业务处理。

也就是说，接收模块501接收业务系统产生的业务消息；调度模块502根据设置的业务规则对所述业务消息进行调度处理，使得无需关联的业务消息保持为无关联关系的业务消息，需要关联的业务消息则成为有关联关系的业务消息；输出模块503将经过调度处理的业务消息重新反馈给所述业务系统，由业务系统进行业务处理。

图6是本申请实现异步消息处理的装置实施例二的结构图。如图6所示，该装置包括：接收模块501、调度模块502和输出模块503。其中，调度模块502包括消息存取模块601、无关联消息调度模块602和有关联消息调度模块603。具体地：

接收模块501，用于系统中间件接收业务系统产生的业务消息，系统中间件是所述业务系统内部集成的中间件，业务消息为独立的异步消息。

调度模块502，用于系统中间件根据设置的业务规则对所述业务消息进行调度处理，使得无需关联的业务消息保持为无关联关系的业务消息，需要关联的业务消息则成为有关联关系的业务消息。其中：

消息存取模块601，用于将所述业务消息推送到建立的消息队列中；在启动消息消费时，从所述消息队列中获取所述业务消息。

无关联消息调度模块602，针对无需关联的业务消息，直接将其作为调度处理后的业务消息，并传输给所述输出模块503。

有关联消息调度模块603，针对需要关联的业务消息，则根据设置的业务规则判断当前是否可以执行，如果可以执行，则直接将其作为调度处理后的业务消息，并传输给所述输出模块503；否则，将其重新推送到所述消息队列中等待。

输出模块503，用于系统中间件将经过调度处理的业务消息重新反馈给所述业务系统，由业务系统进行业务处理。

也就是说，接收模块501接收业务系统产生的业务消息；消息存取模块601将所述业务消息推送到建立的消息队列中；在启动消息消费时，从所述消息队列中获取所述业务消息；针对无需关联的业务消息，无关联消息调度模块602直接将其作为调度处理后的业务消息，并传输给所述输出模块503；针对需要关联的业务消息，有关联消息调度模块603根据设置的业务规则判断当前是否可以执行，如果可以执行，则直接将其作为调度处理后的业务消息，并传输给所述输出模块503；否则，将其重新推送到所述消息队列中等待。输出模块503将经过调度处理的业务消息重新反馈给所述业务系统，由业务系统进行业务处理。

本申请装置实施例二中的装置(系统中间件)可以集成在业务系统内部，无需在第三方服务器中单独部署，降低了开发和运行成本。另外，本申请实施例在调度控制下，需要关联的业务消息会成为有关联关系的业务消息。因此，在保持异步消息高吞吐率和高处理能力的基础上，达到了同步消息才能达到的关联效果，可以更好地满足业务的实际需求。

实际应用中，本申请实施例中的装置可以采用接口部分-抽象部分-实现部分的架构其中，接口部分表示中间件实现功能的定义，抽象部分表示中间件实现功能的抽象类，实现部分表示从所述抽象部分继承的具体实现中间件功能的子类。也就是说，假设系统中间件需要实现队列操作、消息查询、消息执行等功能，其中，“队列操作”表示将业务消息推送到消息队列以及从消息队列中获取业务消息；“消息查询”表示判断业务消息是否可以立即执行；“消息执行”表示将业务消息反馈给业务系统进行实现。在本申请上述的架构下，由于实现部分是从抽象部分继承的子类，可以对其中的方法进行改写或者说重新开发，比如对“消息查询”进行改写。这样，不同的业务系统可以根据自身的业务规则改写“消息查询”，使得本申请的系统中间件可以集成到不同的业务系统中使用，增加其使用的灵活性。

另外，实际应用中，上述装置实施例中还可以包括两类消息队列，一类是非阻塞队列，另一类是阻塞队列。根据具体的业务性质将业务消息分别推送给非阻塞队列和阻塞队列中。上述装置实施例中可以采用线程技术实施对消息的消费。当消息队列为空时，线程处于阻塞状态；当消息队列不为空时，线程将被自动唤醒，从消息队列中获取业务消息。线程一旦被唤醒，只要阻塞队列或非阻塞队列不为空，该线程将循环执行，持续从消息队列中获取业务消息，直到消息队列为空，再次进入阻塞状态。具体的，按照队列先进先出(fifo)的特性遍历非阻塞队列，从非阻塞队列中获取业务消息。由于非阻塞队列中保存的均为无需关联的业务消息，不必考虑与其他业务消息之间的相关性。在业务消息大部分为无需关联的业务消息时，可以保持高吞吐率和处理能力。同时，按照队列fifo的特性，从阻塞队列中获取业务消息。由于阻塞队列中保存的均为需要关联的业务消息，因此需要考虑与其他业务消息之间的相关性，达到同步消息的效果。

本申请还公开一种业务系统。图7是本申请实施例中的业务系统结构示意图。如图7所示，该业务系统至少包括系统中间件701，所述系统中间件701可以理解为上述图5或图6所示的装置，可实现上述各方法实施例中的异步消息处理方法。这里所述的业务系统可以为任意的业务服务应用，比如订单系统、库存系统等等。也就是说，业务系统将产生的业务消息发送给系统中间件701，由系统中间件701对业务消息进行调度处理，而后由业务系统进行业务处理。

本申请实施例还提供一种计算机可读介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时可执行如上所述的异步消息处理方法中的步骤。实际应用中，所述的计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或多个程序被执行时，可以实现上述各实施例描述的异步消息处理方法。根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

如图8所示，本发明实施例还提供一种电子设备，其中可以集成本申请实施例实现方法的装置。如图8所示，其示出了本发明实施例所涉及的电子设备的结构示意图，具体来讲：

该电子设备可以包括一个或一个以上处理核心的处理器801、一个或一个以上计算机可读存储介质的存储器802以及存储在存储器上并可在处理器上运行的计算机程序。在执行所述存储器802的程序时，可以实现上述异步消息处理方法。

具体的，实际应用中，该电子设备还可以包括电源803、输入单元804、以及输出单元805等部件。本领域技术人员可以理解，图8中示出的电子设备的结构并不构成对该电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器801是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器802内的软件程序和/或模块，以及调用存储在存储器802内的数据，执行服务器的各种功能和处理数据，从而对该电子设备进行整体监控。

存储器802可用于存储软件程序以及模块，即上述计算机可读存储介质。处理器801通过运行存储在存储器802的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器802可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器802还可以包括存储器控制器，以提供处理器801对存储器802的访问。

该电子设备还包括给各个部件供电的电源803，可以通过电源管理系统与处理器801逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源803还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该电子设备还可包括输入单元804，该输入单元804可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

该电子设备还可以包括输出单元805，该输出单元805可以用于显示由用户输入的信息或提供给用户的信息以及各种图像用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。