我面临一些问题。我的生态系统中各个服务的原子性和持久性。
假设我有服务 A、B 和 C。现在客户端与服务 A 对话以执行某些操作。但服务 A 反过来与 B 对话，然后 c 将结果转发给客户端。假设我能够更新某些资源作为服务 B 的一部分，但无法更新某些资源作为服务 C 的一部分。那么我将如何实现跨服务的一致性，即如果 C 失败，那么作为服务 B 一部分的所有更新也应该回滚。
XA 是正确的选择还是存在其他更优雅的东西。
最佳答案
Is XA is the way to go or something else more elegant is present.
SOA 的目标之一是实现松耦合。 松耦合有多种形式(或者可以应用松耦合的系统的不同方面)。 这些松散耦合形式之一与事务相关。
使用XA事务，您的优势在于您的代码不需要处理替代流程，因此，代码更清晰且更易于维护。
此时，您的问题已经有了一个优雅的解决方案。
但是，这种“简单性”是有代价的:您的服务以事务形式耦合。 特别是，如果参与您交易的某些服务属于第三方系统(不受您控制)，则存在外部系统锁定您的服务的风险。
如果这种耦合成为问题，解决方案可能是消除 XA 事务并编写处理替代流的代码。这就是 Saga 模式出现的地方。这个想法是，如果业务流程的一个步骤失败，您将必须以编程方式保持一致性，实现所谓的补偿代码。
此时，您的问题也有了一个优雅的解决方案，尽管您的代码变得更加复杂。
我见过像您所描述的那样的场景，其中由于缺乏 XA 事务，服务代码不必要地过于复杂。 我说不必要是因为事务耦合不存在问题。 我认为很难看到事务耦合足够大以至于值得付出努力来用补偿代码替换 XA 事务。
关于java - SOA 中服务间的原子性和一致性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23663851/