c# - 将 NServiceBus Saga 作为单个可等待的请求-响应调用

Question

考虑一个 Web 应用程序，它实现了除查询(即添加、更新、删除)之外的每个数据库操作作为 NServiceBus 消息，这样每当用户调用 Web API 时，在后端它都会被映射到 await endpointInstance.Request方法在同一 HTTP 请求连接中返回响应。

挑战在于当消息处理程序需要发送一些其他消息并等待它们的响应以完成其工作时。 NServiceBus 不允许调用 Request在消息处理程序中。

我最终使用 Saga 来实现依赖于其他消息处理程序响应的消息处理程序。但是 Saga 的问题是我无法在同一个 HTTP 请求中发回结果，因为 Saga 使用发布/订阅模式。

我们所有的 web API 都需要在同一个 HTTP 请求中响应(连接应保持打开状态，直到收到结果或发生超时异常)。是否有任何干净的解决方案(最好不使用 Saga)？

示例场景:

1. 用户调用http://test.com/purchase?itemId=5&paymentId=133
2. 网络服务器调用 await endpointInstance.Request<PurchaseResult>(new PurchaseMessage(itemId, paymentId));
3. PurchaseMessage处理程序应调用 await endpointInstance.Request<AddPaymentResult>(new AddPaymentMessage(paymentId));
4. 如果AddPaymentResult成功，将购买详情存入数据库并返回true作为PurchaseResult , 否则返回 false

Answer 1

您正试图实现我们(在 Particular Software)正试图积极阻止的事情。让我解释一下。

通过远程过程调用 (RPC)，您可以在进程外调用另一个组件。那是什么使过程调用“远程”。在使用常规编程的情况下，您可以在进程中完成所有操作，而且速度非常快，而使用 RPC，您需要承担序列化、延迟等方面的开销。基本上，你必须处理 the fallacies of distributed computing .

尽管如此，人们还是出于各种原因这样做。有时是因为您想使用 WebAPI(或“老式”Web 服务)，因为它提供了您不想开发的功能。书中最古老的例子是通过邮政编码搜索地址。或者从某人的银行账户中扣款。如果您正在构建 CRM，则可以使用这些远程组件。现在很多人构建分布式单体，因为他们在 session 上被告知这是一件好事。在架构图中，它看起来非常好，但仍然存在时间耦合，这会带来很多麻烦。

其中一些令人头疼的问题是您试图以原子操作执行某些操作。过去，通过进程内调用代码/类/等，这既简单又快速。直到您遇到限制，例如数据库上的大量锁。

对此的解决方案是异步通信。您通过即发即弃方式发送一些信息。这解决了时间耦合。与其拥有一个收到数十个更新数据等请求的数据库，不如让您的网站逐渐停止运行，您可以通过多种选择来确保这种情况不会发生。这真是一件好事，因为您拥有各种更小的操作和许多分布式工作、扩展系统等方式，而不是单个原子操作。

它也带来了额外的挑战，因为不是每个人都能使用即发即弃的方式工作。一些已经构建的系统尝试通过消息传递(希望是 NServiceBus)引入异步通信。有些部分可以完美地工作。但其他部分不能。主要是用户界面(UI)。因为它是为了立即获得结果而构建的。因此，当您从 UI 发送消息时，您会期待一个结果!

通过 NServiceBus，我们构建了一个名为“客户端回调”的包，使这成为可能。我们强烈建议我们的客户不要使用它，除了我刚才描述的这个特定场景。迁移整个 UI 以应对您没有立即收到答复这一事实要好得多，但我们知道这是一项艰巨的工作，没有多少人能够做到这一点。

然而，一旦发送了第一条消息并且 UI 收到了结果，就没有必要再使用回调了。因此，我想提出这种情况:

1. 使用电话http://test.com/purchase?itemId=5&paymentId=133
2. 网络服务器调用 await endpointInstance.Request<PurchaseResult>();
3. PurchaseMessage处理程序检索它需要的信息并将消息发送或发布到(一个)其他组件，然后用答案回复到网络服务器。
4. 下一个处理程序处理发送/发布的消息并继续该过程

如果您需要更多信息，请告诉我们。您可以随时通过发送电子邮件至 support@particular.net 与我们联系