2013-03-19 70 views
0

在NServiceBus中考慮服務時,您開始質疑有多少消息處理的消息太多並開始將這些消息分解爲新服務?NServiceBus,使用的消息太多了嗎?

考慮以下情況:我有一個銷售服務,目前可以被分成幾個不同的業務組件,這些都是銷售訂單確認,銷售訂單處理,採購訂單確認和訂單處理。

目前大約有20的消息處理程序和該服務內使用2個傳奇。我擔心的是,在我的網站流量很高的情況下,這可能會導致郵件的初始高峯跳到數百個。考慮到消息需要按照從隊列中取出的順序進行處理,這可能會導致隊列中最後一個消息的延遲(取決於每個消息的處理情況)。

當分離服務中的問題納入更小的業務組件,我覺得這讓事情變得更容易一些。當然,這是一個邏輯上的分離,但它似乎提供了一個清晰和理解層。對我來說,看起來似乎更容易做到這一點,而不是創建新的服務,最終我得到的服務越多,我需要做的維護越多。

有沒有人有類似的擔憂呢?

+0

處理消息時,它們是否都讀取/寫入相同的數據庫/表? – 2013-03-20 07:04:18

+0

我想我知道你要去哪裏。除了用Raven管理自己國家的傳奇外,這些服務被分離到不同的數據庫中。 – Ryan 2013-03-20 10:47:23

回答

1

我想你實際上已經回答了你自己的問題:)

一旦消息量達到一個地步,滯後就成爲一個問題,你可以看看比如你的端點。您不一定需要減少處理程序的數量。您可以簡單地多次安裝該服務,並通過映射將特定消息類型發送到相關端點。

,使其成爲一個簡單的實例安裝和一些配置的變化的問題。因此,您可以在發送時分割消息,以便來自特定源的消息以消息類型結束於特定端點(可能優先級爲)。

我正好做同樣的事情在以前的項目(不使用NServiecBus雖然)我們需要從UI來文檔轉換的消息被儘快處理。我們只需使用自己的一組隊列再次安裝轉換服務,並更改UI配置以將轉換消息發送到新端點。後臺轉換消息仍然會轉到上一個端點。所以這裏的來源確定了分離。

+0

同意,這似乎很像試驗和錯誤場景,您必須查看生產環境中的工作情況。我一直是排隊的粉絲,因爲它是一種強大的消息傳遞方式,但是由於負載的原因,消息流經的時間可能會阻礙事物的發展。我想,一旦你命名了一個服務,你就試圖強制信息適合它,它可能並不總是最好的情況。很高興知道我不是唯一一個在思考這些想法的人,歡呼。 – Ryan 2013-03-20 10:57:45