消息隊列和服務總線的消息粒度

Question

我正在研究一個應用程序，該應用程序可能會在客戶端上以相當嚴格的循環生成數千條消息，以便在服務器上進行處理。事件鏈如下：

1. 客戶端處理項目，放置在本地隊列中。
2. 本地隊列處理選取消息並調用Web服務。
3. Web服務在服務器上的服務總線中創建消息。
4. 服務總線處理消息到數據庫。

這個想法是所有的通信都是異步的，因爲會有很多web服務的客戶端。我知道MSMQ可以直接做到這一點，但我們並不總是有這樣的管理功能在客戶端設置安全等東西。

我的問題是關於在每個階段的消息的粒度。最簡單的方法將意味着客戶端上處理的每個項目都會生成一個客戶端消息/ Web服務調用/服務總線消息。這很好，但我知道如果可能的話，Web服務調用會更好，除非大粒度Web服務DTO與數據庫上的短期運行之間存在權衡。這種特殊的場景並不需要一個「業務事務」，其中處理全部或不處理任何項目，我只是希望實現消息大小與Web服務調用數量與數據庫事務數量的最佳平衡。

有什麼建議嗎？

Answer 1

查詢界面（即大量和大量的消息）將分派傳入消息（並在客戶端，回覆）到正確的代碼來處理消息（這將是一個固定的每條消息的成本）。雖然大消息傾向於使用資源來處理消息。

此外，許多正在進行的Web服務調用將意味着需要管理很多TCP/IP連接，併發問題（包括鎖定數據庫）可能會成爲問題。

但是沒有消息處理的一些細節，除了由於固定開銷而針對健談的接口的一般建議之外，它很難具體。

Answer 2

先測量，稍後優化。除非你可以做出一個反饋信息的估計，表明最簡單的解決方案會產生不可接受的高負載，那麼嘗試一下，建立好的監督測量，看看它是如何執行和擴展的。 然後開始考慮批量和在哪裏。

這種做法，當然，需要你能夠在部署之後更改Web服務接口，所以你需要一個版本的方法來處理它可能沒有經過重新設計的客戶端，支持若干個並聯的WS版本。但是，無論如何，不​​考慮版本控制幾乎總是會讓你陷入次優界面。

Answer 3

摘要信息隊列

，並具有可交換消息隊列後端。這樣，你可以測試許多後端，並讓自己容易紓困，如果你選錯了一個或成長像一個新的出現。消息傳遞的開銷通常是打包和處理請求。不同的系統針對不同級別的流量和不同的對稱性進行設計。

如果您抽象出基本功能，您可以根據需要更改或調整機械，或更準確地進行評估。

您也可以在應用程序或消息路由的各個部分翻譯來自不同隊列類型的消息，因爲接收方的壓力因爲處理而發生變化，例如1000：1/s比較高級別上的10：1/s。

好運