Сервисная шина Azure - несколько тем?

Итак, краткое изложение того, с чем я работаю в данный момент:

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

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

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

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

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


azure c# azureservicebus azure-servicebus-topics servicebus
person David    schedule 17.05.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

1) Центры событий

2) Центры Интернета вещей

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

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

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

Еще одним полезным ресурсом может быть http://azureiotsuite.com. Это эталонная реализованная архитектура Интернета вещей. Итак, если вы нажмете кнопку «Создать», в вашей подписке Azure будет одна из двух эталонных архитектур (удаленный мониторинг или профилактическое обслуживание), и вы сможете просмотреть все потоки.

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

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

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

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

Устройства => Шлюз (SuperSocket или что-то еще) || IoT Hub => Реестр устройств (см. Ссылки, указанные выше)

Устройство Cloud 2:

Пользовательский интерфейс => IoT Hub с зарегистрированным устройством => Устройство

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

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

person Alex Belotserkovskiy    schedule 17.05.2016
comment
Спасибо за быстрый и подробный ответ :) Вы на 100% собираетесь перейти к концентратору IoT, как только наши устройства смогут использовать MQTT, пока мы можем использовать только сокеты Raw TCP. Однако мне ДЕЙСТВИТЕЛЬНО нравится то, что я вижу на SuperSocket. В моей предыдущей работе мне удалось запустить действительно хороший сервер асинхронных сокетов, который обрабатывал более 20 гигабайт необработанных двоичных данных TCP в день :) Итак, я стал мастером мини-сокетов, ха-ха. Прочтите остальное сейчас :) - person David; 17.05.2016
comment
Ах хорошо! Это имеет смысл, почему вы делаете это с помощью сокетов. Тогда да, взгляните на SuperSocket и шаблон реестра устройства. Если вы попробуете удаленный мониторинг Azure IoT Suite, вы увидите, как он работает - устройство имеет интерфейс и ключи для доступа к Центру Интернета вещей, где они регистрируются, и отправляет интерфейс и команды на бэкэнд. Затем команды отображаются на портале, и пользователь может выполнить команду, которая отправится на устройство. Даже если вы еще не можете использовать IoT Hub, я считаю, что это может быть реализовано на сокетах. - person Alex Belotserkovskiy; 17.05.2016
comment
Поцарапайте это, позвонив инженеру по прошивке сейчас, чтобы обсудить добавление MQTT :) Это действительно правильный путь вперед на этой ранней стадии. Огромное спасибо! - person David; 17.05.2016
comment
Абсолютно! Отметьте вопрос, на который был дан ответ, если это было полезно, для использования в будущем. - person Alex Belotserkovskiy; 17.05.2016
comment
Извините меня еще раз, просто быстрый (немного не по теме) вопрос. Можно ли сгенерировать собственные ключи устройства при создании устройства. Или можно указать только DeviceId? - person David; 19.05.2016