Azure Service Bus - несколько тем?

Question

поэтому краткое резюме о том, с чем я работаю в настоящий момент:

Я принимаю решение, могу ли я сделать это с помощью темы 1 темы, в которой вам нужны темы N и оба с соответствующими метаданными/фильтрами.

У меня есть 3 штуки в значительной степени; к серверу сокетов (рабочая роль), к которым подключаются подразделения в поле, сообщение службы Azure Service Bus и, наконец, веб-приложение. Пользователь может заказывать команды, которые будут отправляться на устройства через веб-приложение, но мы должны иметь возможность хранить сообщения в очереди до тех пор, пока устройство не выйдет в сеть, из которого он получит все сообщения. Вот где я запутался ...

Я изначально работал по линиям динамического создания 1-9999 тем (можно создать лимит из 10 000 тем, используя последние 4 символа сериала) в веб-приложении сообщений в очереди. После этого устройства будут иметь полный серийный номер в метаданных. Таким образом, когда устройства подключаются к серверу сокетов, я могу создать N подписки с определенными правилами и отключить их при отключении устройств.

Но теперь мне интересно, могу ли я просто иметь 1 тему и поместить всю логику в метаданные?

Я новичок в SQLFilters с сервисной шиной, так что любая помощь будет принята с благодарностью :)

Answer 1

Хороший вопрос! Прежде всего, я должен сказать, что я буду использовать концентраторы IoT в вашей ситуации, которая является сервисом типа «queue», оптимизированным для сценариев IoT, управления и управления. Или Event Hubs, но они меньше оптимизированы для шаблонов команд.

1) Событие концентраторы

2) ИТНЫ Концентраторы

Первый из них для сценариев, которые больше событий-ориентированные. То, что я имею в виду - реализовать управление устройством с бэкэнд будет более сложным с концентраторами событий и менее сложным с концентраторами IoT.

Я бы настоятельно рекомендовал вам ознакомиться с этими услугами, поскольку Service Bus - отличный сервис, но перечисленные службы более ориентированы на IoT.

С точки зрения архитектуры недавно Microsoft опубликовала технический документ IoT Reference Architecture, который вы можете скачать здесь. Он имеет рекомендации, услуги, лучшие практики и т. Д., Которые могут использоваться для проектов Azure + IoT с точки зрения Microsoft.

Другим полезным ресурсом может быть http://azureiotsuite.com. Реализована эталонная архитектура IoT. Таким образом, если вы нажмете на Create, у вас будет одна из двух эталонных архитектур (дистанционный мониторинг или интеллектуальное обслуживание) в вашей подписке Azure, и вы сможете просмотреть все потоки.

Итак, я бы рекомендовал использовать IoT/Event Hubs вместо тематик/очередей SB, потому что в поле IoT служба, оптимизированная для этих рабочих нагрузок, должна работать лучше, чем не оптимизирована изначально.

Во-вторых, вы не указали, как вы подключаете свои устройства к роли рабочего, так как я видел, что есть хорошая библиотека для этого, которая называется SuperSocket.

Так что, как я вижу вашу архитектуру решения может выглядеть так:

устройство 2 Облако:

Devices => Шлюз (SuperSocket или любой другой) || IoT Hub => Реестр устройств (см ссылки, указанные выше)

Cloud 2 устройства:

User Interface => IoT концентратор с зарегистрированного устройства => Device

реестра устройств более удобный способ сделать потоки IoT, чем передача идентификаторов или т. д. Динамическое создание сущностей имеет некоторые недостатки - представьте, если команда создания вернет ошибку тайм-аута, например. Я считаю, что лучше использовать оптимизированные сервисы.

Когда устройство находится в автономном режиме, оно не будет опроса в очереди. Сообщения имеют некоторое время удержания до того, как они будут остановлены, то есть встроенный механизм.