[发明专利]一种保障微服务调用数据一致性的处理方法、处理装置

说明书

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

技术领域

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

背景技术

微服务架构下多个服务之间通过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阶段进行完善的设计和代码编写，业务侵入性较大，不太容易实施和落地。

发明内容