从订单支付看分布式事物

问题：公司做的项目转成微服务架构很久了，但是一直没有实现分布式事物控制。
在出解决方案的时候想到业界成熟的使用消息队列实现数据的最终一致性。
但是仔细想想，分布式事物的介绍

在分布式系统中一次操作由多个系统协同完成，这种一次事务操作涉及多个系统通过网络协同完成的过程称为分布式事务。这里强调的是多个系统通过网络协同完成一个事务的过程，并不强调多个系统访问了不同的数据库，即使 多个系统访问的是同一个数据库也是分布式事务。

这样想想，以前做的订单支付算是这种定义下的分布式事物么？

之前做的订单支付功能，调用第三方支付接口。需要做到调用支付成功，我们系统支付成功；调用第三方支付系统失败，我们系统支付失败。似乎也可以算作广义上的分布式事物。
看看流程图

1.发起请求同步回调

首先第一步，本地服务访问第三发接口，并且接收，返回值。
这里可能出错情况：
1.发送请求出错。
2.请求发送后，第三方服务器挂掉没有返回。
3.接受返回值之后，执行业务流程报错。
这里1、3报错都在一个事物内，可以进行回滚操作。2异常可以将订单状态设置成异常状态、或者超时状态。

2.超时状态处理

定时将超时状态订单重新调用第三方支付接口，查询付款状态，完成订单状态更新。

3.异步回调完成订单付款

这里可能出先的问题：
1.接受到异步回调之后，服务器出现异常。在事物范围内可以回滚。并且无法发送返回报文。
2.发送返回报文时提交时异常。
这里1情况方法出现异常事物回滚之后，订单还是处于未支付状态。但是第三方系统因为未收到完成回调，则会在一段时间后重新回调，完成订单支付。2情况会导致订单未支付，并且第三方支付服务器不会再有回调，这时需要定时任务去将长时间未付款订单查询付款状态，或者关闭。
以上便是系统中一个比较完善的付款流程。

那么在多服务中可以使用简化操作

思考：
在自己需要两个服务协同工作时，我们可以新建一个协同任务表。
定时将协同任务像需要调用服务发送请求，以达到数据最终一致。

文中不足还请多多指教。