场景:我有多个符合 XA 的数据库，由不同的微服务负责，这些微服务对这些数据库执行 CRUD 操作。我需要在这些微服务之间执行两阶段提交。这意味着我有一个正在运行的服务器，它对这些微服务进行 API 调用以进行一些更新，并且这些更新应该是事务性的。 我们计划创建一个事务管理器来管理它。
问题:所有可用的解决方案(例如 Atomikos 等)都要求不同的事务发生在同一台服务器上，但就我而言，这些事务发生在不同的微服务中。 在这种情况下我们如何提供事务管理？ 最终，我们希望准备事务，然后在由我们自己的事务管理器管理的不同 session 中提交它们。 这可能吗？
最佳答案
这绝对是可能的(您可以在大多数(如果不是全部)资源管理器上的单独 session 上执行 xa_prepare 和 xa_commit)，但实际上最终您将基本上编写一个 Java EE (JTA) 风格的事务管理器通过 REST 或消息传递或您正在使用的任何通信机制进行事务上下文传播。这已经在 Narayana/JBoss 实现的 Rest-AT 规范和其他一些规范中完成。
Weblogic 拥有一个拥有多年经验的运营商，可以将其带入 Kubernetes 领域，因此 XA/2PC 可以继续在那里使用，Tuxedo 将推出一款产品来实现相同的目标(而不是 Rest) )。
传奇模式也绝对应该被考虑。不能盲目地接受它，也不能立即将其视为微服务领域的一个很好的模式/契合点。与任何其他领域一样，事务管理中的用例继续变得越来越优化和特化，因此它涉及最终一致性、补偿等的事实本身不应是不可能的，因为它有许多在部署模型、扩展以及消除 XA 分布式锁等方面具有显着优势。最佳解决方案取决于具体用例及其要求。
许多微服务框架，例如 Narayana (WildFly/Quarkus/SpringBoot)、Helidon，甚至 Oracle DB 本身，现在都拥有 Saga 引擎。全面披露，我在 Oracle 工作，并将在接下来的几周内举办一个关于这个产品的研讨会，该研讨会将建立在现有的“通过融合 Oracle 数据库研讨会简化微服务”的基础上，该研讨会有一个非常基本的基于编排的传奇(而不是我提到的基于编排的产品/引擎)。
很高兴能更多地讨论这个主题，因为我在过去 25 年里一直在编写事务管理器。 :)
关于microservices - 对微服务的 XA 支持，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/68826779/