在我们的场景中,我正在考虑使用pub sub技术。但是我不知道哪个是更好的选择。
1 ########
我们的网络服务会发布一条消息,说明在外部调用时发生了某些事情,ExternalPersonCreatedMessage!
此消息将包含一个字段,表示将消息处理为的目标(允许多个)。
各订阅者将订阅。这些订阅者将通过检查目标字段来过滤消息以查看是否需要执行任何操作。
2 ########
我们的网络服务将解析来电并根据该字段中提供的目的地发布特定类型的消息。即将创建许多目的地[ n ] PersonCreatedMessage消息。
订阅者只会订阅他们关注的特定邮件。即不必过滤任何消息
问题
以上哪个是更好的选择,为什么?我如何阻止自己制作RequestMessages。从我所看到/看到的我应该尝试以PersonCreated,PersonDeleted的方式构建它,即SOMETHING HAPPENED和 NOT 在REQUEST SOMETHING TO HAPPEN表单中,例如CreatePerson或DeletePerson
我的想法是否正确?我一直在寻找关于如何构建消息的指导,并确保我没有走错路,但没有找到任何关于做什么的指导而不是。任何人都可以帮助和指导吗?我想尝试从关闭中得到正确的结果:))
答案 0 :(得分:0)
NServiceBus处理pub-sub的方式更像是你的选择二。
在我看来,你应该停止考虑目的地。消息是消息。他们不应该有任何固有的目的地信息。订阅机制定义解决方案的寻址/路由要求。
答案 1 :(得分:0)
根据参考文章中的集成方案,在我看来,您可能需要一个Saga来完成接受消息的工作流程 - >对消息进行操作 - >发送确认。如果在操作后立即发送确认,您可以使用NSBs消息处理程序管道功能,该功能允许您以指定的顺序链接处理程序,如...
First<FilterHandler>.Then<DoWorkHandler>().AndThen<SendConfirmationHandler>();
就内容过滤而言,你可以这样做,虽然你会产生一些传输开销,这意味着队列必须接受消息,并且进程将始终在每条消息上调用第一个处理程序(你可以将上面的内容短路)任何一点的管道)。可能是您真正想要的是分销商/工人设置,其中所有工人都是相同的,您可以处理一些负担。
如果您确实拥有完全不同逻辑的不同端点,那么我将使用Publisher流程(仅接受和发布消息)执行将入站消息转换为订阅者可能感兴趣的其他内容的工作。如果那样的话发现给定的已发布消息只有1个订阅者,那么您根本不需要发布,只需将Bus.Send()发送到正确的端点。