CN109542639B - 一种保障微服务调用数据一致性的处理方法、处理装置 - Google Patents

Abstract

本发明提出了一种保障微服务调用数据最终一致性的处理方法、处理装置。其中，处理方法包括：获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚。以隔离事务的管理范围以及提供异常处理机制，补偿错误操作的数据，使得业务向前恢复或避免向下发展，达到数据最终一致的效果。

Description

一种保障微服务调用数据一致性的处理方法、处理装置

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种保障微服务调用数据一致性的处理方法、处理装置。

背景技术

微服务架构下多个服务之间通过RestFul接口或者RPC框架进行调用，一次完整的业务调用往往需要多个微服务的参与，包括如图1和图2所示的两种场景，这两种场景下，如果中途调用出错，会造成整体业务的失败。此种架构下，每个微服务使用独立的DB(Database，数据库)存储数据，各个业务的DB间相互隔离，不允许直接跨库访问。那么，传统的使用数据库本地事务ACID(Atomicity Consistency Isolation Durability，原子性、一致性、隔离性、持久性)特性保证数据一致的方案不再适用，各个服务间可能由于网络超时、业务异常等问题造成不能同步的提交或者回滚对应的数据库操作，造成各个服务对应数据的不一致。

相关技术的解决方案中，可以使用全局数据库事务的方式解决此问题，其解决思路如图3所示，其提供统一的数据管理器，在业务最开始时，各个服务执行第一阶段，准备各个操作需要资源，开启事务并执行，不提交事务，如遇到异常，事务管理器通知各个业务回滚，第二阶段，事务管理器统一协调各个节点提交事务。此种传统的全局数据库事务方案，逐步暴露出一些严重的问题，例如：(1)同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型的，当参与者占有公共资源时，其他第三方节点访问公共资源处于阻塞状态；(2)单点问题：由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去，尤其在第二阶段，协调者发生故障，所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。(3)数据不一致：在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，导致只有一部分参与者接受到了commit请求，整个分布式系统出现了数据部不一致性的现象。同时，XA规范(资源管理器与事务管理器的接口标准)下的两阶段提交方案，其性能较低，很容易成为互联网应用中的瓶颈，所以，全局数据库事务方案在微服务架构下的互联网应用不太可取。

由此，基于消息或者事件通知的方案应运而生，此方案采用消息中间件或者事件中心的方式，使用消息和事件异步的通知服务提供方执行业务。此种方案避免了跨库的事务管理问题，但也抛出了一些其他问题。针对消息中间件方案，问题诸如：(1)本地业务事务和消息发送任务的一致性问题：各个微服务内部，业务操作使用本地数据库事务控制内部的一致性，发送消息或者接收消息应该在事务的内部控制，但是由于网络延时问题，消息未成功到达或接收，会造成本地事务和消息投递不一致情况；(2)消息可靠发送，消息重试和幂等性问题：消息在发送和接收时，有可能不能一次性成功，会产生重复消息，重复消息的接收会造成业务重复执行，造成数据错误；(3)消息中间件权限管理问题：服务基于消息队列编码，MQ(Message Queue，消息队列)中间件需要暴露给服务调用方，MQ中间件可能由不同的团队维护，中间件地址和端口、用户名密码的直接给多调用方暴露，不够安全；(4)报错事务上报和云端管控问题：本地事务执行失败，需要有统一的云端管控界面，查看和管理全局业务调用的情况，进行重试或者分析操作，各个端和云端的数据同步是难点问题。

除了上述两种方案，业界还推出了TCC(Try Confirm Cancel)事务的最终一致性方案，但此方案对业务开发人员的技术要求较高，需要对Try阶段进行完善的设计和代码编写，业务侵入性较大，不太容易实施和落地。

发明内容

本发明旨在解决现有技术或相关技术中存在的微服务调用数据最终一致性的技术问题。

为此，本发明的一个方面在于提出了一种保障微服务调用数据一致性的处理方法。

本发明的另一个方面在于提出了一种保障微服务调用数据一致性的处理装置。

有鉴于此，根据本发明的一个方面，提出了一种保障微服务调用数据一致性的处理方法，包括：获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚。

本发明提供的保障微服务调用数据一致性的处理方法，提供标记信息以标记全局事务的开启和加入，每个全局事务中包括不同的微服务，以隔离事务的管理范围。当出现某一微服务异常调用时，对该异常微服务调用进行异步返回异常和通知上游，以及进行可靠消息投递通知下游，即提供异常处理机制，补偿错误操作的数据，使得业务向前恢复或避免向下发展，达到数据最终一致的效果。

根据本发明的上述保障微服务调用数据一致性的处理方法，还可以具有以下技术特征：

在上述技术方案中，优选地，还包括：当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；执行业务调用任务信息，同时利用消息中间件发送待发送任务信息；接收对待发送任务信息的确认信息，将待发送任务信息的发送状态标记为发送成功。

