I read some information about 2 Phase Commit/ XA distributed transactions and how JTA does support it. Seems to be that there is many resource managers - RM (eg. RDBMS or JMS), and one TransactionManager (TM) instance that manages global transactions across many RM's.
我知道最好使用佐贺图案，但想想还是很有趣的：
UPD: 在JTA的世界里 TransactionManager 不提供REST API用于管理跨微服务的事务。 LIXA 提供了这种能力。带有示例的文章 https://dzone.com/articles/microservices-and-distributed-transactions除了答案:)
在微服务中，事务需要通过公开准备和提交 API 来完成。还需要有一个事务管理器来协调事务。
例如，假设有 2 个不同的银行，并且必须将 Bank1 的 Account_A 中的 100 美元转入 Bank2 的 Account_B。此外，假设中央银行当局负责交易完成 2PC 的工作方式如下：
中央银行机构（交易经理）将收到从 Bank1 的 Account_A 向 Bank2 的 Account_B 转账 100 美元的请求。
a. https://CentralBank/Transaction?from=Bank1-Account_A&to=Bank2-Account_B&amount=100
中央银行会将其保存到其交易数据库中，其中交易 ID = 123。此外，它还会返回交易 ID 进行调用，以便稍后可以调用以获取交易状态。
a. add transaction 123 in database with status open
准备阶段事务管理器将发出以下 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
提交阶段一旦它在准备阶段获得两个调用的成功响应，就会进入提交阶段，在此阶段发出以下命令：
a. move transaction 123 to committed state
b. https://Bank1/Commit?transactionid=123
c. https://Bank2/Commit?transactionid=123
一旦在提交阶段的两个调用都获得成功响应，中央银行就可以将交易转移到“已完成”状态（可选）
如果 PREPARE 或 COMMIT 阶段的任何步骤失败，则事务协调器将通过发出以下命令来中止事务：
a. move transaction 123 to Failed state
b. https://Bank1/Rollback?transactionid=123
c. https://Bank2/Rollback?transactionid=123
上述问题的形式为分布式原子提交，2PC 是一种实现方式。另请注意，2PC 有很多缺点，例如在 PREPARE 阶段央行崩溃后会发生什么。另外，如果 4.c 步骤失败但 4.b 成功，等等该怎么办。讨论这些本身就是非常广泛的研究，但仍然是需要注意的事情。尽管有很多缺点，2PC 因其简单性而被广泛使用。
我们是否需要使用 TransactionManager 服务作为单独的微服务来在许多微服务之间提供 2PC？
理论上不会。如果您仔细观察任何银行（Bank1 或 Bank2）也可以充当事务管理器（它只需要一个单独的数据库表事务），但实际上很多时候它被保留为单独的微服务。