我一直在阅读NServiceBus网站上的文档，但我很难将它们拼凑在一起。
目标是在内部部署后台系统与另一个数据中心的面向公众的网站之间提供持久的消息传递解决方案。
我需要双向（内部部署＆lt;＆gt;网站）pub-sub和请求 - 响应通信。
文档清楚地表明，所有通信都没有一个中心点，但订阅确实需要在某个地方（在一个中心位置？）持续存在。
NServiceBus gateway确实看起来符合我的要求，但我找不到任何有用的例子。
有人可以提供有关网关如何工作以及是否符合我要求的更多细节吗？
答案 0 :(得分：1)
订阅将保留在每个发布者端点上。假设您有一个服务端点发布Web订单。所有其他感兴趣的服务可以通过向发布者发送订阅消息来订阅，然后发布者在本地存储订阅。当消息可用时，发布者评估订阅并向每个订阅者发送消息。
这将我们带到您的其他要求 - 请求/响应的要求。因为NSB基于msmq，所以一切都是异步的。发布者可以做的最多就是向呼叫者发送响应，只是说已经收到请求并将被发布。异步消息传递的本质意味着您无法获得任何下游订阅者的同步响应。
但是这种成本带来了好处 - 即可靠性和可用性。
可靠性 - 因为您正在使用持久消息传递，所以最终将传递消息，此时可以生成响应，最终也可以找到返回调用者的消息。与请求响应相比，这是非常可靠的。
可用性：因为发布者服务总是能够发送消息（下游订户是否可用），所以它永远不需要阻止传入的请求。如果您以某种方式对发布商进行负载均衡，则可以轻松地在企业级别实现可用性。
但是，您需要根据延迟要求进行平衡。异步通常等于延迟。因此，如果你有超过100毫秒范围的延迟要求，NSB可能不是你最好的选择。
不回答有关NSB Gateway的查询的道歉 - 我从未使用过它。
希望这有帮助。
答案 1 :(得分：1)
网关解决了站点之间的通信问题。它将确保消息从SiteA传递到SiteB。消息在另一端进行散列和验证。显然在2.5中没有这样的例子，所以我想把它们放在一起，因为在过去一个月里已经出现了几次。