在该技术方案中，消息传递的载体为类似RabbitMQ的消息中间件，在消息的发送和接收过程中可能出现网络异常或调用超时问题，为避免此问题产生，在业务调用时，记录待发送消息到数据库，并不真正发送待发送消息，而是在执行业务调用任务信息的同时利用消息中间件发送待发送任务信息，以保证待发送消息和业务调用同步，由此避免了任务执行成功但消息未成功发送，或者消息发送成功但任务由于发送消息超时异常回滚等问题。并且，发送过程中可以使用消息中间件的确认机制，保证消息最终可达。

在上述任一技术方案中，优选地，还包括：当待发送任务信息发送失败时，在执行下一业务调用任务时重新发送待发送任务信息。

在该技术方案中，提供消息发送重试机制，增加事务的成功概率。

在上述任一技术方案中，优选地，还包括：当任一微服务接收业务调用任务信息时，将业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识进行比对；当业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识不重复时，处理业务调用任务信息；将业务调用任务信息的状态标记为处理成功，以及发送对业务调用任务信息的确认信息。

在该技术方案中，根据全局唯一信息标识进行幂等性校验，具体为，在业务调用任务信息发送时会生成全局唯一信息标识，业务调用任务信息接收后且在处理之前，通过全局唯一信息标识的唯一性对比来保证信息只被执行一次，处理过的信息直接反馈确认信息，不再重复处理，避免业务重复消费消息、多次操作，保证幂等性。业务在处理消息时，业务逻辑正常，且正确修改消息接收状态后，才发送消息的ACK(Acknowledgement，确认字符)标记，保证消息被正常处理。

在上述任一技术方案中，优选地，还包括：为每个微服务进行AccessKey认证和Secret的认证，使每个微服务与消息中间件进行安全连接。

在该技术方案中，利用RabbitMQ的认证扩展机制，集成认证中心的AccessKey和Secret的认证。RabbitMQ支持使用扩展的认证机制，提供自有的MQ连接认证服务，禁止使用MQ自身生成的简单用户名密码进行连接，利用认证中心统一给各个微服务提供的AccessKey和Secret进行TCP(Transmission Control Protocol，传输控制协议)连接发送消息，此过程不需要业务关心，保障连接的安全性，且提供的事务控制由软件开发工具包统一控制。

在上述任一技术方案中，优选地，还包括：为每个微服务配置消息中间件的地址。

在该技术方案中，支持为每个微服务配置专属的消息中间件地址，通过配置中心统一管理并下发到服务调用方，框架的软件开发工具包自动发现需要调用的服务对应的消息中间件地址并建立链接，待全局事务中任一微服务发生异常时，发送补偿通知到下游节点时使用。支持微服务不同的环境对应不同的中间件地址，服务的不同环境可以配置成不同性能的MQ实例，应对生产环境的压力和日常的压力测试。

在上述任一技术方案中，优选地，还包括：对异常微服务、异常信息进行显示，以及生成对发送失败信息的重新发送指令；与云端进行数据同步，向云端上报异常微服务、异常信息，以及获取云端的处理指令。

在该技术方案中，各个服务节点的错误事务，最终统一由软件开发工具包上报到统一管控端，管理端界面中可以查看整体的调用链路中哪些环节发生了错误，并查看错误事务的原因和调用链路。根据具体原因来下发不同的处理指令，软件开发工具包定时从管控端拉取属于自身的错误事务处理指令，进行消息的重发和重收，从而驱动业务继续进行。软件开发工具包在和云端数据同步时，会更新数据的版本和上传下载状态，利用数据库乐观锁的机制保证数据安全性。多微服务实例场景下，使用Redis实现的互斥锁或者数据库的悲观锁机制强制限制。

根据本发明的另一个方面，提出了一种保障微服务调用数据一致性的处理装置，包括：存储器，用于存储计算机程序；处理器，用于执行计算机程序以：获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚。

本发明提供的保障微服务调用数据一致性的处理装置，提供标记信息以标记全局事务的开启和加入，每个全局事务中包括不同的微服务，以隔离事务的管理范围。当出现某一微服务异常调用时，对该异常微服务调用进行异步返回异常和通知上游，以及进行可靠消息投递通知下游，即提供异常处理机制，补偿错误操作的数据，使得业务向前恢复或避免向下发展，达到数据最终一致的效果。

根据本发明的上述保障微服务调用数据一致性的处理装置，还可以具有以下技术特征：

在上述技术方案中，优选地，处理器，还用于执行计算机程序以：当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；执行业务调用任务信息，同时利用消息中间件发送待发送任务信息；接收对待发送任务信息的确认信息，将待发送任务信息的发送状态标记为发送成功。

