NServiceBus消息类型和思维过程
在我们的场景中，我正在考虑使用 pub sub 技术。但我不知道哪个是更好的选择。
1 ########
我们的一个Web服务，在外部调用的时候，会发布一条发生了事情的消息，ExternalPersonCreatedMessage！
该消息将包含一个字段，该字段表示将消息处理到的目的地（允许多个）。
各种订阅者都会订阅。这些订阅者将通过检查目标字段来过滤消息，以查看是否需要执行任何操作。
2 ########
我们的 Web 服务将解析传入呼叫并根据字段中提供的目的地发布特定类型的消息。即会创建许多 Destination[n]PersonCreatedMessage 消息。
订阅者将仅订阅他们关心的特定消息。即不必过滤任何消息
问题
以上哪一个是更好的选择，为什么？我该如何阻止自己发出 RequestMessages。从我读过/看到的内容来看，我应该尝试以 PersonCreated、PersonDeleted 的方式来构建它，即在“请求某事发生”表单中发生了一些事情，并且没有，例如 CreatePerson 或 DeletePerson
是我的想法正确的？我一直在寻找有关如何构建消息并确保我不会走上错误道路的指导，但没有找到关于该做什么和不该做什么的指导。任何人都可以提供帮助和指导吗？我想尝试从一开始就正确地做到这一点:)
In our scenario I'm thinking of using the pub sub technique. However I don't know which is the better option.
1 ########
A web service of ours will publish a message that something has happened when it is called externally, ExternalPersonCreatedMessage!
This message will contain a field that represents the destinations to process the message into (multiple allowed).
Various subscribers will subscribe. These subscribers will filter the message to see if any action is required by checking the destination field.
2 ########
A web service of ours will parse the incoming call and publish specific types of messages depending on the destinations supplied in the field. i.e. many Destination[n]PersonCreatedMessage messages would be created.
Subscribers will subscribe to only the specific message they care for. i.e. not having to filter any messages
QUESTIONS
Which of the above is the better option and why? And how do I stop myself from making RequestMessages. From what I've read/seen I should be trying to structure this in a way of PersonCreated, PersonDeleted i.e. SOMETHING HAS HAPPENED and NOT in the REQUEST SOMETHING TO HAPPEN form such as CreatePerson or DeletePerson
Are my thoughts correct? I've been looking for guidance on how to structure messages and making sure I don't go down a wrong path but have found no guidance out there on do's and dont's. Can any one help and guide? I want to try and get this correct from the off :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据参考文章中的集成场景，在我看来，您可能需要一个 Saga 来完成接受消息 -> 的工作流程。对消息进行操作->发送确认。在操作后立即发送确认的情况下，您可以使用 NSB 消息处理程序管道功能，该功能允许您按指定顺序链接处理程序，例如...
在内容过滤方面，您可以执行此操作，尽管您会产生一些传输开销，这意味着队列必须接受消息，并且进程将始终调用每条消息的第一个处理程序（您可以随时短路上述管道）。可能的情况是，您真正想要的是一个分发者/工作人员设置，其中所有工作人员都是相同的，并且您可以处理一些负载。
如果您确实有具有完全不同逻辑的不同端点，那么我会让发布者进程（仅接受和发布消息）完成将入站消息转换为订阅者可以感兴趣的其他内容的工作。如果您发现给定的 Published 消息只有 1 个订阅者，那么您根本不需要 Publish，您只需 Bus.Send() 到正确的端点。
Based on the integration scenario in the referenced article, it appears to me that you may need a Saga to complete the workflow of accept message -> operate on message -> send confirmation. In the case that the confirmation is sent immediately after the operation, you could use NSBs message handler pipeline feature which allows you to chain handlers in a specified sequence such as...
In terms of the content filtering, you can do this although you incur some transport overhead, meaning the queue will have to accept the message and the process will always call the first handler on every message(you can short-circuit the above pipeline at any point). It may be the case that what you really want is a Distributor/Worker setup where all Workers are the same and you can handle some load.
If you truly have different endpoints with completely different logic, then I would have the Publisher process(only accepts and Publishes message) do the work of translating the inbound message to something else a Subscriber can then be interested in. If then you find that a given Published message only ever has 1 Subscriber, then you don't need to Publish at all, you need to just Bus.Send() to the correct endpoint.
NServiceBus 处理发布-订阅的方式更像是您的选项二。
在我看来，你应该停止考虑目的地。消息就是消息。它们不应包含任何固有的目的地信息。订阅机制定义了解决方案的寻址/路由要求。
The way NServiceBus handles pub-sub is more like your option two.
In my opinion, you should stop thinking about destinations. Messages are messages. They should not have any inherent destination information in them. The subscription mechanism defines the addressing/routing requirements for the solution.