微服务中的交易

Question

我已经阅读了一些关于微服务架构的文章，但没有人会谈论交易的话题。他们都说这很难做到。也许有人可以描述如何处理这个？

但不是来自域端，而是来自技术端。假设我们有业务案例，我们需要调用两个不同的服务，并且他们都对数据库进行了一些更改。但是如果在第二个错误发生时如何回滚？

谁知道这个问题的一些图书馆或设计模式？

Answer 1

最好的设计是有独立的服务：每个服务只是在自己的事务中完成它的工作，而你的工作流程预计单一服务会出现故障。

如果只有在所有服务都被错误地调用的情况下才需要提交，那么应该创建一个更高级别的服务来在外部事务中执行这些调用。

Answer 2

我可能不是这方面的最终专家，但我相信你正在走向分布式交易。为了让它们运行，所有的应用程序服务组件都需要一个公共的共享事务ID，并且必须确保每个组件都被告知有关事务的状态。它是异步的，所以你需要大量的编程技巧。提到或讨论

下面是分布式事务：

https://en.wikipedia.org/wiki/Distributed_transaction

http://contino.co.uk/microservices-not-a-free-lunch/

http://martinfowler.com/articles/microservices.html

这似乎人们尽量避免它，因为它是困难的。也许这就是为什么你没有发现很多。

希望这有助于向前迈进了一步:-)以前的答案顶部

Answer 3

大厦，分布式事务的解决方案。在我看来，你不想建立自己的跟踪全局事务状态的机制，而是想使用某种产品 - 有几种产品。我已经写了关于解决这一问题的Java应用服务器冗长的博客文章：

http://blog.maxant.co.uk/pebble/2015/08/04/1438716480000.html

Answer 4

两阶段提交可以option.Coordinator发送提交请求消息cohorts.Cohorts发回ok.After然后协调员发送提交消息给队列。如果任何失败使协调器向队列发送回退消息。

Answer 5

它来到我的脑海里读取这个问题后的第一胎就是要创建的每个添加 API与删除 API和，可以说，一个额外的布尔标志delFlag。

布尔标志delFlag;

对于POST，它将为0.对于DELETE，它将为1。

现在您维护一个交易管理器，它是所有微服务的超级服务。 在此服务中维护所有服务和API的调用队列。当服务失败时，获取调用api并调用该服务的删除方法，并撤消您所做的任何操作。

PS-只是一个原始的想法。纠正我，如果你认为它是错误的。

Answer 6

您可以使用工作流引擎（如JBPM，Activiti）编排逻辑并处理事务故障或其中的补偿事务，以实现数据完整性。这是你在SOA架构中使用ESB，BPMN和Web服务的类似案例