[发明专利]支持微服务架构事务最终一致性的方法、装置及系统

说明书

本发明提供了一种支持微服务架构事务最终一致性的方法、装置及系统。其中，用于发送端的支持微服务架构事务最终一致性的方法，包括：发起服务调用，记录日志，当日志写入动作时，定时检查未发起服务调用或者超过指定时间未收到返回结果日志，发送调用请求；接收回执消息，查询日志记录，根据日志状态判断调用处理是否完成，若调用处理中，调用返回结果，根据返回结果调用相应业务接口，继续发起服务调用，再通过用于消息队列服务以及用于接收端的支持微服务架构事务最终一致性的方法，实现通过日志以及消息队列对服务进行异步数据调用，最终实现服务间数据的最终一致性。

技术领域

本发明涉及微服务领域，具体而言，涉及一种支持微服务架构事务最终一致性的方法、装置及系统。

背景技术

目前，在互联网开发的环境下，统一的大应用系统已经不能满足日益增长的扩展性需求。为了提高系统的运行速度，以及支持灵活的动态扩展，业务系统一般会被拆分为多个微服务，即每个服务仅提供相对独立的部分功能，实现通过部署新的服务方式进行系统的功能扩展，同时在系统的压力过大时，可以更精确地扩展需要增加的服务，避免其它服务占用不必要的系统资源。

一次业务服务的调用过程，可能会经过多个应用系统，而原有单个应用系统在运行时，不同应用模块间是通过数据库保证事务的一致性，即同时修改成功，一旦失败后会回滚全部应用操作的数据。然而，采用微服务的架构方式，无法再依赖数据库实现事务的一致性，存在各个应用系统间的调用问题。

在微服务架构下，应用系统通过服务接口调用的方式访问其他应用。具体地说，在服务调用的方式下，从A应用发起一次业务请求，可能需要调用B应用、C应用等多个应用的服务，为了保证事务的一致性，如果调用C应用失败，B应用系统的数据无法回滚而产生错误，这时可以通过A应用的业务逻辑在此调用B应用的方向服务，但是，会带来两个问题：一方面，导致业务逻辑的复杂度高，容易出现错误；另一方面，如果A应用、B应用或者C应用出现宕机时，可能导致数据无法回滚，最终无法保证数据的一致性。

在微服务架构下，各应用系统间的业务相对独立，即业务的数据也相 对独立，因此，不需要保证数据的实时一致性，只要保证数据的最终一致性即可，具体地说，当A系统调用B系统服务时，可以先完成A系统的数据持久化，B系统可以异步修改自己的数据，如果出现错误时，根据错误产生的原因重新执行B系统业务动作，或者调用A系统的反向操作，回退A系统的数据，实现A系统、B系统间的数据的最终一致性，同时不会影响A系统的执行速度。

发明内容

本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。

为此，本发明的一个目的在于提出了一种用于发送端的支持微服务架构事务最终一致性的方法。

本发明的另一个目的在于提出了一种用于消息队列服务的支持微服务架构事务最终一致性的方法。

本发明的又一个目的在于提出了一种用于接收端的支持微服务架构事务最终一致性的方法。

本发明的又一个目的在于提出了一种用于发送端的支持微服务架构事务最终一致性的装置。

本发明的又一个目的在于提出了一种用于消息队列服务的支持微服务架构事务最终一致性的装置。

本发明的又一个目的在于提出了一种用于接收端的支持微服务架构事务最终一致性的装置。

本发明的再一个目的在于提出了一种支持微服务架构事务最终一致性的系统。