我們正在使用NServicebus設計有解決的方案拍賣系統:我們要發出一個消息,一組可以在一個項目投標的企業。在我們收到所有出價後,我們希望將商品發送給出價最高的出價商。NServicebus時間敏感的拍賣實現
我們最初認爲這種場景非常適合NServicebus:Pub/sub用於發送消息(例如BidOnItem或ItemAvailable),爲每個感興趣的公司訂閱該消息的消息處理程序以及用於存儲不同的消息我們收到的出價,我們完成了。
在一個正常的拍賣,我們可以設定在比方說5分鐘,超時,然後決定誰根據我們收到的最高價格的項目。我們沒有那種奢侈。我們遇到的問題是,我們的具體情況有一個棘手的,不可協商的業務需求:拍賣對時間非常敏感。秒很重要。我們想要做的是在所有公司都做出迴應後立即決定誰獲得該項目。通常這會在幾秒鐘內發生。我們想要決定第二個所有用戶已經做出迴應。顯然我們也會實現一個超時,但這將是例外而不是規則。如果我們想確定是否每個人都回復了,我們需要類似於訂閱了BidOnItem消息的所有端點上的所有處理程序的列表。看來NServicebus API不提供這些信息。
有未來的一些要求,我們必須實現圍繞數據豐富,並會從知道上發佈/訂閱頻道的所有處理是否已作出迴應受益匪淺批准/拒絕的決定以及居中。我知道這惡臭的請求/應答這是一件好事NServicebus鼓勵,因爲它會導致耦合,但這一要求感覺的東西,是一個爲很多的過程,這是非常難以實現的核心總線基礎設施之外的基礎。在這個意義上,它感覺很像NServicebus提供的Saga.ReplyToOriginator。
會是什麼「NServicebus路」來解決這個問題?
看起來像 「變通辦法」 之一,我們認爲。您示例中的RequestBidFrom方法將返回RequestBidFromCompanyX,RequestBidFromCompanyY等的實例,並且處理程序與這些類(可選地分佈在多個端點上)相匹配是否正確? –
這取決於請求的不同。我可能會使用相同的消息,並讓「集成」端點負責不同出價人之間的映射。然後,集成端點可以決定使用不同的消息來更好地進行擴展,監控等。集成端點也可以是保存活動競標者列表的集成端點。請記住,在發送消息時,一個請求會導致多個響應 –
謝謝Andreas。我明白你要去哪裏。感覺就像我們會建立一些pub/sub可以免費提供給我們的東西。我們想聽到的是爲什麼pub/sub不是這樣的方式:是因爲當前NServicebus API的限制還是因爲它本質上不是一個好的模式,如果是這樣,爲什麼? –