服务异步交互方法、设备、系统和可读介质与流程

本发明涉及通信技术领域，特别涉及服务异步交互方法、设备、系统和可读介质。

背景技术：

随着一个系统的功能和内容不断壮大，单一的系统无法支撑日益增长的用户体量。微服务的概念也是在这种环境下产生的，它是指导一个系统如何划分为一个个独立的系统，使服务之间相互解耦，从而提高服务的性能和稳定性。但解耦首要解决的问题是如何确保多个系统之间数据操作的一致性，也就是分布式事务如何保证最终一致性的方法。传统的解决方法就是通过各个服务之间通过http请求进行同步操作，如果只涉及到1至2个系统还可以稳定运行。但是一旦涉及到更多个系统，则一旦某一个系统出问题，会导致其他系统也会受到牵连。

技术实现要素：

本发明的主要目的是提供服务异步交互方法、设备、系统和可读介质，旨在增加系统之间同步操作的稳定性。

为实现上述目的，本发明提出的一种服务异步交互方法，用于多系统之间业务交互，所述服务异步交互方法包括如下步骤：

在接收到需要与另一系统进行业务交互的业务指令时，根据所述业务指令执行本地相关业务操作；

在所述业务操作成功时，调用消息通知与接收模块，来将所述业务操作的传递信息封装为通信消息，所述通信消息包括消息事务id以及消息发送和接受协议；

将所述通信消息发送至与所述另一系统之间部署的消息队列，用以通过所述消息队列发送至所述另一系统。

优选的，在所述业务操作成功时，所述服务异步交互方法还包括步骤：

在预设消息记录表中记录所述业务操作的业务操作消息，其中，所述业务操作消息包括所述消息事务id和推送状态；

在接收到来自所述另一系统针对所述通信消息返回的返回消息时，根据所述返回消息更新所述业务操作消息的推送状态。

优选的，所述服务异步交互方法还包括如下步骤：

定时轮询所述消息记录表，查询推送状态为失败的通信消息；

在查询到推送状态为失败的通信消息时，对所述推送状态为失败的通信消息进行重新发送。

优选的，所述消息队列采用兔子消息队列rabbitmq。

本发明提供的一种服务异步交互设备，所述服务异步交互设备包括处理器、存储器和储存于所述储存器上的并可在处理器上运行的服务异步交互程序；所述服务异步交互程序被所述处理器执行时实现上述的服务异步交互方法的步骤。

本发明提供的可读介质，用于计算机读取，所述可读介质上存储有服务异步交互程序，所述服务异步交互程序被处理器执行时实现上述的服务异步交互方法的步骤。

本发明提供的一种服务异步交互系统，包括处理器、存储器和储存于所述储存器上的用以实现多种服务的多个系统，所述服务异步交互系统还包括储存在所述储存器上的用于部署在多个所述系统之间的消息队列集群；

所述系统在被所述处理器执行时，实现如下步骤：

在接收到需要与另一系统进行业务交互的业务指令时，根据所述业务指令执行相关业务操作；

在所述业务操作成功时，调用消息通知与接收模块，来将所述业务操作的传递信息封装为通信消息，所述通信消息包括消息事务id以及消息发送和接受协议；

将所述通信消息发送至与另一系统之间部署的消息队列，用以通过所述消息队列发送至另一系统；

所述系统在被所述处理器执行时，还包括实现如下步骤：

接受来自另一系统的通信消息；

根据所述通信消息进行处理，并且在处理完毕时将处理结果封装为包括消息发送和接受协议的返回消息；

将所述返回消息发送至所述消息队列，用以通过所述消息队列发送至另一系统；

所述消息队列集群在被所述处理器执行时，实现如下步骤：

在接收到所述系统的通信消息以及返回消息时，通过每个所述系统之间业务交互所分别使用的一个指定消息队列来发送所述通信消息以及返回消息。

优选的，所述消息队列集群在被所述处理器执行时，还包括实现消息队列的持久化。

优选的，所述一系统在被所述处理器执行时，还实现如下步骤：

