消息总线中的总线发现 [英] Bus discovery in message busses

问题描述

我正在设法绕过消息总线和ioc，而我的头却在发问.

I am trying to get my head around message buses and ioc's and my head is spinning with questions.

这是我想到的情况

三台计算机通过局域网连接，无法访问互联网.这三台计算机各自具有运行的服务，并自动发现其他计算机，换句话说，它们分别在公共总线上发送消息?可以证明自己的身份.

Three computers connected by LAN, no internet access. The three computers each have a service that runs and automatically self discovers the others, in other words , they each send messages on a common bus?? which identifies themselves.

从那时起，他们可以交换任何类型的消息.

From that point on wards they can exchange any type of messages.

首先使用消息总线体系结构是否有可能?

Is this possible in the first instance just using a message bus architecture?

如果是，自我发现位将如何工作?我所看到的所有示例似乎都是特定于机器的本地队列.我似乎找不到一个向远程队列发送消息或完成自我发现的示例.

If it is, how would the self discovery bit work? All the examples I have seen seem to be local queues which are machine specific. I cant seem to find an example where remote queues are sent messages or where self discovery is done.

我在.Net中有一个与rebus一起工作的本地服务，但现在希望了解这个难题的缺失部分.

I have got a local service working with rebus in .Net but looking to now understand the missing pieces of the puzzle.

此刻，我不是在谈论使用ASP.Net或其他任何花哨的设置. 任何帮助将不胜感激

I am not talking about any fancy setup using ASP.Net or anything at this moment. Any help is greatly appreciated

推荐答案

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

With Rebus, you can easily achieve the behavior you're describing by making all three service endpoints share the same subscription storage, e.g. a central SQL Server/MongoDB/RavenDB/PostgreSQL database, and then letting each subscriber establish the subscription by subscribing with itself.

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

In order to subscribe with itself, an endpoint must be the owner of all the message types, e.g. by having the following Rebus XML in app.config:

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

<rebus inputQueue="myOwnInputQueue" errorQueue="sharedErrorQueue@anotherMachine">
    <add messages="SomeMessageAssembly" endpoint="myOwnInputQueue"/>
</rebus>

这样，每个端点只需要执行bus.Subscribe<SomeMessage>()即可注册为该特定消息类型的订户，从那时起，它将处理所有已发布的SomeMessage，无论哪个端点发布它(注意:包括它本身！)

This way, each endpoint need only do a bus.Subscribe<SomeMessage>() in order to register as a subscriber of that particular message type, and from that point on it will get to handle all published SomeMessages, regardless of which endpoint publishes it (note: including itself!)

如果端点需要按发送者的身份过滤传入的消息，则可以检查

If an endpoint needs to filter incoming messages by who sent it, it can inspect the rebus-return-address header in order to e.g. ignore messages that it has published itself.

如果您想通过上述数据库选项以外的其他方式来集中订阅存储，则可以使用自己的

If you want to centralize your subscription storage in other ways than the mentioned database options, you can use your own implementation of IStoreSubscriptions that stores subscriptions somewhere else or uses other logic to decide who receives messages of a given type.

请查看 IStoreSubscriptions Wiki页面，以获取更多信息和启发: )

Take a look at the IStoreSubscriptions wiki page for more information and inspiration :)

这有意义吗?

更新:我无能为力，我不得不尝试-检查 Rebus示例存储库中的MessageBus"rel =" nofollow> MessageBus示例是我在此处介绍的解决方案的POC，该解决方案是使用共享XML文件存储订阅的.

Update: I couldn't help it, I had to try - check out the MessageBus sample in the Rebus samples repository - it is a POC of the solution I described here by using a shared XML file to store subscriptions.

这篇关于消息总线中的总线发现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！