消息總線中的總線發現

我想讓我的頭繞着消息總線和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

消息總線中的總線發現

回答

相關問題