我們正試圖找到一個優雅的解決方案,用於報告基礎架構中的系統生成的異常,比查看電子郵件或檢查日誌文件更容易操作。服務總線上的發佈/訂閱模式可以很好地解決這個問題。服務將發佈錯誤/事件,並且子訂閱者可以使用簡單模式匹配來過濾這些消息。NServiceBus發佈/訂閱
我們已經調查NServiceBus項目,並想知道它是否會達到我們的要求,着眼於PubSub的樣品(http://docs.particular.net/samples/pubsub/),我們注意到它並沒有解決以下兩種情況:
- 所有出版商發佈相同的消息類型
- 訂戶不應該要求出版商端點
我們已經設法實現這些要求的知識,但我們不確定是否配置COR RECT。以下是我們的解決方案:
所有發佈共享相同的訂閱存儲配置(DBSubscriptionStorage),這是因爲在文檔http://docs.particular.net/nservicebus/messaging/publish-subscribe/
所有發佈/訂戶的訂閱存儲部分中所描述的共享數據庫配置爲使用nservicebus網站文檔中描述的分配器。
我們想知道這是否是正確執行NServiceBus的發佈/訂閱模式,或者是否有可能是另一種解決辦法,acheive我們的目標是什麼?
感謝您的回覆,IBus.Publish和IBus.Send之間的根本區別是什麼? – Matt 2010-06-09 21:50:40
忽略我們的錯誤情況一分鐘,也許考慮一個訂單處理系統,其中一組服務正在發佈他們已經處理的訂單的通知。如果我們打算從多個發佈者向多個訂閱者發佈相同訂單通知消息,那麼共享訂閱存儲是否是正確的實現。當用戶訂閱我們的消息時,訂閱被添加到共享存儲器中,並且該特定消息的所有發佈者開始向我們的訂閱者發佈。這似乎工作,但它是正確的? – Matt 2010-06-09 21:51:28
馬特 - 我認爲你將多個*物理*發佈節點與多個*邏輯*發佈服務結合在一起。NServiceBus強制執行單個邏輯發佈服務,但在該服務中允許使用任意數量的物理節點(在生產配置文件中自動設置,手動執行此操作即可使用DbSubscriptionStorage)。 此外,IBus.Publish用於傳達已經發生*的事件,而Send用於請求我們想要發生的事情(但可能會被拒絕)。事件不能被拒絕(因爲它們已經發生)。 – 2010-06-13 08:38:49