CN114356599A - 业务消息处理系统及方法 - Google Patents

Abstract

本发明实施例公开了一种业务消息处理系统及方法，其中，该系统包括：消息生产层、数据中心和消息订阅层，其中，数据中心，用于存储消息队列，消息队列用于存储事务型消息；消息生产层，用于接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中；消息订阅层，用于从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作。本发明实施例的技术方案，解决了在海量数据处理过程中出现的数据不一致性以及本地事务或分布式事务不适用微服务架构的问题，提高了系统资源利用率，在一定程度上提高了系统的性能和响应速率。

Description

业务消息处理系统及方法

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种业务消息处理系统及方法。

背景技术

随着摩尔定律遇到瓶颈，越来越多的情况下需要依靠分布式架构，才能实现海量数据处理能力和可扩展计算能力。

在微服务架构中，通常情况下，数据都是微服务私有的，只能通过API的方式访问数据。这种方式可以实现微服务间的松耦合，是彼此独立的微服务更容易进行扩展。然而，随之带来的问题是：数据不一致性既不能依靠底层数据库事务实现，也无法通过统一的事务协调器来实现数据一致性，传统的本地事务或分布式事务不适合微服务架构。

发明内容

本发明实施例提供了一种业务消息处理系统及方法，以实现业务消息的动态适应性执行。

第一方面，本发明实施例提供了一种业务消息处理系统，该系统包括：消息生产层、数据中心和消息订阅层，其中，

数据中心，用于存储消息队列，消息队列用于存储事务型消息；

消息生产层，用于接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中；

消息订阅层，用于从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作。

第二方面，本发明实施例还提供了一种业务消息处理方法，该方法包括：

通过消息生产层接收所述目标事务的系统操作信息，并根据所述系统操作信息生成与所述目标事务对应的事务型消息，将所述事务型消息发送到数据中心的消息队列中，其中，所述数据中心用于存储消息队列，所述消息队列用于存储事务型消息。

通过消息订阅层从所述数据中心的消息队列中读取所述事务型消息，并执行与所述事务型消息对应的目标消费操作。

第三方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本发明任意实施例所提供的业务消息处理方法。

本发明实施例提供了一种业务消息处理系统，该系统包括：消息生产层、数据中心和消息订阅层，其中，数据中心，用于存储消息队列，消息队列用于存储事务型消息；消息生产层，用于接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中；消息订阅层，用于从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作，解决了在海量数据处理过程中出现的数据不一致性以及本地事务或分布式事务不适用微服务架构的问题，提高了系统资源利用率，在一定程度上提高了系统的性能和响应速率。

附图说明

为了更加清楚地说明本发明示例性实施例的技术方案，下面对描述实施例中所需要用到的附图做一简单介绍。显然，所介绍的附图只是本发明所要描述的一部分实施例的附图，而不是全部的附图，对于本领域普通技术人员，在不付出创造性劳动的前提下，还可以根据这些附图得到其他的附图。

图1为本发明实施例一所提供的一种业务消息处理系统的结构示意图；

图2为本发明实施例二所提供的一种业务消息处理系统的结构示意图；

图3为本发明实施例二所提供的一种业务消息处理方法的流程示意图；

图4为本发明实施例三所提供的一种业务消息处理方法的流程示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

实施例一

图1为本发明实施例一所提供的一种业务消息处理系统的结构示意图，本实施例可适用于基于消息队列和事务型消息对业务信息进行处理的情况，参考图1，本实施例提供的业务消息处理系统包括：消息生产层1、数据中心2和消息订阅层3。其中，数据中心2，用于存储消息队列，消息队列用于存储事务型消息；消息生产层1，用于接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心2的消息队列中；消息订阅层3，用于从数据中心2的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作。

其中，消息队列可以为在消息传输过程中，用于保存消息的中间件。示例性地，消息队列可以包括但不限于ActiveMQ、RabbitMQ、Redis、Kafka以及 RocketMQ等。在本实施例中，消息队列可以为Redis消息队列。

其中，Redis(Remote Dictionary Server，远程数据服务)是一款内存高速缓存数据库，采用C语言编写，是一个key-value(键值存储)数据库。Redis 可以用于数据缓存、事件发布或订阅以及高速队列等。在本实施例中，采用Redis 为消息队列的好处在于：不引入其他中间件和部署，不增加构建系统的额外开销，达到了资源复用的技术效果，提高了资源利用率。事务型消息可以为根据数据库中目标事务的事务状态，确定该消息是否发送的一类消息。在本实施例中，事务型消息中可以包括多种业务服务消息。

