跨多个微服务的2PC分布式事务？

我阅读了一些关于2阶段提交/XA分布式事务以及JTA如何支持它的信息。似乎有很多资源管理器-RM(例如，RDBMS或JMS)，以及一个管理跨多个RM的全局事务的TransactionManager(TM)实例。

我知道使用Saga模式更好，但是想想还是很有趣的：

1. Do 2PC/XA分布式事务提供了仅从一个应用程序和一个TM使用多个RM进行事务的可能性？
2. 如果没有-如何在多个微服务之间使用2PC/XA分布式事务来提供使用2PC的能力，如果每个微服务只能访问自己的数据库？我很乐意看到一个例子
3. 是否需要将TransactionManager服务作为单独的微服务使用，以便在多个微服务之间提供2%？

更新：JTA世界TransactionManager不提供睡觉跨微服务交易管理接口。Lixa提供了这种能力。Article with examples除答案外：)

---

解决方案

跨微服务，事务需要通过公开准备和提交API来完成。此外，还需要有事务管理器来协调事务。

例如，假设有两个不同的银行，Bank1的Account_A中的100美元必须转移到Bank2的Account_B。此外，假设中央银行当局负责完成交易。 2PC的工作方式如下：

1. 中央银行机构(交易管理器)将收到将$100从Account_A从Bank1转账到Account_B从Bank2转账的请求。

   a. https://CentralBank/Transaction?from=Bank1-Account_A&to=Bank2-Account_B&amount=100
   

2. 中央银行将使用某个交易ID=123将其保存到其交易数据库中。它还将返回事务ID以供调用，以便稍后可以调用以获取事务的状态。

   a. add transaction 123 in database with status open
   

3. 准备阶段Transaction Manager将发出以下RPC命令：

   a. https://Bank1/Prepare?Account=Account_A&money=100&action=subtract&transactionid=123
   b. https://Bank2/Prepare?Account=Account_B&money=100&action=add&transactionid=123
   

4. 提交阶段在准备阶段获得两个调用的成功响应后，它将进入提交阶段，在此阶段它会发出以下命令：

   a. move transaction 123 to committed state
   b. https://Bank1/Commit?transactionid=123
   c. https://Bank2/Commit?transactionid=123
   

5. 在提交阶段获得两个调用的成功响应后，央行可以将交易移至已完成状态(可选)

6. 如果准备或提交阶段的任何步骤失败，则事务协调器通过发出以下命令中止事务：

   a. move transaction 123 to Failed state
   b. https://Bank1/Rollback?transactionid=123
   c. https://Bank2/Rollback?transactionid=123
   

---

上述问题是分布式原子提交的形式，2PC是解决该问题的一种方法。还请注意，2PC有很多缺点，比如如果在准备阶段央行崩溃后会发生什么。如果4.c步失败了，4.b步成功了怎么办，等等。讨论这些本身就是一个非常广泛的研究，但仍然是值得注意的事情。尽管2PC有很多缺点，但由于其简单性而被广泛使用。

---

我们是否需要将TransactionManager服务作为单独的微服务来在多个微服务之间提供2%？

理论上没有。如果您仔细观察任何一家银行(Bank1或Bank2)也可以充当事务管理器(它只需要一个单独的数据库表事务)，但实际上很多时候它是作为单独的微服务保存的。