我想这个问题需要根据自己的系统具体架构来分别讨论，这边拿一个车联网的系统举例。
拆除GPS这个功能接口需要分几个步骤实现（不涉及数据更新的步骤略去了）：
①更改GPS设备状态(设备管理服务)
②更改工单状态（工单管理服务）
假设调用拆除GPS这个接口的时候，由于各种原因②不能工作了。
架构1：普通的微服务架构
工单管理服务要调用设备管理服务的功能，用的是spring cloud的自己的restTemplate，这个很简单，加上普通的事务就可以了。
架构2：引入了消息中间件
这个时候，服务之间调用加了一层消息中间件(以activemq为例)，这也没关系，activemq有消息确认机制ACK，可以指定ACK_MODE为SESSION_TRANSACTED=0进行事务提交
，然后再配合原来的数据库事务，也可以实现。并且activemq还有失败重发机制，可以尝试N次重发失败之后再回滚。
架构3：用到了分库
那就涉及到多数据源了，这方面spring也可以集成atomiko实现分布式事务。
