NServiceBus 设计理念

Question

任何具有 NServiceBus 经验的开发人员/架构师都可以提供以下方面的指导和帮助吗？

我们在业务中需要(而不是很多钱)在外部托管的应用程序和我们的内部 ERP(是的，不止一个)之间创建一个健壮的接口(interface)。

当第三方应用程序中发生某些事件时，他们会向我们发送消息。即调用 Web 服务，在消息中传递各种信息字段等。我们无法控制也无法更改此第三方应用程序。

我的职责是创建这个 Web 服务并将消息处理到每个 ERP 中。第三方决定了 Web 服务的外观，但不决定它负责什么。我们必须接受，如果他们得到“成功”的回复，那么我们此时已对该消息负责!即，我们需要确保几乎没有数据丢失发生。

这是我对使用 NServiceBus 感兴趣的地方。首先使用它来存储/接受消息。在这一点上，我迷路了，我不知道应该发生什么，即遵循什么设计。另一台机器(进程)是否订阅并抓取消息以将其处理到 ERP 中，如果是这样，因为每个 ERP 集成逻辑不同，我是否为每个 ERP 制作一个订阅者？但是，一条消息可能有两个目标 ERP 目标，因此最好发送消息而不订阅消息。

显然，在整个设计中，我需要一些有助于确定目标 ERP 的业务规则，然后是确定每个 ERP 中实际发生的业务规则。所以我也有关于 BRE 的问题，但这可以等待，尽管仍然可能是消息必须执行的驱动程序。

所以:

第三方>网络服务调用>存储消息(&返回成功)>确定哪个ERP是目标>处理每个到ERP>标记消息完成

如果任何事情都失败了，请确保消息不会丢失。 p.s.整机可能死机，MSMQ如何防止丢失？这只是磁盘弹性等吗？

非常感谢您阅读，甚至更多的任何建议。

Answer 1

这听起来像是一个完美的 NServiceBus 应用程序。

您的 Web 服务应该只解析来自第三个的请求并将其转换为 NServiceBus 消息，它应该 Bus.Send() .在该消息到达总线之前，您不会使用 200 状态代码进行响应，此时，您应对此负责，并且 NServiceBus 的内置错误/重试和错误队列设施成为您最好的 friend 。

此消息应该由另一个端点接收，但它需要能够考虑重复消息或使用幂等性，以便重复不是问题。如果第三方访问了您的 Web 服务，并且消息已成功放置在总线上，但随后某些错误阻止他们接收 200 响应代码，您将从他们那里得到重复。

此时，接收 MessageFromWebServiceCommand 消息的端点可以 Bus.Publish()包含命令数据的 SomeBusinessEventHappenedEvent。

对于每个 ERP，创建一个订阅 SomeBusinessEventHappenedEvent 的附加端点，并使用您的业务逻辑来决定对该 ERP 执行什么操作。在某些情况下，“某事”可能是“无”。这里也要记住幂等性，因为如果消息失败，它将被重试。

由于 NServiceBus 和 MSMQ 对此类问题具有天然的弹性，您担心的所有其他事情(防止消息丢失、机器死机时会发生什么)都将得到解决。

这是一篇博客文章，包括一个示例项目，展示了如何通过 Web 服务接收来自外部合作伙伴的消息并使用 NServiceBus 处理它们，以及直接指向 GitHub 上示例项目的链接:

Robust 3rd Party Integrations with NServiceBus

Project Source Code on GitHub