其中，目标事务可以为当前需要处理的事务。可选地，目标事务中可以包括多项业务，各项业务之间可以是相互关联的，也可以是没有关联关系的，本实施例对此不作限定。相应的，系统操作信息可以为系统用于实现目标事务中各项业务所执行的各种操作信息。

其中，目标消费操作可以为执行与事务型消息中包括的各类业务服务对应的操作。例如，目标消费操作可以为负责用户完成某笔业务操作，完成业务信息录入并保存；或者，统计用户的操作数据信息，执行汇总计算操作等。

可选地，当消息队列可以为Redis消息队列时，消息订阅层3，用于通过 brpop命令或blpop命令从数据中心2的消息队列中读取事务型消息。

其中，brpop命令或blpop命令可以理解为rpop命令或lpop命令的阻塞版本。rpop命令可以理解为从list的尾部删除元素，并返回删除的元素，lpop命令可以理解为从list中删除并返回第一个元素。一般情况下，当消息“消费者”每隔一段时间(例如，1秒)从数据中心读取消息以进行消费时，会采用rpop 命令或lpop命令进行消息读取，这样的消息处理方式，会在读取消息时存在一定的延时，基于此，本实施例采用brpop命令或blpop命令从数据中心的消息队列中读取事务型消息以进行消费，这样设置的好处在于：当list没有数据时，命令会阻塞等待，直到超时或者消息队列中有消息时结束。

可选地，消息订阅层3，还用于在执行与事务型消息对应的目标消费操作之后，根据目标消费操作确定事务型消息的消息执行状态，并将消息执行状态发送给数据中心2；数据中心2，还用于存储消息执行状态。

具体地，消息生产层1在接收到目标事务的系统操作信息时，根据系统操作信息生成与目标事务对应的事务型消息，并将事务型消息发送至数据中心2 的消息队列中存储，以便可以实现消息解耦、异步以及限流等，然后，通过消息订阅层3从数据中心2的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作，进一步地，在执行对应的目标消费操作后，消息订阅层3根据目标消费操作确定事务型消息的消息执行状态，并将消息执行状态发送给数据中心2。

其中，消息执行状态可以包括消息执行成功以及消息执行失败。

可选地，在消息执行状态为执行成功时，数据中心2，具体用于将事务型消息的消息执行状态标记为执行成功，确定事务型消息的目标消息标识，将目标消息标识与事务型消息对应存储。

其中，目标消息标识可以为用于识别事务型信息当前状态的标识信息。例如，可以采用消息token(令牌)作为目标消息标识。目标消息标识可以用于快速识别其对应的事务型消息的执行状态，以便可以根据识别结果确定后续的各项操作。

在实际应用中，在事务型消息的执行过程中，如果执行成功，则可以生成该事务型消息的目标消息标识，并将该目标消息标识与事务型消息对应存储在数据中心2中，以使用户可以快速查询所需事务型消息的执行状态。

可选地，当消息执行状态为执行失败时，消息订阅层3还用于，再次执行从数据中心2的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作；如果消息执行状态仍为执行失败，则执行与事务型消息对应的回滚逻辑。

其中，回滚逻辑可以为当程序或数据错误时，将程序或数据恢复到上一次正确状态的行为，也可以理解为清除自事务的起点或到某个保存点所做的所有数据修改。

数据中心中的事务型消息正确执行需要四个基本要素：原子性、一致性、隔离性和持久性。其中，原子性可以理解为在执行事务型消息的所有操作中，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。在事务型消息的执行过程中发生错误时，会被回滚到该事务型消息开始前的状态，就像该事务型消息从来没有执行过。一致性可以理解为事务型消息必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务型消息有多少。隔离性可以理解为如果有两个事务型消息，在相同的时间内运行，执行相同的功能，事务型消息的隔离性将确保每一事务型消息在系统中认为只有该事务型消息在使用系统。持久性可以理解为在事务型消息执行完成以后，该事务型消息对数据中心所作的更改便持久的保存在数据中心之中，并不会被回滚。

在实际应用中，为了保障不同服务间数据的一致性，在消息执行状态为执行失败时，消息订阅层3可以再次从数据中心2的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作，进一步地，如果消息执行状态仍为执行失败，则执行与事务型消息对应的回滚逻辑，将消费生产层1以及数据中心2中关于目标事务的事务型消息的执行过程数据全部消除。

可选地，消息订阅层3包括统计服务节点。其中，统计服务节点，用于从消息队列中读取事务型消息并获取与事务型消息对应的目标业务数据，并根据事务型消息对目标业务数据进行统计分析服务。