在所述业务操作成功时，在预设消息记录表中记录所述业务操作的业务操作消息，其中，所述业务操作消息包括所述消息事务id和推送状态；

在接收到来自另一系统针对所述通信消息返回的返回消息时，根据所述返回消息更新所述业务操作消息的推送状态。

优选的，所述一系统在被所述处理器执行时，还实现如下步骤：

定时轮询所述消息记录表，查询推送状态为失败的通信消息；

在查询到推送状态为失败的通信消息时，对所述推送状态为失败的通信消息进行重新发送。

本发明所提供的服务异步交互方法、设备、系统和可读介质，通过设置功能单一的系统，本地执行其业务，并且将传递信息通过封装并且通过消息队列传递至目标系统，则是各自在本地进行本地的业务逻辑操作，再将结果通过消息队列的方式发送至另一系统。相对于通过http实现系统间的同步，本实施例实现了系统之间的异步交互，能够增强系统的稳定性；进一步的，通过rabbitmq可以让各个系统的服务业务之间解耦，无需复杂的http调用接口验证。

附图说明

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

图1为本发明服务异步交互方法第一实施例的流程图；

图2为本发明服务异步交互方法第二实施例的流程图；

图3为本发明服务异步交互方法第三实施例的流程图；

图4为本发明服务异步交互设备一实施例的模块示意图；

图5为本发明可读介质一实施例的模块示意图；

图6为本发明服务异步交互系统一实施例的模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

请参看图1，本发明服务异步交互方法第一实施例，用于多系统之间业务交互，所述服务异步交互方法包括如下步骤：

步骤s101，在接收到需要与另一系统进行业务交互的业务指令时，根据所述业务指令执行本地相关业务操作。

例如，当用户在领券系统内激活了领券业务，则领券系统执行该领券的业务；而该领券的业务将用于订单系统，用于在订单系统内实施现金抵扣业务。则上述的领券业务需要与订单系统进行业务交互。当领券系统接收到执行领券业务指令时，其在本地执行该业务直至该业务结束，例如向用户展现领券动画，以及领券金额，以及领券成功的提示等等。

步骤s102，在所述业务操作成功时，调用消息通知与接收模块，来将所述业务操作的传递信息封装为通信消息，所述通信消息包括消息事务id以及消息发送和接受协议。

继续以上述领券业务作为例来说明：当用户激活领券业务，领券系统通过审核，并没有发现用户有任何不合规之处，则代表用户可以领用该优惠券。则领券系统执行发放优惠券的步骤，此时判定业务操作成功。若用户不符合领取优惠券的要求，则拒绝向用户发放优惠券，此时判定业务操作失败。在领券系统中，领券系统可以独立的完成其功能，无需关心订单系统是否能正确处理所接收到的优惠券消息，从而领券系统功能较单一，结构较简单地实现了其本身的领券功能。进一步的，当用户获得优惠券时，该优惠券需要与订单系统交流通讯，因此领券你系统需要生成一个传递信息，通知订单系统，该用户具有优惠券。

而该传递信息，通过通知与接收模块封装而成。具体的，该消息通知与接收模块的作用主要是生成一个唯一的消息事务id，供全局的消息使用，以达到区分各个消息的目的；另外此模块会按照具体消息队列的接口语法，封装好消息的发送和接受的方法，对外提供服务。此模块可以作为所有系统之间调用消息的共用模块。即该通知与接收模块可以是本系统存在的，也可以是多个系统共享使用的。

步骤s103，将所述通信消息发送至与所述另一系统之间部署的消息队列，用以通过所述消息队列发送至所述另一系统。

消息队列可以采用优选采用灰兔消息队列rabbitmq，rabbitmq是当前流行的开源消息队列系统，用erlang语言开发，因为erlang天生就是一门分布式语言，因此便于实现集群，以及分布式系统。rabbitmq是amqp(高级消息队列协议)的标准实现，可复用的企业消息系统。它遵循mozillapubliclicense开源协议。相对于其他的消息队列，rabbitmq具有开源，稳定性好，以及符合amqp标准，因此为优秀的消息队列选择。

