3

将 NServiceBus Sagas 与 REST API 集成/交互的最明智的方法是什么？

场景如下，

  • 我们有一个负载平衡的 REST API。根据负载，我们可以添加更多节点。
  • REST API 是围绕 DomainServices API 的包装器。这意味着可以直接使用 API。
  • 我们想将 Sagas 用于工作流并实现 NServiceBus Distributor 以进行横向扩展。

问题是，如果我们使用 Sagas 的 REST API，实际处理发生在 API 场中。这在某种程度上违背了实现分发者模式的目的。

另一方面，直接从 Sagas 使用 DomainServives API，允许在工作节点内进行本地处理。使用这种方法，我们将不得不在多个位置维护 API 程序集，但吞吐量可能会更高。

我试图了解最好的方法。就个人而言，我更喜欢使用 API（如果随时可用），但这可能会给系统带来麻烦，并且与进程内相比可能需要更长的时间才能完成。

一个典型的序列可能类似于发布在线广告，

  • 广告商通过 Web 应用程序提交新的广告请求。
  • Web 应用程序调用相关的 API 端点并发送命令消息。
  • 命令消息启动一个新的发布广告 Saga 实例。
  • Saga 发送一个命令来验证调用者权限（进程内/进程外 API 调用）
  • Saga 发送一个命令来验证广告数据（进程中/进程外 API 调用）
  • Saga 向欺诈服务（第三方服务）发送命令
  • 一旦内容和欺诈验证成功，
  • Saga 向计费系统发送命令。
  • Saga 调用 API 调用以保存添加详细信息。（进程中/进程外 API 调用）

这种情况一直持续到广告过期，有许多重试和失败条件路径。

4

2 回答 2

2

经过多次设计迭代后，我们提出了以下准则，

  1. 将 REST API 层视为集成平台。
  2. 假设 API 端点能够抽象出相当复杂的微工作流。微工作流是在单次突发（不可中断）中执行并在很短的时间跨度（<1 秒）内完成的操作。
  3. 假设 API 农场能够服务许多并发请求并且可以轻松横向扩展。
  4. 当目标操作相当简单时，优先使用同步调用而不是基于异步消息的调用。
  5. 当需要异步处理时，使用单个消息处理程序并从处理程序调用 API。这会将工作委派给 API 农场。这也将消除对分销商和额外硬件资源的需求。
  6. 除非业务工作流包含多个事务、补偿逻辑和恢复，否则请避免使用 Saga。测试表明 Sagas 在负载下表现不佳。
  7. 避免直接从消息处理程序中使用 DomainServices。这直到在本地完成工作，并且还通过分发业务逻辑引入了部署麻烦。

很高兴听到想法。

于 2012-11-20T05:29:33.300 回答
0

您正确地确定了您将需要 Sagas 来管理工作流程。我敢打赌，您的域连接到一个通用数据库。如果这是真的，那么直接使用您的域并消除序列化/网络开销会更快。您还将失去在数据库级别轻松管理事务的能力。

假设你直接调用你的域，性能就变成了域如何执行的问题。您可能会采取措施优化数据库、降低分布式事务成本、分片数据等。您最终可能会使用 Distributor 来拥有多个 Saga 处理节点，但听起来一旦设计完成后您需要进行更多测试选择。

一般而言，我们使用 REST API 将命令建模为资源（通过 POST），以允许无法直接访问消息传递的客户端与 NSB 进行交互。这是一个潜在的解决方案，可以将内容从您的 Web 应用程序转移到 NSB。

于 2012-09-17T13:24:47.923 回答