在事件驱动的世界中处理异常

Question

null

在此场景中的任何阶段，都可能出现失败，例如：

• 该商品已无存货
• 付款信息不正确
• 受款人使用的帐户没有可用资金
• 向支付服务提供商等外部调用失败，如停机时间

您如何跟踪每个阶段已被调用和/或完成？

你如何处理出现的问题？你如何通知前台故障？

Answer 1

您描述的一些东西不是错误或异常，而是您应该在分布式体系结构中考虑的替代流。

例如，商品缺货是业务流程中一个完全有效的替代流程。一个可能需要人为干预的。您可以将消息移动到一个单独的队列中，并提供一些UI，在那里人工操作员可以处理问题、解决问题并使事件流继续进行。

你描述的付款问题也可以说是类似的事情。如果一个订单不能成功解决，人工操作员将需要调查并解决这个问题。因此，您的设计必须考虑到替代流作为它的一部分，并使它能够在消息最终进入队列时以某种方式进行干预，需要人来检查它们。

• 补偿事务模式
• 尝试/取消/确认模式
• 长时间运行的事务
• 传奇

补偿交易背后的思想是，每一个盈都有它的阳：如果你有一个交易可以下订单，那么你可以用一个取消该订单的交易来撤销该交易。后一个事务是补偿性事务。因此，如果您执行了许多成功的事务，但其中一个失败了，您可以追溯您的步骤，并补偿您所做的每一个成功的事务，因此，恢复它们的副作用。

我特别喜欢《从研究到实践的Rest》一书中的一章。它的第23章（在RESTful服务上实现分布式原子事务）深入解释了try/cancel/confirm模式。

Microservices Patterns一书有一整章叫做Management Transactions with Sagas，它详细探讨了如何实现这种类型的解决方案。

我还通常考虑以下几个方面：

幂等性

当涉及到重试服务事务时，您不应该仅仅因为它失败而重试。您必须首先知道它失败的原因，根据错误，重试或不重试可能是有意义的。某些类型的错误是暂时的，例如，如果一个事务由于查询超时而失败，重试可能没问题，而且很可能第二次就会成功；但是，如果您得到了数据库约束违反错误（例如，因为DBA向字段添加了check约束），那么重试该事务就没有意义了：无论您尝试多少次，它都将失败。

将错误作为一种可供选择的流

正如我在回答的开头所提到的，并不是每件事都是错误。有些东西只是替代流。

我发现这种类型的事务性工作流需要对模型必须经历的不同状态进行良好的设计。与try/cancel/confirm模式一样，这意味着最初应用副作用，而不必使数据模型对用户可用。

例如，当您下订单时，您可能会将其添加到数据库中，处于“挂起”状态，而该状态不会出现在仓库系统的UI中。一旦付款被确认，订单就会出现在用户界面中，这样用户就可以最终处理其发货。

这里的困难在于发现如何设计事务粒度，以使即使事务工作流的一个步骤失败，系统仍然处于有效状态，一旦故障原因得到纠正，您可以从该状态恢复。

因此，正如您所看到的，设计以这种方式工作的分布式系统比单独调用分布式事务服务要复杂一些。现在，每个服务调用都可能由于多种原因而失败，并使分布式工作流处于不一致的状态。并且重试事务可能并不总是解决问题。您的数据需要像状态机一样建模，以便在整个编排成功之前应用但不确认副作用。

这就是为什么整个事情可能需要以不同于在单片客户机-服务器应用程序中通常所做的方式进行设计。当涉及到解决冲突时，您的用户现在可能是设计的解决方案的一部分，并且考虑到事务性编排可能需要几个小时甚至几天才能完成，这取决于他们的冲突是如何解决的。

正如我最初所说的，这个主题太广泛了，它需要一个更具体的问题来讨论，也许只是详细地讨论其中的一两个方面。