NServiceBus的设计思路

Tez*_*zza 4 nservicebus

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

我们要求业务(而不是很多钱)在外部托管的应用程序和我们的内部ERP之间创建一个强大的接口(是的,不止一个).

当某些活动在第三方应用程序中发生时,他们会向我们发送消息.即调用通过消息等各种信息领域的Web服务.我们无法控制,也无法更改此第三方应用程序.

我的职责是创建这个Web服务并将消息处理到每个ERP中.第三方决定了Web服务的外观,而不是它的责任.我们必须接受,如果他们得到"成功"的回复,那么我们此时已对此消息负责!即我们需要确保接近完美,不会发生数据丢失.

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

显然,在整个设计中,我需要有一些业务规则来帮助确定目标ERP,然后确定业务规则,以确定每个ERP中实际发生的情况.所以我也有一个关于BRE的问题但是这可以等待,尽管仍然可能是消息必须做的驱动因素.

所以:

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

如果任何事情都失败了,确保消息不会丢失.ps由于整个机器可能死亡,MSMQ如何防止丢失?这只是磁盘弹性等吗?

非常感谢您的阅读,甚至更多的建议.

Dav*_*ike 8

这听起来像NServiceBus的完美应用程序.

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

此消息应该由另一个端点接收,但它需要能够考虑重复的消息或使用幂等性,以便重复不是问题.如果第三方命中您的Web服务,并且消息已成功放置在总线上,但是由于某些错误导致它们无法接收200响应代码,您将从它们获得重复项.

此时,接收MessageFromWebServiceCommand消息的端点可能Bus.Publish()是包含命令数据的SomeBusinessEventHappenedEvent.

对于每个ERP,创建一个订阅SomeBusinessEventHappenedEvent的附加端点,并使用您的业务逻辑来决定该ERP的相应操作.在某些情况下,"某事"可能是"没有".在这里也要记住幂等性,因为如果消息失败,它将被重试.

所有其他你担心的事情(防止丢失消息,如果机器死亡会发生什么)将由于NServiceBus和MSMQ自然适应这些问题而得到照顾.

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