Azure Service Bus-多個主題與篩選的主題

Question

我已經使用許多應用程序訂閱的主題將Azure Service Bus的實現寫入了我們的應用程序。 我們團隊中的討論之一是我們是堅持一個主題，還是通過消息的屬性進行過濾，或者創建一個滿足我們特定需求的主題。

我們的場景是希望按優先級和環境變量（測試和uat環境共享連接）進行過濾。

因此，我們是否有主題（類似）：

• TestHigh
• TestMedium
• TestLow
• UatHigh
• UatMedium
• UatLow

或者 ，僅將這些值設置為兩個屬性的單個主題？

我的偏好是我們創建單獨的主題，因為我們將利用可用的功能，並且我想在高負載下這樣做會更好嗎？ 我讀過偷看大隊列可能效率低下。 訂閱一個主題似乎也比較干凈。

任何意見，將不勝感激。

Answer 1

兩種方法都有效。 更多主題和訂閱意味着您在部署時需要管理更多實體。 如果高/中/低反映了優先級，則多個主題可能是一個更好的選擇，因為您可以先從優先級最高的訂閱中提取。

從可伸縮性的角度來看，由於Service Bus已經在內部將負載分散到多個日志中，因此您實際上不會注意到太多差異，因此，如果您使用六個主題或兩個主題將不會產生實質性的變化。

影響性能可預測性的是服務類別的選擇。 如果選擇“標准”，則吞吐量和延遲是共享多租戶基礎結構上的最大努力。 同一群集上的其他租戶可能會影響您的吞吐量。 如果選擇“ Premium” ，則會獲得使您的性能可預測的異常資源，並且從該資源池中處理兩個或六個Topic。

Answer 2

我將針對每種環境分別討論不同的主題。 比較干凈 可以針對每個環境分別監視主題中的郵件數。 它的可擴展性略高一些（例如，不會共享主題大小限制）-但是這些限制很寬泛，在測試中沒有太大關系。

但是我的主要觀點是：這就是（希望）生產的方式。 與之類似，生產將在ASB中擁有自己的連接（和名稱空間），並且將具有單獨的主題。 因此，您將不會在生產環境中通過屬性過濾消息，那么為什么在測試中會有所不同呢？

最后提示：為了簡化主題設置，我建議您的應用在啟動時自動創建主題。 這很容易-檢查它們是否存在，並創建它們是否不存在。