在该技术方案中，消息传递的载体为类似RabbitMQ的消息中间件，在消息的发送和接收过程中可能出现网络异常或调用超时问题，为避免此问题产生，在业务调用时，记录待发送消息到数据库，并不真正发送待发送消息，而是在执行业务调用任务信息的同时利用消息中间件发送待发送任务信息，以保证待发送消息和业务调用同步，由此避免了任务执行成功但消息未成功发送，或者消息发送成功但任务由于发送消息超时异常回滚等问题。并且，发送过程中可以使用消息中间件的确认机制，保证消息最终可达。

在上述任一技术方案中，优选地，处理器，还用于执行计算机程序以：当待发送任务信息发送失败时，在执行下一业务调用任务时重新发送待发送任务信息。

在该技术方案中，提供消息发送重试机制，增加事务的成功概率。

在上述任一技术方案中，优选地，处理器，还用于执行计算机程序以：当任一微服务接收业务调用任务信息时，将业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识进行比对；当业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识不重复时，处理业务调用任务信息；将业务调用任务信息的状态标记为处理成功，以及发送对业务调用任务信息的确认信息。

在该技术方案中，根据全局唯一信息标识进行幂等性校验，具体为，在业务调用任务信息发送时会生成全局唯一信息标识，业务调用任务信息接收后且在处理之前，通过全局唯一信息标识的唯一性对比来保证信息只被执行一次，处理过的信息直接反馈确认信息，不再重复处理，避免业务重复消费消息、多次操作，保证幂等性。业务在处理消息时，业务逻辑正常，且正确修改消息接收状态后，才发送消息的ACK标记，保证消息被正常处理。

在上述任一技术方案中，优选地，处理器，还用于执行计算机程序以：为每个微服务进行AccessKey认证和Secret的认证，使每个微服务与消息中间件进行安全连接。

在该技术方案中，利用RabbitMQ的认证扩展机制，集成认证中心的AccessKey和Secret的认证。RabbitMQ支持使用扩展的认证机制，提供自有的MQ连接认证服务，禁止使用MQ自身生成的简单用户名密码进行连接，利用认证中心统一给各个微服务提供的AccessKey和Secret进行TCP(Transmission Control Protocol，传输控制协议)连接发送消息，此过程不需要业务关心，保障连接安全性，且提供的事务控制由软件开发工具包统一控制。

在上述任一技术方案中，优选地，处理器，还用于执行计算机程序以：为每个微服务配置消息中间件的地址。

在该技术方案中，支持为每个微服务配置专属的消息中间件地址，通过配置中心统一管理并下发到服务调用方，框架的软件开发工具包自动发现需要调用的服务对应的消息中间件地址并建立链接，待全局事务中任一微服务发生异常时，发送补偿通知到下游节点时使用。支持微服务不同的环境对应不同的中间件地址，服务的不同环境可以配置成不同性能的MQ实例，应对生产环境的压力和日常的压力测试。

在上述任一技术方案中，优选地，处理器，还用于执行计算机程序以：对异常微服务、异常信息进行显示，以及生成对发送失败信息的重新发送指令；与云端进行数据同步，向云端上报异常微服务、异常信息，以及获取云端的处理指令。

在该技术方案中，各个服务节点的错误事务，最终统一由软件开发工具包上报到统一管控端，管理端界面中可以查看整体的调用链路中哪些环节发生了错误，并查看错误事务的原因和调用链路。根据具体原因来下发不同的处理指令，软件开发工具包定时从管控端拉取属于自身的错误事务处理指令，进行消息的重发和重收，从而驱动业务继续进行。软件开发工具包在和云端数据同步时，会更新数据的版本和上传下载状态，利用数据库乐观锁的机制保证数据安全性。多微服务实例场景下，使用Redis实现的互斥锁或者数据库的悲观锁机制强制限制。

本发明的附加方面和优点将在下面的描述部分中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1示出了相关技术中的一个业务调用场景的示意图；

图2示出了相关技术中的另一个业务调用场景的示意图；

图3示出了相关技术中的全局数据库事务方式的示意图；

图4示出了本发明的一个实施例的保障微服务调用数据一致性的处理方法的流程示意图；

图5示出了本发明的另一个实施例的保障微服务调用数据一致性的处理方法的流程示意图；

图6示出了本发明的再一个实施例的保障微服务调用数据一致性的处理方法的流程示意图；

图7示出了本发明的一个具体实施例的一致性处理方案的整体调用框架示意图；

图8示出了本发明的一个具体实施例的全局事务示意图；

图9示出了本发明的一个具体实施例的异常处理示意图；

图10示出了本发明的一个具体实施例的重试机制示意图；

图11示出了本发明的一个具体实施例的连接认证示意图；

图12示出了本发明的一个具体实施例的配置管理示意图；

图13示出了本发明的一个具体实施例的统一管控示意图；

