我正面临一些问题w.r.t.我的生态系统中的服务之间的原子性和持久性。
假设我有服务A，B和C.现在客户端与服务A谈话以做某事。但是服务A反过来与B和c交谈，然后将结果转发给客户。假设我能够将某些资源更新为服务B的一部分，但无法将某些资源更新为C服务的一部分。比如何实现服务之间的一致性，即如果C失败，那么作为服务B的一部分的所有更新也应该回滚。
XA是要走的路还是其他更优雅的东西。
答案 0 :(得分：1)
XA是要走的路还是其他更优雅的东西。
SOA的目标之一是实现松散耦合。 存在几种形式的松耦合（或者可以应用松耦合的不同系统的方面）。 其中一种松耦合形式与交易有关。
使用XA事务，您的优势在于您的代码不需要处理替代流程，因此代码更清晰，更易于维护。
此时，您的问题有elegant解决方案。
然而，这＆＃34;简单＆＃34;有一个成本：您的服务以交易形式耦合。 特别是，如果参与您的交易的某些服务属于第三方系统（它不在您的控制之下），则外部系统可能会锁定您的服务。
如果这种耦合成为问题，解决方案可能是消除XA事务并编写处理备用流的代码。这是Saga图案出现的地方。我们的想法是，如果业务流程的一个步骤失败，那么通过编程方式，您将必须保持一致性，实现所谓的补偿代码。
此时，您的问题也有elegant解决方案，尽管您的代码变得更加复杂。
我看过你所描述的场景，由于缺少XA事务，服务代码不必要地过于复杂。 我不必要地说，因为交易耦合并不是一个问题。 我认为很难看到事务耦合足够大以便用补偿代码替换XA事务的情况。