场景：我有多个符合 XA 的数据库，这些数据库前面有不同的微服务，它们对它们执行 CRUD 操作。我需要在这些微服务中执行 2 阶段提交。这意味着我有一个正在运行的服务器，它对这些微服务进行 API 调用以进行一些更新，这些更新应该是事务性的。我们计划创建一个事务管理器来管理它。
问题：所有可用的解决方案（如 Atomikos 等）都要求不同的事务发生在同一台服务器上，但在我的情况下，这些事务发生在不同的微服务中。在这种情况下，我们如何提供事务管理？最终，我们想要准备事务，然后在由我们自己的事务管理器管理的不同会话中提交它们。那可能吗？
我认为您的意思并不是完全不同的会话，而是一个应用程序层级事务，其中应用程序组件一个不同的服务器位于事务边界内。
您面临的问题是，创建微服务的人对信息系统的了解或经验不足，无法理解这些场景。
微服务本质上是刻板印象的错误概括和衍生
历史上允许企业信息系统在没有专有供应商锁定的情况下在全球范围内交换信息的事务和许多其他基本概念根本不属于微服务理解的一部分。
所以你的问题实际上是你如何改造架构概念来做正常的日常计算机工作。
最后，如果您继续解决这些问题，您将回到 Java EE 应用程序服务器。（Spring 也经历了同样的失败，最终包装和重新命名了 Java EE 标准功能，但措辞更令人讨厌）
我在 Glassfish 上的业务逻辑可以在一个事务中与 WebLogic 上的业务登录和大型机上的 CICS tx 以及每个人的数据库和消息队列都在不同的服务器上进行通信。XA 规范列出了如何做到这一点。
这绝对是可能的（您可以在大多数资源管理器的单独会话上执行 xa_prepare 和 xa_commit，如果不是全部的话），但实际上最终您最终将基本上编写一个带有事务上下文传播的 Java EE (JTA) 样式事务管理器通过 REST 或消息传递或您正在使用的任何通信机制。这已经在例如 Narayana/JBoss 实现的 Rest-AT 规范和其他一些规范中完成。
Weblogic 现在有一个运营多年的运营商将其带入 Kubernetes 领域，因此 XA/2PC 可以简单地继续在那里使用，Tuxedo 将推出一个产品来实现相同的目的（超过 Rest）。
saga 模式也一定要考虑。不能盲目地接受它，也不能将其视为微服务领域的一种很好的模式/契合点。事务管理中的用例，像任何其他领域一样，继续变得越来越优化和专业化，因此它涉及最终一致性、补偿等的事实本身不应该是非首发，因为它有许多就部署模型、可扩展性以及 XA 分布式锁的移除等而言，具有显着优势。最佳解决方案取决于特定的用例及其要求。
许多微服务框架，例如 Narayana (WildFly/Quarkus/SpringBoot)、Helidon，甚至在 Oracle DB 本身内部，现在都有 Saga 引擎。全面披露，我在 Oracle 工作，并在接下来的几周内举办一个关于这个产品的研讨会，它将建立在现有的“使用聚合 Oracle 数据库研讨会简化微服务”的基础上，该研讨会有一个非常基本的基于编排的传奇（而不是我提到的基于编排的产品/引擎）。
由于我在过去 25 年中一直在编写事务管理器，因此很高兴能就这个话题进行更多讨论。:)