图14示出了本发明的一个实施例的保障微服务调用数据一致性的处理装置的示意框图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本发明的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不限于下面公开的具体实施例的限制。

本发明第一方面的实施例，提出一种保障微服务调用数据一致性的处理方法，图4示出了本发明的一个实施例的保障微服务调用数据一致性的处理方法的流程示意图。其中，该方法包括：

步骤402，获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；

步骤404，对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚。

本发明提供的保障微服务调用数据一致性的处理方法，提供标记信息以标记全局事务的开启和加入，每个全局事务中包括不同的微服务，以隔离事务的管理范围。当出现某一微服务异常调用时，对该异常微服务调用进行异步返回异常和通知上游，以及进行可靠消息投递通知下游，即提供异常处理机制，补偿错误操作的数据，使得业务向前恢复或避免向下发展，达到数据最终一致的效果。

图5示出了本发明的另一个实施例的保障微服务调用数据一致性的处理方法的流程示意图。其中，该方法包括：

步骤502，获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；

步骤504，对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚；

步骤506，当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；执行业务调用任务信息，同时利用消息中间件发送待发送任务信息；接收对待发送任务信息的确认信息，将待发送任务信息的发送状态标记为发送成功。

在该实施例中，消息传递的载体为类似RabbitMQ的消息中间件，在消息的发送和接收过程中可能出现网络异常或调用超时问题，为避免此问题产生，在业务调用时，记录待发送消息到数据库，并不真正发送待发送消息，而是在执行业务调用任务信息的同时利用消息中间件发送待发送任务信息，以保证待发送消息和业务调用同步，由此避免了任务执行成功但消息未成功发送，或者消息发送成功但任务由于发送消息超时异常回滚等问题。并且，发送过程中可以使用消息中间件的确认机制，保证消息最终可达。

图6示出了本发明的再一个实施例的保障微服务调用数据一致性的处理方法的流程示意图。其中，该方法包括：

步骤602，获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；

步骤604，对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚；

步骤606，当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；执行业务调用任务信息，同时利用消息中间件发送待发送任务信息；接收对待发送任务信息的确认信息，将待发送任务信息的发送状态标记为发送成功；

步骤608，当待发送任务信息发送失败时，在执行下一业务调用任务时重新发送待发送任务信息。

在该实施例中，提供消息发送重试机制，增加事务的成功概率。

优选地，还包括：当任一微服务接收业务调用任务信息时，将业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识进行比对；当业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识不重复时，处理业务调用任务信息；将业务调用任务信息的状态标记为处理成功，以及发送对业务调用任务信息的确认信息。

在该实施例中，根据全局唯一信息标识进行幂等性校验，具体为，在业务调用任务信息发送时会生成全局唯一信息标识，业务调用任务信息接收后且在处理之前，通过全局唯一信息标识的唯一性对比来保证信息只被执行一次，处理过的信息直接反馈确认信息，不再重复处理，避免业务重复消费消息、多次操作，保证幂等性。业务在处理消息时，业务逻辑正常，且正确修改消息接收状态后，才发送消息的ACK标记，保证消息被正常处理。

优选地，还包括：为每个微服务进行AccessKey认证和Secret的认证，使每个微服务与消息中间件进行安全连接。

在该实施例中，利用RabbitMQ的认证扩展机制，集成认证中心的AccessKey和Secret的认证。RabbitMQ支持使用扩展的认证机制，提供自有的MQ连接认证服务，禁止使用MQ自身生成的简单用户名密码进行连接，利用认证中心统一给各个微服务提供的AccessKey和Secret进行TCP(Transmission Control Protocol，传输控制协议)连接发送消息，此过程不需要业务关心，保障连接安全性，且提供的事务控制由软件开发工具包统一控制。

优选地，还包括：为每个微服务配置消息中间件的地址。

在该实施例中，支持为每个微服务配置专属的消息中间件地址，通过配置中心统一管理并下发到服务调用方，框架的软件开发工具包自动发现需要调用的服务对应的消息中间件地址并建立链接，待全局事务中任一微服务发生异常时，发送补偿通知到下游节点时使用。支持微服务不同的环境对应不同的中间件地址，服务的不同环境可以配置成不同性能的MQ实例，应对生产环境的压力和日常的压力测试。

还包括：对异常微服务、异常信息进行显示，以及生成对发送失败信息的重新发送指令；与云端进行数据同步，向云端上报异常微服务、异常信息，以及获取云端的处理指令。

在该实施例中，各个服务节点的错误事务，最终统一由软件开发工具包上报到统一管控端，管理端界面中可以查看整体的调用链路中哪些环节发生了错误，并查看错误事务的原因和调用链路。根据具体原因来下发不同的处理指令，软件开发工具包定时从管控端拉取属于自身的错误事务处理指令，进行消息的重发和重收，从而驱动业务继续进行。软件开发工具包在和云端数据同步时，会更新数据的版本和上传下载状态，利用数据库乐观锁的机制保证数据安全性。多微服务实例场景下，使用Redis实现的互斥锁或者数据库的悲观锁机制强制限制。

