Azure服務總線 - 多個主題？

Question

所以我現在使用的是什麼樣的簡要總結：

我決定我是否可以做到這一點與1個主題vs需要N個主題，並與相關的元數據/過濾器。

我有3件相當多;套接字服務器（工作者角色），該字段中的單元連接到Azure服務總線消息傳遞以及最終的Web應用程序。 用戶可以通過網絡應用程序將要發送給設備的命令進行排隊，但我們需要能夠在隊列中保留消息，直到設備聯機爲止，然後才能獲取所有消息。這是我困惑的地方...

我最初的工作沿線動態創建1-9999主題（限制10 000個主題可以創建，所以使用最後4個字符串）在Web應用程序上消息正在排隊。然後將在元數據中設備完全串行。這樣，當設備連接到套接字服務器時，我可以創建具有特定規則的N個訂閱，並在設備斷開連接時將其關閉。

但現在我想知道如果我可以只有1個主題並將所有邏輯放在元數據中？

我是很新的SQLFilters與服務總線所以任何幫助，將不勝感激:)

Answer 1

問得好！首先，我應該說我會在您的情況下使用物聯網集線器，這是針對物聯網場景，管理和指揮而優化的「隊列」式服務。或事件中心，但它們不是優化命令模式。

1）事件集線器

2）的IoT集線器

第一個是對於那些更多的場景事件導向。我的意思是 - 通過事件中心實現對後端設備的管理將變得更加複雜，並且與物聯網中心的複雜性降低。

我強烈建議你看看這些服務，因爲服務總線是很棒的服務，但列出的服務更多的是面向物聯網的服務。

從架構角度來看，最近微軟發佈了物聯網參考架構白皮書，您可以在這裏下載。它具有可從微軟的角度用於Azure +物聯網項目的建議，服務和最佳實踐等。

另一個有用的資源可能是http://azureiotsuite.com。它是實施的參考物聯網架構。因此，如果您單擊創建，您將在Azure訂閱中擁有兩個參考體系結構（遠程監控或預測性維護）之一，並且您將能夠查看所有流。

因此，我建議考慮使用物聯網/事件中樞而不是SB主題/隊列，因爲在IoT字段中，針對這些工作負載優化的服務應該比未優化的服務執行得更好。

其次，你沒有指定你如何將你的設備連接到工作者角色，所以我看到有一個好的庫可以做到這一點，稱爲SuperSocket。

所以，當我看到你的解決方案體系結構可能看起來像：

設備2雲：

設備=>網關（SuperSocket或其他）||的IoT集線器=>設備註冊表（參見上文指定的鏈接）

雲2設備：與已註冊設備=>設備

用戶界面=>的IoT集線器

設備註冊表是做更方便的方法物聯網流量比傳輸ID等。動態創建實體有一些缺點 - 想象一下，例如，如果創建命令將返回超時錯誤。我相信，更好地使用優化的服務。

當設備脫機時，它不會輪詢隊列。消息在停頓之前會有一些保留時間，這是內置機制。