其中，目标业务数据可以为事务型消息中用于表征各项业务的数据。目标业务数据可以包括业务操作执行结果和业务数据。示例性地，目标业务可以为新增用户业务、账单查询业务或者资金交易业务等。

具体地，通过消息订阅层3中的统计服务节点从消息队列中读取事务型消息，并获取与事务型消息对应的各项业务操作执行结果和业务数据，根据事务型消息对各项业务数据进行统计分析服务。

可选地，业务消息处理系统还包括业务服务层和全局业务控制层。

其中，业务服务层，用于接收到目标业务的业务操作请求，并生成与业务操作对应的操作执行请求，将操作执行请求发送给全局业务控制层；全局业务控制层，用于接收操作执行请求，读取微服务架构中各节点的可用资源，根据可用资源确定操作执行请求对应的业务执行节点，并将业务执行节点发送至业务服务层；业务服务层，还用于通过业务执行节点执行业务操作请求对应的业务操作。

在本实施例中，目标业务可以为当前需要处理的业务。相应的，业务操作请求可以为系统为完成目标业务所需要执行的各项操作请求。操作执行请求可以为用于表征是否可以执行该项操作的请求信息。微服务架构为一种将应用程序构造为一组松散耦合的服务架构。微服务架构可以将应用程序拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这样设置的好处在于：各项服务在工作和出现故障时不会相互影响。业务执行节点可以为用于执行目标业务的业务操作逻辑运算的节点。

可选地，全局业务控制层，具体用于确定可用资源在系统总资源中的资源占用率，如果节点的资源占用率小于预设资源占用上限阈值，则将节点确定为操作执行请求的业务执行节点。

其中，可用资源可以为能够支撑执行目标业务的资源。预设资源占用上限阈值可以为预先设置的，用于对系统总资源中可用资源上限进行限定的值。例如，预设资源占用上限阈值可以为70％，即，当资源占用率达到70％时，则认为该节点不能执行任何业务。

具体地，当全局业务控制层在接收到操作执行请求后，会读取可用资源在系统总资源中的系统占用率，以便可以确定是否可以执行目标业务的操作执行请求，当节点的资源占用率小于预设资源占用上限阈值，则可以任务该节点可以执行目标业务，并将该节点确定为操作执行请求的业务执行节点，这样设置的好处在于：可以实现动态适应性执行，不需要人为手动控制，相比固定预设值，资源利用率更高，适应性更强。

在具体实施中，当业务服务层接收到目标业务的业务操作请求时，会生成与业务操作请求对应的操作执行请求，并发送至全局业务控制层，以使全局业务控制层可以在接收到操作执行请求后，读取微服务架构中各节点的资源使用率，确定各节点的可用资源，并确定符合目标业务的操作执行请求的业务执行节点，将业务执行节点发送至业务服务层，进一步地，业务服务层在接收到业务执行节点后，通过业务执行节点执行业务操作请求对应的业务操作。

可选地，业务服务层，用于执行与业务操作请求对应的业务操作，根据各目标业务对应的业务操作的业务操作结果进行事务数据提交，并在目标事务的事务数据提交之后，将与目标事务对应的系统操作信息发送至消息生产层1。

具体地，业务服务层在执行与业务操作请求对应的业务操作，根据各目标业务的业务操作的业务操作结果，将事务数据提交至数据中心2中，并在目标事务中的各目标业务的数据全部提交之后，将与目标事务对应的系统操作信息发送至消息生产层1，这样设置的好处在于：可以有效减少事务回滚操作，减少了数据库运算开销，提高了系统的性能以及系统响应速率。

本发明实施例提供了一种业务消息处理系统，该系统包括：消息生产层、数据中心和消息订阅层，其中，数据中心，用于存储消息队列，消息队列用于存储事务型消息；消息生产层，用于接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中；消息订阅层，用于从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作，解决了在海量数据处理过程中出现的数据不一致性以及本地事务或分布式事务不适用微服务架构的问题，提高了系统资源利用率，在一定程度上提高了系统的性能和响应速率。

实施例二

图2为本发明实施例二所提供的一种业务消息处理系统的结构示意图，图 3为本发明实施例二所提供的一种业务消息处理方法的流程示意图。本发明实施例为上述各发明实施例的一个优选实施例，参见图2所示，本发明实施例中的业务消息处理系统包括生产者、Redis和消费者。

首先，消费生产层(即，图2中生产者)在接收到系统用户发送的目标事务的系统操作信息(即，图2中前端请求)后，根据系统操作信息生成与目标事务对应的事务型消息(如，续期缴费或者信息导出等)，并将事务型消息通过 LeftPush发送至数据中心的消息队列中(即，图2中Redis)；