本发明实施例是针对微服务场景下数据最终一致性的问题，微服务架构在当前许多互联网应用场景使用，其小团队开发、快速迭代、高内聚低耦合、服务自治、持续集成部署、容器化等优势给开发者和运维人员带来巨大的便利，但同时其架构特点也引出一些诸如微服务稳定性控制、数据一致性等问题，本方案主要针对数据一致性问题展开讨论。提出一种适用同步RPC调用的一致性处理方案，基于可靠消息投递来触发异常业务的回滚调用，其整体的调用框架如图7所示：微服务(微服务A、微服务B、微服务C)间通过服务治理平台的RPC框架进行调用，调用过程中开启全局事务或者加入全局事务，每一步骤的本地调用过程中，在记录业务数据到数据库时，同时记录事务的关联关系入库。调用过程中传递事务上下文信息，调用成功后更新本地事务和关联关系的状态。

一旦业务出错，在本地数据回滚同时，应返回特殊的异常通知上游进行回滚动作，同时记录待发送消息入库，以待通知其下游或者已调用分支的回滚操作。上游接收到异常后，触发本节点回滚动作，根据事务开始时记录的事务关联关系，发送异步可靠消息通知下游或其他分支进行回滚。

本发明实施例在保证微服务调用下的数据最终一致性，解决以下几个问题：

问题一：事务控制范围和异常处理机制的问题。

本发明实施例提供一种非数据库方式的类似“全局事务管理”，标识事务的开始或者加入上下文中已有的全局事务，且需要处理事务上下文传递的问题，将信息逐级向下传递。当业务调用链的某个环节或者分支出错时，需要通知上游或者其他节点回滚业务，补偿错误操作的数据。

问题二：本地事务和消息发送、接收任务的同步问题。

消息传递的载体为类似RabbitMQ的消息中间件，消息的发送和接收过程中可能出现网络异常或调用超时问题，业务本地的数据库操作和消息发送、接收的一致性问题需要解决。类似本地事务执行成功但消息未成功发送、消息发送成功但本地事务由于发送消息超时异常回滚等问题不允许出现。

问题三：任务重试机制和幂等性问题。

消息的发送应该支持重试机制，增加事务的成功概率，但消息有可能出现重复，消息接收方必须识别消息是否已经执行，避免业务重复消费消息，多次操作。且需要提供消息处理的幂等性保障。

问题四：服务对应的消息中间件权限和扩展问题。

微服务架构下，服务提供者如果利用消息来接收补偿或回滚操作通知，应该提供消息中间件的地址，供调用者连接和发送消息。但一旦暴露连接地址和用户名密码，中间件的可维护性大大降低且不安全，需要提供一种安全的消息中间件连接和认证的方式。同时，各个接入此一致性方案的服务提供者，应允许配置各自的特定的消息中间件实例，以满足不同的压力和连接数标准；甚至应该满足开发、测试、灰度、生产等不同环境不同配置的要求。需要解决消息中间件灵活配置的要求。

问题五：错误事务在客户端和云端的同步问题。

此一致性方案真正需要应用的场景即事务控制范围内，出现错误的场景。所以，方案需要在业务调用链路出现错误时尽量的进行重试，重试依然失败则应记录错误事务的调用上下文和相关业务参数，上报到统一的管控中心；管控中心应能下达针对某个全局事务的重试或者忽略命令，客户端自动获取到命令进行重试或其它操作，促使异常业务向前恢复。客户端和管控端的数据如何正确的进行同步是此环节的关键点和难点。

问题一的解决方案：提供注解方式标记事务开启和加入，隔离事务的管理范围；异步返回异常通知上游，可靠消息投递通知下游。

以图8为例，全局事务从服务A开启，以注解方式标记，在服务A、服务B、服务C、服务D中属于同步调用，为同一事务控制范围，通过其他消息机制或者RestFul机制调用后，开启另外一个全局事务，服务E、服务G、服务F、服务H属于同步调用，在同一全局事务控制范围。在全局事务1和全局事务2中，分别采用本发明实施例的一致性保证方案。

某个节点发生异常，同步返回异常，上游接收到异常进行回滚处理并通知它的上游和分支回滚，本节点处理异常并通知已调用过的分支回滚，示例如图9所示：同步调用，逐级抛异常并回滚本地事务，框架异步通知子事务，子事务确保补偿成功后确认补偿消息已消费。在4中调用链出错，此时服务E已提交本地事务，服务F存在两种情况，已提交本地事务或本地事务已回滚，服务C捕捉到异常后根据事务关系表取得服务C当前已经发生的子事务服务E、服务F，并向服务E、服务F发送异步补偿消息，服务E、服务F服务执行补偿方法后标记消息已处理，同时更改事务状态。服务F本地事务回滚，说明异常是由服务F抛出，此时服务F本地事务已回滚，同时需要发送可靠的补偿消息给服务F的子事务。

