假设我们有一个用户、钱包REST微服务和一个API网关将它们粘合在一起。当Bob在我们的网站上注册时，我们的API网关需要通过用户微服务创建用户和通过钱包微服务创建钱包。
现在这里有几种情况可能会出错：
创建用户Bob失败：没关系，我们只需向Bob返回错误信息。我们正在使用SQL事务，所以没有人曾经在系统中看到过Bob。一切都很好 :)
在我们的钱包创建之前，用户Bob被创建了，但是API网关突然崩溃了。现在我们有一个没有钱包的用户（不一致的数据）。
创建用户Bob并且在我们创建钱包时，HTTP连接断开了。钱包创建可能已成功，也可能未成功。
不合理的事情：
会让你头疼的事情：
可能最好的替代方案是什么：
但如果您需要同步响应呢？
最近我在一次面试中被问到了一个经典问题：如何调用多个 Web 服务并仍然保留某种错误处理。现今，我们在高性能计算中避免使用两阶段提交。很多年前我读过一篇关于事务的“星巴克模型”的论文：想象一下在星巴克点咖啡的整个过程，包括下单、支付、制作和领取你所点的咖啡……虽然这里对问题进行了简化，但是采用两阶段提交模型会导致所有员工都需要等待并停止工作，直到你拿到咖啡。你明白这个情景吗？
相反，“星巴克模型”更加高效，采用了“尽力而为”模式并在过程中对错误进行补偿。首先，他们确保你已经付款！然后，有一个带有你订单信息的消息队列附着在杯子上。如果在过程中出现任何问题，比如你没有拿到咖啡，或者咖啡不是你点的等等，我们就进入补偿流程并确保你得到你想要的东西或者退款。这是提高生产率最有效的模型。
有时候星巴克浪费一杯咖啡，但整个过程是高效的。在构建 Web 服务时，还有其他技巧需要考虑，比如设计它们的方式让其可以被调用任意次数并仍然提供相同的最终结果。因此，我的建议是：
不要对定义 Web 服务过于苛刻（我对当今流行的微服务兴起并不完全信服：存在太多扩展风险）；
异步操作可以提高性能，所以尽可能采用异步方式，并通过电子邮件发送通知；
构建更智能的服务，使其可“可召回”地处理任意次数，使用 uid 或 taskid 处理订单底层至顶部，每一步都验证业务规则；
使用消息队列（JMS 或其他）并转向错误处理器，通过执行相反操作来实现“回滚”操作。与此同时，处理具有异步订单将需要某种队列来验证进程的当前状态，因此需要考虑这一点；
如果一切都失败了（因为这种情况可能不经常发生），将其放入手动处理错误的队列中。
让我们回到最初发布的问题。创建账户和钱包，确保一切都完成。
假设调用一个 Web 服务来编排整个操作。
Web 服务的伪代码如下：
调用账户创建微服务，传递一些信息和一个独特的任务 ID 1.1。账户创建微服务首先检查是否已经创建了该账户。任务 ID 关联着账户记录。微服务检测到该账户不存在，因此创建它并存储任务 ID。注意：可以调用此服务 2000 次，它总是执行相同的结果。该服务用“收据”回答，其中包含执行撤消操作所需的最少信息。
调用钱包创建，给出账户 ID 和任务 ID。假设某个条件无效，无法执行钱包创建。调用返回一个错误，但未创建任何内容。
编排程序被通知有错误发生。它知道需要终止账户创建，但不会自己执行。它将通过传递在步骤 1 结束时收到的“最小撤消收据”来请求钱包服务执行此操作。
账户服务读取撤消收据并知道如何撤消操作。撤消收据甚至可以包含有关它自己调用的另一个微服务执行工作的信息。在这种情况下，撤消收据可能包含账户 ID 和执行相反操作所需的其他一些额外信息。在我们的情况下，为简化事情，让我们仅仅是使用账户 ID 删除账户。
所有分布式系统都会面临事务一致性的问题。最好的方法就像你说的那样，使用两阶段提交。将钱包和用户创建为待定状态。在创建后，再单独调用激活用户的功能。
这个最后的调用应该是可以安全重复的（以防连接中断）。
这将需要最后一个调用同时了解到两个数据表（以便可以在单个JDBC事务中完成）。
或者，您可能想考虑为什么如此担心没有钱包的用户。您认为这会导致问题吗？如果是这样，也许将它们作为单独的REST调用是一个不好的想法。如果用户没有钱包就不能存在，那么您应该在创建用户的原始POST调用中添加钱包。
我的看法是，微服务架构的一个关键方面是事务仅限于单个微服务（单一职责原则）。
在当前示例中，用户创建将成为自己的事务。用户创建将向事件队列推送一个USER_CREATED事件。钱包服务将订阅USER_CREATED事件并进行钱包创建。
一个简单的解决方案是使用用户服务创建用户，并使用消息总线，其中用户服务会发出其事件，钱包服务在消息总线上注册，监听用户创建事件并为用户创建钱包。同时，如果用户进入钱包界面查看他的钱包，则检查用户是否刚刚创建，并显示您的钱包创建正在进行中，请稍后再查看。
有许多将非事务资源“绑定”到事务中的方法：另外，我知道REST可能并不适用于此用例。也许处理这种情况的正确方法是完全放弃REST，并使用像消息队列系统这样的不同通信协议？
或者我应该在我的应用程序代码中强制执行一致性（例如，通过具有检测不一致性并修复它们的后台作业或通过在我的User模型上具有“creating”，“created”值等的“state”属性）？
反对者说：为什么要构建这样的东西，当有产品可以为您完成这项工作（请参见上文），而且很可能做得比您好，因为它们经过了尝试和测试？
分布式事务不是一个好选择，许多人现在更倾向于最终一致性系统，但我不确定这对银行、保险等行业是否可行。
我写了一篇关于我的解决方案的博客，也许这可以帮助你……
最终一致性是关键。
指挥官负责分布式事务并掌控全局。它知道要执行的指令并协调执行它们。在大多数情况下，只有两个指令，但它可以处理多个指令。
指挥官负责保证执行所有指令，这意味着重试。当指挥官尝试影响远程更新并且没有得到响应时，它没有重试。这样，系统可以配置为不太容易出现故障并自我修复。
由于我们有重试，因此我们具有幂等性。幂等性是能够以某种方式执行两次操作，使得最终结果与仅执行一次相同的属性。我们需要在远程服务或数据源处具有幂等性，以便在接收到指令超过一次的情况下，它仅处理一次。
最终一致性 这解决了大多数分布式事务的挑战，但我们需要考虑几个要点。 每次失败的事务都将跟随一个重试，尝试重试的次数取决于上下文。
一致性是最终的，即在重试期间系统处于不一致状态，例如如果客户订购了一本书并进行了付款，然后更新库存数量。如果库存更新操作失败，并且假设这是最后一本库存，则该书仍将可用，直到库存更新操作成功为止。重试成功后，您的系统将保持一致。