本实施例所提供的服务异步交互方法，通过设置功能单一的系统，本地执行其业务，并且将传递信息通过封装并且通过消息队列传递至目标系统，则是各自在本地进行本地的业务逻辑操作，再将结果通过消息队列的方式发送至另一系统。相对于通过http实现系统间的同步，本实施例实现了系统之间的异步交互，能够增强系统的稳定性；进一步的，通过rabbitmq可以让各个系统的服务业务之间解耦，无需复杂的http调用接口验证。

其中，异步双方不需要共同的时钟，也就是接收方不知道发送方什么时候发送，所以在发送的信息中就要有提示接收方开始接收的信息，如开始位，同时在结束时有停止位。

解耦就是用数学方法将两种运动分离开来处理问题，常用解耦方法就是忽略或简化对所研究问题影响较小的一种运动，只分析主要的运动。从而使得系统的变量降低，使得系统更稳定。在解耦控制问题中，基本目标是设计一个控制装置，使构成的多变量控制系统的每个输出变量仅由一个输入变量完全控制，且不同的输出由不同的输入控制。

全局事务：资源管理器管理和协调的事务，可以跨越多个数据库和进程。

请参看图2，本发明服务异步交互方法第二实施例，本实施例以第一实施例为基础，新增了步骤，具体如下：

步骤s201，本步骤与第一实施例的步骤s101相同，具体请参看上述实施例，在此不再赘述。

步骤s202，本步骤与第一实施例的步骤s102相同，具体请参看上述实施例，在此不再赘述。

步骤s203，本步骤与第一实施例的步骤s103相同，具体请参看上述实施例，在此不再赘述。

步骤s204，在预设消息记录表中记录所述业务操作的业务操作消息，其中，所述业务操作消息包括所述消息事务id和推送状态。

步骤s205，在接收到来自所述另一系统针对所述通信消息返回的返回消息时，根据所述返回消息更新所述业务操作消息的推送状态。

本实施例，通过记录业务操作消息至消息记录表中，则可以实现对每一业务操作进行追溯的效果。从而便于复查以及核对消息等后续工作。

请参看图3，本发明服务异步交互方法第三实施例，本实施例以第二实施例为基础，新增了步骤，具体如下：

步骤s301，本步骤与第一实施例的步骤s201相同，具体请参看上述实施例，在此不再赘述。

步骤s302，本步骤与第一实施例的步骤s202相同，具体请参看上述实施例，在此不再赘述。

步骤s303，本步骤与第一实施例的步骤s203相同，具体请参看上述实施例，在此不再赘述。

步骤s304，本步骤与第一实施例的步骤s204相同，具体请参看上述实施例，在此不再赘述。

步骤s305，本步骤与第一实施例的步骤s205相同，具体请参看上述实施例，在此不再赘述。

步骤s306，定时轮询所述消息记录表，查询推送状态为失败的通信消息。

定时的时间，可以是5秒，1分钟或者10分钟等等。

步骤s307，在查询到推送状态为失败的通信消息时，对所述推送状态为失败的通信消息进行重新发送。

本实施例，通过定时轮询所述消息记录表，则可以了解发送失败的消息，进一步重发这些消息，从而建立了错误补偿机制。错误补偿机制能够保证一些消息发送失败，能够进行重新发送，确保消息抵达到其他系统的服务。

请参看图4，本发明服务异步交互设备一实施例，所述服务异步交互设备1000包括处理器1100、存储器1200和储存于所述储存器1200上的并可在处理器1100上运行的服务异步交互程序1300；所述服务异步交互程序1300被所述处理器1100执行时实现如上述任一实施例的服务异步交互方法的步骤。

所述服务异步交互方法被处理器1100执行时，所实现的步骤参看上述实施例，在此不再赘述。

由于本实施例所提供的服务异步交互设备1000，包括了上述服务异步交互方法的全部技术特征，因此也具有上述服务异步交互方法的全部有益效果，在此不再赘述。