消费订阅层(即，图2中消费者)通过RightPop从数据中心的消息队列(即，图2中Redis)中读取事务型消息，执行与事务型消息对应的目标消费操作(如，续期缴费或者信息导出等)，并将消息执行状态发送给数据中心；

当消息执行状态为执行成功时，数据中心(即，图2中Redis)将事务型消息的执行状态标记为执行成功，并使用消息token作为消息标识与事务型消息对应存储(如，图2中消息1对应Token1，消息2对应Token2，消息3对应 Token3)；

当消息执行状态为执行失败时，消费订阅层再次执行从数据中心的消息队列(即，图2中Redis)中读取事务型消息，并执行与事务型消息对应的目标消费操作；

如果消息执行状态仍为执行失败，则执行与事务型消息对应的回滚逻辑，并且，系统用户可以在异步任务查询界面查询错误消息和执行状态等。

以某业务场景为例，参见图3所示，本发明实施例的方法可以包括如下步骤：

1、在业务服务执行前，将业务服务的操作执行请求发送至全局业务控制层 (即，图3中全局任务数控制单元M1)，以使全局业务控制层读取各节点的可用资源，根据可用资源确定符合条件的节点，以实现最大任务数的查询；

2、将符合业务服务执行条件的节点发送至业务服务层(即，图3中业务服务S1)，以实现允许执行通知的发送；

3、业务服务层(即，图3中业务服务S1)通过业务执行节点执行业务操作；

4、根据业务操作的业务操作结果进行事务数据提交，并在事务数据提交后，将对应的系统操作信息发送至消息生产层(即，图3中消息服务M2)；

5、统计服务节点(即，图3中统计服务S2)从消息队列中读取消息，并进行统计分析服务；

6、通知服务节点S3从消息队列中读取消息，并执行相应的消费操作。

本发明实施例提供了一种业务消息处理系统，该系统包括：消息生产层、数据中心和消息订阅层，其中，数据中心，用于存储消息队列，消息队列用于存储事务型消息；消息生产层，用于接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中；消息订阅层，用于从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作，解决了在海量数据处理过程中出现的数据不一致性以及本地事务或分布式事务不适用微服务架构的问题，提高了系统资源利用率，在一定程度上提高了系统的性能和响应速率。

实施例三

图4为本发明实施例三所提供的一种业务消息处理方法的流程示意图，该方法可以应用于上述实施例提供的业务消息处理系统，参见图4，该方法可以包括如下步骤：

S210、通过消息生产层接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中。

其中，所述数据中心用于存储消息队列，所述消息队列用于存储事务型消息。

S220、通过消息订阅层从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作。

本发明实施例的技术方案，通过消息生产层接收目标事务的系统操作信息，并根据系统操作信息生成与目标事务对应的事务型消息，将事务型消息发送到数据中心的消息队列中，进一步地，通过消息订阅层从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作，解决了在海量数据处理过程中数据不一致性以及本地事务或分布式事务不适用微服务架构的问题，提高了系统资源利用率，在一定程度上提高了系统的性能和响应速率。

可选地，在执行与业务操作消息对应的目标消费操作之后，通过消息订阅层根据目标消费操作确定事务型消息的消息执行状态，并将消息执行状态发送给数据中心；其中，所述数据中心，还用于存储所述消息执行状态。

可选地，当消息执行状态为执行成功时，所述数据中心还用于，将事务型消息的消息执行状态标记为执行成功，确定事务型消息的目标消息标识，将目标消息标识与事务型消息对应存储。

可选地，当所述消息执行状态为执行失败时，再次执行通过消息订阅层从数据中心的消息队列中读取事务型消息，并执行与事务型消息对应的目标消费操作的操作；如果消息执行状态仍为执行失败，则执行与事务型消息对应的回滚逻辑。

可选地，所述消息订阅层包括统计服务节点，其中，通过统计服务节点从消息队列中读取事务型消息并获取与事务型消息对应的目标业务数据，并根据事务型消息对目标业务数据进行统计分析服务。

可选地，所述消息队列为Redis消息队列，所述消息订阅层通过brpop命令或blpop命令从数据中心的消息队列中读取事务型消息。

可选地，通过业务服务层执行与业务操作请求对应的业务操作，根据各目标业务对应的业务操作的业务操作结果进行事务数据提交，并在目标事务的事务数据提交之后，将与目标事务对应的系统操作信息发送至消息生产层。

可选地，通过业务服务层接收目标业务的业务操作请求，并生成与业务操作对应的操作执行请求，将操作执行请求发送给全局业务控制层；通过全局业务控制层接收操作执行请求，读取微服务架构中各节点的可用资源，根据可用资源确定操作执行请求对应的业务执行节点，并将业务执行节点发送至业务服务层；业务服务层基于业务执行节点执行业务操作请求对应的业务操作。

