跨微服务，事务需要通过公开prepare&commit API来完成。还需要一个事务管理器来协调事务。
例如，假设有两个不同的银行，银行1的账户a的100美元必须转到银行2的账户b。此外，假设中央银行管理局负责交易，以完成2pc的工作方式如下：
中央银行管理局（交易经理）将收到从银行1的账户a向银行2的账户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

一旦在提交阶段成功响应两个调用，中央银行就可以将事务移到完成状态（可选）
如果准备或提交阶段的任何步骤失败，则事务协调器通过发出以下命令中止事务：

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服务作为一个单独的微服务来提供多个微服务之间的2pc？
理论上不会。如果你仔细观察任何一家银行（bank1或bank2），它也可以充当事务管理器（它只需要一个单独的数据库表事务），但实际上很多时候它是作为单独的微服务保存的。