NServiceBus：共享消息 DLL
我最近一直在研究 NServiceBus，因为我认为消息传递是减少系统之间依赖关系的好方法。然而，让我印象深刻的第一件事是消息发布者和所有订阅者必须共享消息定义 DLL。在这种情况下会发生什么？：
假设有一个处理客户数据的中央系统。每当客户记录发生更改时，它都会发布一条包含姓名和地址的消息。它有十个订阅者，它们在收到消息后更新其本地数据副本。
有一天，需求发生变化，其中一位订阅者也需要客户的电话号码。消息、发布者和受影响的订阅者都被更新以处理电话号码，并且它们都被重新编译和发布。
其他九个订阅者是否会继续不受影响？它们是否会像往常一样使用旧的 Message DLL，还是都需要使用新的 DLL 进行更新、重新编译并发布？
I have been recently looking into NServiceBus, as I thought messaging would be a good way to reduce dependencies between systems. However, one of the first things that struck me is that the message publisher and all subscribers have to share the message definition DLL. What would happen in this scenario?:
Say there is one central system that handles client data. Whenever a client record is changed, it publishes a message, containing name and address. This has ten subscribers, which update their local copy of the data on receipt of the message.
One day, requirements change and one of the subscribers need the clients phone number as well. The message, the publisher, and the affected subscriber are all updated to handle the phone number, and they are all recompiled and released.
Will all nine other subscribers continue unaffected? Will they carry on as normal with the old Message DLL, or will they all need to be updated with the new DLL, recompiled and released as well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
NServiceBus 架构旨在能够适应消息结构更改（尤其是在更改涉及添加信息（如您的场景中））。请参阅 NServiceBus 站点上的版本控制示例页面。
The NServiceBus architecture is designed to be resilient to message structure changes (especially where the changes involve adding information like in your scenario). See the Versioning Sample page on the NServiceBus site.
您不能像版本控制示例中概述的那样在 NSB 中处理版本控制。
如果您在发送/接收场景中实现 NSB，则可以执行此操作。在这种情况下，尽管合约是消息 DLL，但发送者和接收者之间不需要共享相同的 DLL 版本。这是因为在线提供 XML 将在接收端干净地反序列化，一切都会好起来的。
然而，这在发布-订阅场景中完全失效了。在这种情况下，发布者和订阅者之间共享的消息传递程序集的版本完全相同。这意味着版本、公钥令牌等都需要相同。其原因在于订阅机制。
当订阅者启动时，它将向发布者发送一条订阅消息，然后发布者会将订阅输入订阅数据存储中。此订阅适用于源自特定程序集版本的消息。
如果发布者随后更新其消息 DLL 的版本并收到需要发布的消息，它将对其持有的订阅进行查找并依次评估每个订阅。由于订阅存在于消息组件的先前版本，因此评估过程将忽略该订阅条目，因此不会向订阅者发送任何消息。
您需要了解发布-订阅场景中的这种硬依赖关系。
希望这有帮助。
编辑
从 NServiceBus 3.x 版本开始，只要您的消息程序集主要版本在发布者和订阅者之间共享，那么发布-订阅将正常工作。
It is not the case that you can handle versioning in NSB like they outline in the Versioning Sample.
You can do this if you are implementing NSB in a send/receive scenario. In this instance even though the contract is a messages DLL, the same DLL version does not need to be shared between senders and receivers. This is because providing the XML on the wire will de-serialize cleanly on the receiver end all will be well.
However, this completely breaks down in a pub-sub scenario. In this case, there is a dependency on the exact same version of the messaging assembly being shared between publisher and subscribers. This means the version, public key token etc all need to be identical. The reason for this is the subscription mechanism.
When your subscriber starts up it will send a subscription message to the publisher, who will then enter the subscription in the subscription data store. This subscription is for messages originating in a specific assembly version.
If the publisher then updates it's version of the messages DLL and receives a message which it needs to publish, it will do a lookup against the subscriptions it holds and evaluates each one in turn. Because the subscription exists for a previous version of the messages assembly the evaluation process will ignore that subscription entry, and therefore no message will be sent to the subscriber.
You need to be aware of this hard-dependency in the pub-sub scenario.
Hope this helps.
Edit
As of version 3.x of NServiceBus as long as your messages assembly major version is shared between publisher and subscriber then pub-sub will work as normal.