Можно ли повторно использовать подключения в функциях Azure при отправке сообщений с устройства в облако на IoTHub? - PullRequest
1 голос
/ 05 октября 2019

У меня есть Azure IoTHub с тысячами зарегистрированных устройств. Эти устройства взаимодействуют через поставщика Telco, который отправляет сообщения через очередь хранилища Azure. Эта очередь хранения запускает функцию Azure, которая должна проанализировать сообщения и отправить событие на IoTHub, как показано ниже. enter image description here

В настоящее время мы используем Azure IoTHub SDK для создания DeviceClient для каждой полезной нагрузки и отправляем событие. Поскольку DeviceClient представляет устройство в IoTHub и несет контекст источника событий, нам приходится заново создавать клиент устройства для каждого события. Это быстро превышает пороговое значение числа соединений, разрешенных для функций Azure.

Мы пытались использовать привязки вывода IoTHub для функций Azure, но не смогли приступить к работе, и я не думаю, что это сработает, потому что нам нужно убедиться, что события попадают в IoTHub с правильным контекстом (сообщения отправляются нужным устройством).

Как правильно решить эту проблему? Можно ли повторно использовать соединения с IoTHub? Должны ли мы отказаться от Azure Function в пользу чего-то другого?

Ответы [ 2 ]

1 голос
/ 06 октября 2019

Я предполагаю, что Telco - это какое-то нестандартное решение для управления устройствами (решение для блокировки поставщиков), которое также может обмениваться данными с устройством и получать телеметрию устройства и, в конечном итоге, перенаправлять его на указанную конечную точку, правильно? * Если я могу спросить, и если мое предположение верно, зачем вам доставлять события в IoT Hub, если вы не управляете устройствами Telco через IoT Hub (стрелки на диаграмме только в одном направлении)?

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

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

Сохраните IoT Hub и настройте маршрутизацию к ранее созданному Event Hub.

Теперь, если у вас есть устройства, которые не заблокированы поставщиком и могут напрямую взаимодействовать с IoT Hub, сообщения будут перенаправляться в Event Hub. Также сообщения устройств Telco будут направляться точно в тот же концентратор событий.

Теперь у вас может быть, например, Azure Stream Analytics, который может анализировать поток данных только из концентратора событий, как для устройств Telco, так и для устройств, которые могут не являться Telco.

0 голосов
/ 01 ноября 2019

Попробовав несколько вещей, я отказался от использования SDK для отправки сообщений в IoT Hub. Это связано с тем, что в SDK используется AMQP, а создание DeviceClient для каждой полезной нагрузки невозможно. Вместо этого мы перешли на использование HTTPS для отправки сообщений в IoT Hub, а с помощью HttpClientFactory мы можем создавать пулы соединений. Я думал, что поместил бы это здесь в случае, если у кого-то есть та же самая проблема.

Вот пример запроса Http на отправку сообщения в IoT Hub

Host: https://<iothubname>.azure-devices.net/devices/<deviceId>/messages/events?api-version=2018-06-30

Authorization: SharedAccessSignature sr=<iothubname>.azure-devices.net&sig=abc123;12344iweoippweruea=iothubowner&se=1570574220

Body: <normal Interval or alarms payloads> // example {"deviceid": "abc", "hello": "world"}

Наконец, спасибо @kgalic за ответ, но ваше предложение не сработает. Это не чистая интеграция B2B. Наша реализация должна позволять подключать устройства как непосредственно к IoT Hub, так и устройства через Telco. Вот почему каждое устройство должно иметь свою собственную идентичность и цифровой близнец.

...