问题二的解决方案：本地业务和记录发送消息、接收消息等动作处于同一本地事务。

由于在消息发送和接收环节可能由于网络问题造成不一致，为避免此问题产生，在业务调用时，框架只记录待发送消息到数据库，并不真正发送消息，保证消息待发送记录和业务调用同步的成功或者失败。方案的SDK(Software Development Kit，软件开发工具包)根据异步执行的调度任务，从数据库中取出待发送消息，可重试的真正发送消息到消息队列，发送过程中可以使用消息中间件的确认机制，接收过程中可以利用消息中间件的ACK机制，保证消息最终可达。

问题三的解决方案：消息的发送和消息接收提供重试机制，消息接收端根据全局唯一的消息ID进行幂等性校验。

消息发送时，能够根据框架提供的SDK中的配置，将待发送任务进行发送，发送时生成全局唯一的消息ID，偶发网络异常导致发送失败时，不更新待发送消息的状态，下次调度任务时根据重试次数的配置重新发送。

如图10所示，发送消息到消息队列时，利用事务消息机制和消息队列的回调机制，保证消息一定到达RabbitMQ中间件并持久化后，更新数据库中的消息发送任务状态。

消息接收时，同理使用重试机制进行处理，利用RabbitMQ中间件的ACK机制，接收到确认后才从队列中标记消息接收成功。业务在处理消息时，业务逻辑正常，且正确修改消息接收状态后，才发送消息的ACK标记，保证消息被正常处理。

消息接收后在处理业务之前，和已接收消息进行比对，全局唯一的消息ID的唯一性来保证消息只被执行一次，处理过的消息直接ACK，不再重复处理，保证幂等性。

问题四的解决方案：利用RabbitMQ的认证扩展机制，集成认证中心的AccessKey和Secret的认证，利用配置中心动态管理各个微服务不同环境对应的消息中间件地址；

RabbitMQ支持使用扩展的认证机制，如图11所示，本发明具体实施例提供自有的RabbitMQ连接认证服务，禁止使用RabbitMQ自身生成的简单用户名密码进行连接，利用认证中心统一给各个微服务提供的AccessKey和Secret进行TCP(Transmission ControlProtocol，传输控制协议)连接发送消息，此过程不需要业务关心，本方案提供的事务控制由SDK统一控制。

同时，本发明具体实施例支持每个微服务配置专属的消息中间件地址，如图12所示，通过配置中心统一管理并下发到服务调用方，框架的SDK自动发现需要调用的服务对应的消息中间件地址并建立链接，待全局事务中本节点发生异常时，发送补偿通知到下游节点时使用。

支持微服务不同的环境对应不同的中间件地址，服务的不同环境可以配置成不同性能的MQ实例，应对生产环境的压力和日常的压力测试。

问题五的解决方案：提供云端全局事务统一管控中心，查看事务状态和下发重试命令；SDK提供和云端数据同步功能，及时上报错误事务和拉取云端指令；

如图13所示，各个服务节点的错误事务，最终统一由SDK上报到统一管控端，管理界面中可以查看整体的调用链路中哪些环节发生了错误，并查看错误事务的原因和调用链路。根据具体原因来下发不同的处理指令，SDK定时从管控端拉取属于自身的错误事务处理指令，进行消息的重发和重收，从而驱动业务继续进行。SDK在和云端数据同步时，会更新数据的版本和上传下载状态，利用数据库乐观锁的机制保证数据安全性。多微服务实例场景下，使用Redis实现的互斥锁或者数据库的悲观锁机制强制限制。

本发明具体实施例提出的方案，具有以下特点：

(1)高性能，基于异步的消息通知，避免全局事务管理器的介入；

(2)分布式控制，在各个节点自行控制事务，避免了单点问题；

(3)错误事务可重试，保证业务可以向前恢复，达到最终执行状态；

(4)提供幂等性保证，不需要业务处理重复消息问题。

同时，此方案相对于类似TCC的数据一致性方案的优势在于：

(1)低侵入性，方案提供低侵入性的编程方式，以适配组件的方式进行扩展；

(2)业务接入简单，对开发者要求低，不需要编写大量的Try阶段代码。

在微服务架构推行过程中，本发明具体实施例的最终数据一致性方案解决了业务上使用微服务框架对于数据不一致的担忧；达到了错误发生时，整体业务可向前恢复的效果。同时在业务侵入性上降到最低，使得业务开发者对方案的实现细节透明无感知，最少开发量的情况下启用微服务调用的事务一致性控制。

