api - NServiceBus Sagas 和 REST API 集成最佳实践

Question

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

场景如下，

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

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

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

我正在尝试了解最佳方法。就个人而言，我更愿意使用 API(如果随时可用)，但这可能会给系统带来麻烦，并且与进程内相比可能需要更长的时间才能完成。

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

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

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

Answer 1

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

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

很高兴听到想法。