帮助 NServiceBus 架构
我一直在阅读 NServiceBus 网站上的文档，但正在努力将其拼凑在一起。
目标是在本地后台系统和另一个数据中心面向公众的网站之间提供持久的消息传递解决方案。
我将需要双向（本地<>网站）发布-订阅和请求-响应通信。
该文档清楚地表明，所有通信都没有一个中心点，但订阅肯定需要保存在某个地方（在一个中心位置？）。
NServiceBus gateway 看起来确实可以满足我的要求，但我找不到任何工作示例这。
有人可以提供有关网关如何工作以及它是否满足我的要求的更多详细信息吗？
I've been reading through the documentation on the NServiceBus site but am struggling to piece it all together.
The goal is to provide a durable messaging solution between on-premise back office systems and a public facing web site in another data center.
I will need bidirectional (on-premise <> web site) pub-sub and request-response communication.
The documentation makes it clear that there isn't one central point that all communication goes through, but surely the subscriptions need to persisted somewhere (in a central location?).
The NServiceBus gateway does look like it would meet my requirements but I can't find any working examples of this.
Can someone provide a bit more detail on how the Gateway works and whether it will meet my requirements?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
订阅会保留在每个发布者端点上。假设您有一个发布 Web 订单的服务端点。所有其他感兴趣的服务都可以通过向发布者发送订阅消息来进行订阅，然后发布者将订阅存储在本地。当消息可用时，发布者评估订阅并向每个订阅者发送消息。
这给我们带来了您的其他要求 - 请求/响应。因为NSB是基于msmq的，所以一切都是异步的。发布者最多可以向调用者发送响应，仅表示请求已收到并将发布。异步消息传递的本质意味着您无法从任何下游订阅者获得同步响应。
但这种成本也带来了好处——即可靠性和可用性。
可靠性 - 因为您使用的是持久消息传递，所以消息最终将被传递，此时可以生成响应，该响应最终也将找到返回给调用者的方式。与请求响应相比，这是高度可靠的。
可用性：由于发布者服务始终能够发送消息（无论下游订阅者是否可用），因此它永远不需要阻止传入请求。如果您以某种方式对发布商进行负载平衡，您就可以轻松实现企业级别的可用性。
但是，您需要平衡这一点与您的延迟要求。异步通常等于延迟。因此，如果您的延迟要求在 100 毫秒以下范围内，NSB 可能不是您的最佳选择。
很抱歉没有回答您有关 NSB 网关的询问 - 我从未使用过它。
希望这有帮助。
The subscriptions are persisted on each publisher endpoint. Say you have a service endpoint publishing web orders. All other services who are interested can subscribe by sending a subscription message to the publisher, who then stores the subscriptions locally. When a message is available the publisher evaluates the subscriptions and send a message to each of the subscribers.
This brings us onto your other requirement - that of request/response. Because NSB is based on msmq, everything is asynchronous. The most a publisher could do is send a response to a caller just saying that the request has been received and will be published. The nature of async messaging means that you cannot have a synchronous response from any downstream subscribers.
But this cost comes with benefits - namely reliability and availability.
Reliability - because you are using durable messaging the messages will eventually be delivered, at which point a response can be generated which will also eventually find it's way back to the caller. This is highly reliable when compared to request response.
Availability: because the publisher service is always able to send a message (whether a downstream subscriber is available or not), it never needs to block incoming requests. If you load balance your publisher somehow you can easily achieve availability at enterprise levels.
However you need to balance this against your latency requirements. Asynchrony usually equals latency. So if you have latency requirements in the sub-100 ms range NSB may not be your best bet.
Apologies for not answering your query about NSB Gateway - I have never used it.
Hope this helps.
网关解决站点之间的通信问题。它将确保消息从 SiteA 传递到 SiteB。消息在另一端进行哈希处理和验证。显然 2.5 中没有这样的例子，所以我正在考虑将一个放在一起，因为在过去的一个月里这个问题已经出现了几次。
The Gateway solves the communication problem between sites. It will ensure that messages get delivered from SiteA to SiteB. The messages are hashed and validated on the other end. Apparently there isn't an example of this in 2.5, so I'm thinking of throwing one together as this has come up a few times in the past month.