本发明第二方面的实施例，提出一种保障微服务调用数据一致性的处理装置，图14示出了本发明的一个实施例的保障微服务调用数据一致性的处理装置140的示意框图。其中，该装置140包括：

存储器142，用于存储计算机程序；

处理器144，用于执行计算机程序以：

获取标记信息，根据标记信息确定开启或加入的多个全局事务，其中每个全局事务包括一个或多个微服务，且每个全局事务包括的微服务不相同；对于任一全局事务，当检测到全局事务中存在异常微服务调用时，处理异常微服务的异常信息，同时将异常信息发送给异常微服务的上游微服务和下游微服务，使上游微服务进行本地事务回滚和异常信息通知，以及使下游微服务进行本地事务回滚。

本发明提供的保障微服务调用数据一致性的处理装置140，提供标记信息以标记全局事务的开启和加入，每个全局事务中包括不同的微服务，以隔离事务的管理范围。当出现某一微服务异常调用时，对该异常微服务调用进行异步返回异常和通知上游，以及进行可靠消息投递通知下游，即提供异常处理机制，补偿错误操作的数据，使得业务向前恢复或避免向下发展，达到数据最终一致的效果。

优选地，处理器144，还用于执行计算机程序以：当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；执行业务调用任务信息，同时利用消息中间件发送待发送任务信息；接收对待发送任务信息的确认信息，将待发送任务信息的发送状态标记为发送成功。

在该实施例中，消息传递的载体为类似RabbitMQ的消息中间件，在消息的发送和接收过程中可能出现网络异常或调用超时问题，为避免此问题产生，在业务调用时，记录待发送消息到数据库，并不真正发送待发送消息，而是在执行业务调用任务信息的同时利用消息中间件发送待发送任务信息，以保证待发送消息和业务调用同步，由此避免了任务执行成功但消息未成功发送，或者消息发送成功但任务由于发送消息超时异常回滚等问题。并且，发送过程中可以使用消息中间件的确认机制，保证消息最终可达。

优选地，处理器144，还用于执行计算机程序以：当待发送任务信息发送失败时，在执行下一业务调用任务时重新发送待发送任务信息。

在该实施例中，提供消息发送重试机制，增加事务的成功概率。

优选地，处理器144，还用于执行计算机程序以：当任一微服务接收业务调用任务信息时，将业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识进行比对；当业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识不重复时，处理业务调用任务信息；将业务调用任务信息的状态标记为处理成功，以及发送对业务调用任务信息的确认信息。

在该实施例中，根据全局唯一信息标识进行幂等性校验，具体为，在业务调用任务信息发送时会生成全局唯一信息标识，业务调用任务信息接收后且在处理之前，通过全局唯一信息标识的唯一性对比来保证信息只被执行一次，处理过的信息直接反馈确认信息，不再重复处理，避免业务重复消费消息、多次操作，保证幂等性。业务在处理消息时，业务逻辑正常，且正确修改消息接收状态后，才发送消息的ACK标记，保证消息被正常处理。

优选地，处理器144，还用于执行计算机程序以：为每个微服务进行AccessKey认证和Secret的认证，使每个微服务与消息中间件进行安全连接。

在该实施例中，利用RabbitMQ的认证扩展机制，集成认证中心的AccessKey和Secret的认证。RabbitMQ支持使用扩展的认证机制，提供自有的MQ连接认证服务，禁止使用MQ自身生成的简单用户名密码进行连接，利用认证中心统一给各个微服务提供的AccessKey和Secret进行TCP(Transmission Control Protocol，传输控制协议)连接发送消息，此过程不需要业务关心，保障连接安全性，且提供的事务控制由软件开发工具包统一控制。

优选地，处理器144，还用于执行计算机程序以：为每个微服务配置消息中间件的地址。

在该实施例中，支持为每个微服务配置专属的消息中间件地址，通过配置中心统一管理并下发到服务调用方，框架的软件开发工具包自动发现需要调用的服务对应的消息中间件地址并建立链接，待全局事务中任一微服务发生异常时，发送补偿通知到下游节点时使用。支持微服务不同的环境对应不同的中间件地址，服务的不同环境可以配置成不同性能的MQ实例，应对生产环境的压力和日常的压力测试。

优选地，处理器144，还用于执行计算机程序以：对异常微服务、异常信息进行显示，以及生成对发送失败信息的重新发送指令；与云端进行数据同步，向云端上报异常微服务、异常信息，以及获取云端的处理指令。

在该实施例中，各个服务节点的错误事务，最终统一由软件开发工具包上报到统一管控端，管理端界面中可以查看整体的调用链路中哪些环节发生了错误，并查看错误事务的原因和调用链路。根据具体原因来下发不同的处理指令，软件开发工具包定时从管控端拉取属于自身的错误事务处理指令，进行消息的重发和重收，从而驱动业务继续进行。软件开发工具包在和云端数据同步时，会更新数据的版本和上传下载状态，利用数据库乐观锁的机制保证数据安全性。多微服务实例场景下，使用Redis实现的互斥锁或者数据库的悲观锁机制强制限制。