请参看图5，本发明可读介质一实施例，用于计算机读取，所述可读介质2000上存储有服务异步交互程序2100，所述服务异步交互程序2100被处理器执行时实现如上述任一实施例的服务异步交互方法的步骤。

所述服务异步交互方法被处理器执行时，所实现的步骤参看上述实施例，在此不再赘述。

由于本实施例所提供的可读介质，包括了上述服务异步交互方法的全部技术特征，因此也具有上述服务异步交互方法的全部有益效果，在此不再赘述。

请参看图6本发明服务异步交互系统一实施例，所述服务异步交互系统3000，包括处理器3100、存储器3200和储存于所述储存器3200上的用以实现多种服务的多个系统。所述服务异步交互系统3000还包括储存在所述储存器3200上的用于部署在多个所述系统之间的消息队列集群3500。其中，本实施例中，多个系统以其中的第一系统3300和第二系统3400为例来举例说明。处理器3100可以是一个也可以是多个，储存器3200也可以是一个或多个，同样整个服务异步交互系统可以设置在一台服务器上，也可以设置在多台服务器上，例如第一系统3300位于一台服务器上，第二系统3400位于另一台服务器上等等。

所述第一系统3300在被所述处理器3100执行时，实现如下步骤：

在接收到需要与第二系统3400进行业务交互的业务指令时，根据所述业务指令执行相关业务操作。

例如，当用户在领券系统内激活了领券业务，则领券系统执行该领券的业务；而该领券的业务将用于订单系统，用于在订单系统内实施现金抵扣业务。则上述的领券业务需要与订单系统进行业务交互。当领券系统接收到执行领券业务指令时，其在本地执行该业务直至该业务结束，例如向用户展现领券动画，以及领券金额，以及领券成功的提示等等。

在所述业务操作成功时，调用消息通知与接收模块，来将所述业务操作的传递信息封装为通信消息，所述通信消息包括消息事务id以及消息发送和接受协议。

继续以上述领券业务作为例来说明：当用户激活领券业务，领券系统通过审核，并没有发现用户有任何不合规之处，则代表用户可以领用该优惠券。则领券系统执行发放优惠券的步骤，此时判定业务操作成功。若用户不符合领取优惠券的要求，则拒绝向用户发放优惠券，此时判定业务操作失败。在领券系统中，领券系统可以独立的完成其功能，无需关心订单系统是否能正确处理所接收到的优惠券消息，从而领券系统功能较单一，结构较简单地实现了其本身的领券功能。进一步的，当用户获得优惠券时，该优惠券需要与订单系统交流通讯，因此领券你系统需要生成一个传递信息，通知订单系统，该用户具有优惠券。

而该传递信息，通过通知与接收模块封装而成。具体的，该消息通知与接收模块的作用主要是生成一个唯一的消息事务id，供全局的消息使用，以达到区分各个消息的目的；另外此模块会按照具体消息队列的接口语法，封装好消息的发送和接受的方法，对外提供服务。此模块可以作为所有系统之间调用消息的共用模块。即该通知与接收模块可以是本系统存在的，也可以是多个系统共享使用的。

将所述通信消息发送至与第二系统3400之间部署的消息队列，用以通过所述消息队列发送至第二系统3400。

本实施例中，第一系统3300既包括本身业务所需的业务代码，还在业务代码中集成了消息通知与接收模块。同理，第二系统3400也既包括本身业务所需的业务代码，还在业务代码中集成了消息通知与接收模块。

所述第一系统3300在被所述处理器执行时，还包括实现如下步骤：

接受来自第二系统3400的通信消息；

根据所述通信消息进行处理，并且在处理完毕时将处理结果封装为包括消息发送和接受协议的返回消息；

将所述返回消息发送至所述消息队列，用以通过所述消息队列发送至第二系统3400。

所述消息队列集群在被所述处理器执行时，实现如下步骤：

在接收到所述第一系统3300的通信消息以及返回消息时，通过每个系统之间业务交互所分别使用的一个指定消息队列，来发送所述通信消息以及返回消息。

