如何回滚微服务之间发生的事务？

Question

我们有microservice架构，其中大多数情况下每个microservice都是独立的。但由于某些遗留原因，我们不得不从另一个内部调用另一个microservice。

例如：以下方法是Legal Service

的一部分

@Autowired
public ServiceManager UserServiceManager;

public void updateUserLegalData(){

    //do db update of Legal info for the user

   userServiveManager.setAcceptedLegal(true);


}

上面有两个db transactions。一个是更新legalService db，另一个是更新UserService db。请注意userService是在单独的VM上运行的microservice。

我们看到合法服务数据库更新但是对userService的调用失败（Internal server error）的情况。所以这使应用程序处于不一致状态。我们如何以推荐的方式解决这个问题？

由于

Answer 1

只能使用JTA全局/分布式事务处理此情况。 JTA是Java EE标准的一部分，可以有各种实现者。 Atomikos通常是首选工具。

Here is good writeup from Dave Syer (Spring ecosystem contributor).它还包含工作示例。它有点过时，但仍然相关。您可以在他的示例之上应用一些更现代的Spring抽象。

我为我的书创作了一些GitHub examples of JTA transactions。请注意，模拟了错误，事务分布在JMS和JDBC数据源中。

但请记住，由于涉及两阶段提交算法，各种数据源的JTA事务处理速度很慢。因此，人们常常试图避免它们，而是以务实的方式处理不一致问题。 / p>

Answer 2

不要进行分布式交易。

为了与现有遗留系统集成，一种方法可以是单独的（微）服务，它监听来自userService的更新事件，并将相应的更新转发给legalService。 Spring集成可能适合这样的任务。

干杯， 迈克尔

Answer 3

好吧，如果你在互联网上读到一些关于这个主题的内容，那么目前这是一个很大的崩溃点，但有一个答案是每个人都同意它，分布式交易是不可能的。它们太笨拙和错误，我们不能依赖它们来保证数据的一致性。

那么我们的选择是什么呢，人们正试图通过Apache Kafka或事件源（专注于保存更改数据而不是保存数据本身的事件）来协调微服务事务。那么问题是什么？它们与我们习惯的通常编程模型完全不同，在技术和组织的角度来看相当复杂，因此您不必编写业务问题编程，而是开始针对技术挑战进行编程。

那么替代方案是什么，我个人开发了另一个概念并撰写了一篇关于它的博客，它可能对你很有意思。在其基础知识中，它使用完整的微服务设计原则和Spring容器中的Spring Boot + Netflix并完全使用事务，这里写下所有细节的时间太长，如果您有兴趣可以阅读下面的链接。< / p>

Micro Services and Transactions with Spring Boot + Netflix

Answer 4

跨微服务的事务可能变得复杂并且可能使系统变慢，解决分布式事务问题的最佳方法之一就是完全避免它们。 如果您避免跨微服务的分布式事务，那么您将不会遇到这种情况。

如果你必须在微服务中实现分布式事务，那么我认为有两种方法：

两阶段提交协议 **最终一致性

在您的情况下，我建议使用消息总线和标志在服务之间进行通信，因此，如果合法服务将数据添加到合法数据库中，则锁定该记录并在消息总线上发送消息，用户服务在其启动时将选择消息并在其末尾更新数据库并将ack消息发送到消息总线上，一旦收到确认消息，则删除锁定，否则在一定时间后删除/回滚记录。在您的情况下，这看起来很复杂但可靠且防故障。