在本说明书的描述中，术语“第一”、“第二”仅用于描述的目的，而不能理解为指示或暗示相对重要性，除非另有明确的规定和限定；术语“连接”、“安装”、“固定”等均应做广义理解，例如，“连接”可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

在本说明书的描述中，术语“一个实施例”、“一些实施例”、“具体实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或实例。而且，描述的具体特征、结构、材料或特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种保障微服务调用数据一致性的处理方法，其特征在于，包括：

获取标记信息，根据所述标记信息确定开启或加入的多个全局事务，其中每个所述全局事务包括一个或多个微服务，且每个所述全局事务包括的微服务不相同；

对于任一所述全局事务，当检测到所述全局事务中存在异常微服务调用时，处理所述异常微服务的异常信息，同时将所述异常信息发送给所述异常微服务的上游微服务和下游微服务，使所述上游微服务进行本地事务回滚和异常信息通知，以及使所述下游微服务进行本地事务回滚；

当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；

执行业务调用任务信息，同时利用消息中间件发送所述待发送任务信息；

接收对所述待发送任务信息的确认信息，将所述待发送任务信息的发送状态标记为发送成功；

当所述待发送任务信息发送失败时，在执行下一业务调用任务时重新发送所述待发送任务信息；

根据全局唯一信息标识进行幂等性校验，具体为：当任一微服务接收业务调用任务信息时，将业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识进行比对；

当业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识不重复时，处理业务调用任务信息；

将业务调用任务信息的状态标记为处理成功，以及发送对业务调用任务信息的确认信息。

2.根据权利要求1所述的保障微服务调用数据一致性的处理方法，其特征在于，还包括：

为每个微服务进行AccessKey认证和Secret的认证，使每个微服务与所述消息中间件进行安全连接。

3.根据权利要求1所述的保障微服务调用数据一致性的处理方法，其特征在于，还包括：

为每个微服务配置所述消息中间件的地址。

4.根据权利要求1至3中任一项所述的保障微服务调用数据一致性的处理方法，其特征在于，还包括：

对所述异常微服务、所述异常信息进行显示，以及生成对发送失败信息的重新发送指令；

与云端进行数据同步，向所述云端上报所述异常微服务、所述异常信息，以及获取所述云端的处理指令。

5.一种保障微服务调用数据一致性的处理装置，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序以：

获取标记信息，根据所述标记信息确定开启或加入的多个全局事务，其中每个所述全局事务包括一个或多个微服务，且每个所述全局事务包括的微服务不相同；

对于任一所述全局事务，当检测到所述全局事务中存在异常微服务调用时，处理所述异常微服务的异常信息，同时将所述异常信息发送给所述异常微服务的上游微服务和下游微服务，使所述上游微服务进行本地事务回滚和异常信息通知，以及使所述下游微服务进行本地事务回滚；

所述处理器，还用于执行所述计算机程序以：

当任一微服务接收业务调用任务信息时，记录待发送任务信息至数据库；

执行所述业务调用任务信息，同时利用消息中间件发送所述待发送任务信息；

接收对所述待发送任务信息的确认信息，将所述待发送任务信息的发送状态标记为发送成功；

所述处理器，还用于执行所述计算机程序以：

当所述待发送任务信息发送失败时，在执行下一业务调用任务时重新发送所述待发送任务信息；

根据全局唯一信息标识进行幂等性校验，具体为：当任一微服务接收业务调用任务信息时，将业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识进行比对；

当业务调用任务信息的全局唯一信息标识与预先接收的其它业务调用任务信息的全局唯一信息标识不重复时，处理业务调用任务信息；

将业务调用任务信息的状态标记为处理成功，以及发送对业务调用任务信息的确认信息。

6.根据权利要求5所述的保障微服务调用数据一致性的处理装置，其特征在于，所述处理器，还用于执行所述计算机程序以：

为每个微服务进行AccessKey认证和Secret的认证，使每个微服务与所述消息中间件进行安全连接。

7.根据权利要求5所述的保障微服务调用数据一致性的处理装置，其特征在于，所述处理器，还用于执行所述计算机程序以：

为每个微服务配置所述消息中间件的地址。

8.根据权利要求5至7中任一项所述的保障微服务调用数据一致性的处理装置，其特征在于，所述处理器，还用于执行所述计算机程序以：

对所述异常微服务、所述异常信息进行显示，以及生成对发送失败信息的重新发送指令；与云端进行数据同步，向所述云端上报所述异常微服务、所述异常信息，以及获取所述云端的处理指令。

Images