消息总线中的总线发现

我想让我的头绕着消息总线和ioc的，而我的脑袋正在旋转着问题。消息总线中的总线发现

这是我心目中

三台电脑通过局域网，无法上网连接的情况。这三台电脑每台都有一个运行的服务并自动发现其他服务器，换句话说，它们每个都在一个公共总线上发送消息。这标识自己。

从这一点上他们可以交换任何类型的消息。

在第一种情况下，这可能只是使用消息总线体系结构吗？

如果是这样，自我发现位将如何工作？我所见过的所有例子似乎都是机器特有的本地队列。我似乎找不到远程队列发送消息或自我发现完成的例子。

我有一个当地的服务与.Net中的rebus一起工作，但是现在想要了解这个难题的缺失部分。

我不是在谈论任何使用ASP.Net或此刻的任何花哨的设置。任何帮助非常感谢

来源

2014-05-06 Bernard

我发现WCF发现服务http://msdn.microsoft.com/en-us/library/dd456791(v=vs.110).aspx也可靠的机器发现。当然，我只在一台本地机器上试过它，但可以使用wcf服务来发现机器及其ips，并订阅总线。 – Bernard

所以我不知道rebus，但我可以深入谈论MassTransit。

如果我想要一个没有互联网连接的系统能够自动注册总线，以便它可以与同行交换消息，有两个主要选项可以想到。

RabbitMQ或MSMQ具有每个实例连接到的已知中央位置。使用RabbitMQ，每个人都使用的RabbitMQ实例很简单，比如rabbitmq：//10.0.0.10/my_queue作为配置中的ReceiveFrom地址。对于MSMQ，订阅服务队列位置将为msmq：//10.0.0.10/mt_subscriptions。那么ReceiveFrom队列应该是msmq：// localhost/my_queue。一旦巴士共享一个中心位置，那么所有的同伴都可以通信。
有一个“双总线”系统。首先使用MSMQ的多播进行发现。基本上每分钟播出一次消息，直到找到中央服务器，然后启动另一条总线，如＃1，但使用从多播总线提供的地址。如果您使用RabbitMQ，则意味着混合RabbitMQ和MSMQ总线。
第三个但不是真棒的可能性就是使用MSMQ的多播订阅客户端。这并不完美，因为多播不是为生产而设计的。但是，如果权衡可以接受，那么你可以使用它。 MSMQ多播在服务开始执行和订阅完全协商之间存在启动延迟。如果您立即开始发布，这可能会导致信息丢失。多点传送需要在同一子网上的所有机器，或者使用路由器回传vodoo magic *以使多播在子网上工作。

值得注意的是，这与IoC没有任何关系。这真的只是一个配置的东西。 MassTransit的想法是，一旦您注册了公交车，只要公交车的另一位成员发布了该信息，该消息将自动终止于该消息的所有消费者。

*注意：我很确定它不是黑色vodoo魔术但是据我担心它是。你需要别人的帮助才能完成这项工作。

第二个注意：使用MSMQ时，在本地主机上使用ReceiveFrom队列很重要。发送到远程主机工作得不错，但是当出现问题时，读取更难以诊断。

3rd注意：除非您要求所有同龄人都注册DTC，否则我将每次推广RabbitMQ而不是MSMQ。如果这是对你的要求，我祝你好运，满意你的心痛。

来源

2014-05-06 13:34:46 Travis

非常感谢您的全面回答！我很抱歉没有回应。我被拉到另一个项目，但我终于回来了，所以我会尝试的建议。 +1 – Bernard

借助Rebus，您可以通过使所有三个服务端点共享相同的订阅存储，轻松实现您所描述的行为，例如，一个中央的SQL Server/MongoDB/RavenDB/PostgreSQL数据库，然后让每个订阅者通过订阅。

为了自己订阅，端点必须是所有消息类型的所有者，例如，通过在app.config中以下卤面XML：

<configSections> 
    <section name="rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" /> 
</configSections> 

<rebus inputQueue="myOwnInputQueue" errorQueue="[email protected]"> 
    <add messages="SomeMessageAssembly" endpoint="myOwnInputQueue"/> 
</rebus>

这样，每个端点只需做一个bus.Subscribe<SomeMessage>()以登记为特定消息类型的用户，并从该点上它会得到处理所有发布的SomeMessage s，而不管哪个端点发布它（注意：包括它本身！）

如果端点需要过滤传入消息的发送者，它可以检查rebus-return-address头，以便例如忽略它自己发布的消息。

如果您想用除提到的数据库选项之外的其他方式来集中您的订阅存储，则可以使用您自己的IStoreSubscriptions实现来存储其他位置的订阅，或使用其他逻辑来决定谁接收给定类型的消息。

看看the IStoreSubscriptions wiki page更多的信息和灵感:)

这是否有意义？

更新：我忍不住了，我不得不尝试 - 在Rebus samples repository检查出MessageBus sample - 这是我在这里描述的通过使用共享的XML文件来存储订阅解决方案的POC。

来源

2014-05-09 20:34:25 mookid8000

作者本人就在身边！非常感谢样品，我被剥离了项目做其他事情，但现在我又回来了，所以我会尝试所有建议的选项并报告回来。 – Bernard

消息总线中的总线发现

回答

相关问题