本实施例中，为了系统稳定以及便于维护，每个系统之间业务的交互需要分别使用一个消息队列进行消息通信，不可共用一个消息队列。进一步的，队列的名字可以取得相对有意义，如商品系统和订单系统交互的队列可以叫shop_order_queue，从而达到后期容易维护的效果。

消息队列可以采用优选采用灰兔消息队列rabbitmq，rabbitmq是当前流行的开源消息队列系统，用erlang语言开发，因为erlang天生就是一门分布式语言，因此便于实现集群，以及分布式系统。rabbitmq是amqp(高级消息队列协议)的标准实现，可复用的企业消息系统。它遵循mozillapubliclicense开源协议。相对于其他的消息队列，rabbitmq具有开源，稳定性好，以及符合amqp标准，因此为优秀的消息队列选择。

rabbit模式大概分为以下三种：单一模式、普通模式、镜像模式。其中，普通模式和镜像模式为集群模式。本实施例的rabbitmq集群则可以采用普通模式或镜像模式。

普通模式：默认的集群模式。

对于queue来说，消息实体只存在于其中一个节点，a、b两个节点仅有相同的元数据，即队列结构。

当消息进入a节点的queue中后，consumer从b节点拉取时，rabbitmq会临时在a、b间进行消息传输，把a中的消息实体取出并经过b发送给consumer。优选的consumer尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理queue。否则无论consumer连a或b，出口总在a，会产生瓶颈。

但是，该模式存在一个问题就是当a节点故障后，b节点无法取到a节点中还未消费的消息实体。因此，优选的所述消息队列集群在被所述处理器执行时，还包括实现消息队列的持久化。在做了持久化后，则可以等a节点恢复后，再可被消费；从而保证数据的稳定性。

其中，持久化可以包括：将交换机置为可持久，将通道置为可持久，以及消息发送时设置可持久。当消息可持久化时，若mq服务中断，再次启动消费者获取消息，消息依然能够恢复。

镜像模式：把需要的队列做成镜像队列，存在于多个节点，属于rabbitmq的ha方案。

该模式解决了上述普通模式存在的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在consumer取数据时临时拉取。

该模式由于需要较强的系统性能以及较宽裕的网络带宽条件。因此该模式在对可靠性要求较高的场合中适用。

本实施例服务异步交互系统的消息队列，采用rabbitmq集群方案，能够更高效和方便的实现多系统之间的分布式布局。

本实施例所提供的服务异步交互系统，通过设置功能单一的系统，本地执行其业务，并且将传递信息通过封装并且通过消息队列传递至目标系统，则是各自在本地进行本地的业务逻辑操作，再将结果通过消息队列的方式发送至另一系统。相对于通过http实现系统间的同步，本实施例实现了系统之间的异步交互，能够增强系统的稳定性；进一步的，通过rabbitmq可以让各个系统的服务业务之间解耦，无需复杂的http调用接口验证。

优选的，所述第一系统3300在被所述处理器3100执行时，还实现如下步骤：

在所述业务操作成功时，在预设消息记录表中记录所述业务操作的业务操作消息，其中，所述业务操作消息包括所述消息事务id和推送状态。

在接收到来自第二系统3400针对所述通信消息返回的返回消息时，根据所述返回消息更新所述业务操作消息的推送状态。

本实施例，通过记录业务操作消息至消息记录表中，则可以实现对每一业务操作进行追溯的效果。从而便于复查以及核对消息等后续工作。

优选的，所述第一系统3300在被所述处理器3100执行时，还实现如下步骤：

定时轮询所述消息记录表，查询推送状态为失败的通信消息；定时的时间，可以是5秒，1分钟或者10分钟等等。

在查询到推送状态为失败的通信消息时，对所述推送状态为失败的通信消息进行重新发送。

本实施例，通过定时轮询所述消息记录表，则可以了解发送失败的消息，进一步重发这些消息，从而建立了错误补偿机制。错误补偿机制能够保证一些消息发送失败，能够进行重新发送，确保消息抵达到其他系统的服务。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。