可选地，通过全局业务控制层确定可用资源在系统总资源中的资源占用率，如果节点的资源占用率小于预设资源占用上限阈值，则将节点确定为操作执行请求的业务执行节点。

实施例四

本发明实施例四还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种业务消息处理方法，该方法包括：

通过消息生产层接收所述目标事务的系统操作信息，并根据所述系统操作信息生成与所述目标事务对应的事务型消息，将所述事务型消息发送到数据中心的消息队列中，其中，所述数据中心用于存储消息队列，所述消息队列用于存储事务型消息。

通过消息订阅层从所述数据中心的消息队列中读取所述事务型消息，并执行与所述事务型消息对应的目标消费操作。

本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器 (CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

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

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

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (10)

1.一种业务消息处理系统，其特征在于，包括：消息生产层、数据中心和消息订阅层，其中，

所述数据中心，用于存储消息队列，所述消息队列用于存储事务型消息；

所述消息生产层，用于接收目标事务的系统操作信息，并根据系统操作信息生成与所述目标事务对应的事务型消息，将所述事务型消息发送到所述数据中心的消息队列中；

所述消息订阅层，用于从所述数据中心的消息队列中读取所述事务型消息，并执行与所述事务型消息对应的目标消费操作。

2.根据权利要求1所述的系统，其特征在于，所述消息订阅层，还用于：

在执行与所述事务型消息对应的目标消费操作之后，根据所述目标消费操作确定所述事务型消息的消息执行状态，并将所述消息执行状态发送给所述数据中心；

所述数据中心，还用于存储所述消息执行状态。

3.根据权利要求2所述的系统，其特征在于，所述数据中心，具体用于：

当所述消息执行状态为执行成功时，将所述事务型消息的消息执行状态标记为执行成功，确定所述事务型消息的目标消息标识，将所述目标消息标识与所述事务型消息对应存储。

4.根据权利要求2所述的系统，其特征在于，所述消息订阅层，还用于：

当所述消息执行状态为执行失败时，再次执行从所述数据中心的消息队列中读取所述事务型消息，并执行与所述事务型消息对应的目标消费操作；

如果所述消息执行状态仍为执行失败，则执行与所述事务型消息对应的回滚逻辑。

5.根据权利要求1所述的系统，其特征在于，所述消息订阅层包括统计服务节点，其中，

所述统计服务节点，用于从所述消息队列中读取所述事务型消息并获取与所述事务型消息对应的目标业务数据，并根据所述事务型消息对所述目标业务数据进行统计分析服务。

6.根据权利要求1所述的系统，其特征在于，所述消息队列为Redis消息队列，所述消息订阅层，用于通过brpop命令或blpop命令从所述数据中心的消息队列中读取所述事务型消息。

7.根据权利要求1所述的系统，其特征在于，还包括：业务服务层，其中，

所述业务服务层，用于执行与所述业务操作请求对应的业务操作，根据各目标业务对应的所述业务操作的业务操作结果进行事务数据提交，并在所述目标事务的事务数据提交之后，将与所述目标事务对应的系统操作信息发送至所述消息生产层。

8.根据权利要求1所述的系统，其特征在于，还包括：全局业务控制层；其中，

所述业务服务层，用于接收到目标业务的业务操作请求，并生成与所述业务操作对应的操作执行请求，将所述操作执行请求发送给所述全局业务控制层；

所述全局业务控制层，用于接收所述操作执行请求，读取微服务架构中各节点的可用资源，根据所述可用资源确定所述操作执行请求对应的业务执行节点，并将所述业务执行节点发送至所述业务服务层；

所述业务服务层，还用于通过所述业务执行节点执行所述业务操作请求对应的业务操作。

9.根据权利要求8所述的系统，其特征在于，所述全局业务控制层，具体用于：

确定所述可用资源在系统总资源中的资源占用率，如果所述节点的所述资源占用率小于预设资源占用上限阈值，则将所述节点确定为所述操作执行请求的业务执行节点。

10.一种业务消息处理方法，其特征在于，包括：

通过消息生产层接收所述目标事务的系统操作信息，并根据所述系统操作信息生成与所述目标事务对应的事务型消息，将所述事务型消息发送到数据中心的消息队列中，其中，所述数据中心用于存储消息队列，所述消息队列用于存储事务型消息。

通过消息订阅层从所述数据中心的消息队列中读取所述事务型消息，并执行与所述事务型消息对应的目标消费操作。

Images