Использование маршрутизации сообщений в Центре Интернета вещей для отправки с устройства в облако в разные конечные точки

Примечание

Некоторые функции, упоминаемые в этой статье, например обмен сообщениями между облаком и устройством, двойники устройств и управление устройствами, доступны только для Центра Интернета вещей уровня "Стандартный". Дополнительные сведения о базовом и стандартном уровнях см. в статье о выборе нужного уровня Центра Интернета вещей.

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

  • Отправка сообщений и событий телеметрии устройства, а именно событий жизненного цикла устройства, событий изменения двойника устройства, событий изменения цифровых двойников и событий состояния подключения устройства ко встроенной и пользовательским конечным точкам. Дополнительные сведения о конечных точках маршрутизации. Дополнительные сведения о событиях, отправленных с устройств IoT Plug and Play, см. в разделе Общие сведения о цифровых двойниках устройств IoT Plug and Play.

  • Фильтрация данных перед их отправкой по различным конечным точкам путем применения полнофункциональных запросов. Маршрутизация сообщений позволяет запрашивать свойства сообщения, текст сообщения, теги и свойства двойников устройств. Дополнительные сведения об использовании запросов для маршрутизации сообщений.

Для маршрутизации сообщений Центру Интернета вещей требуется доступ на запись к этим конечным точкам служб. При настройке конечных точек через портал Azure необходимые разрешения добавляются автоматически. Настройте в службах поддержку ожидаемой пропускной способности. Например, если в качестве пользовательской конечной точки используются Центры событий, необходимо настроить единицы пропускной способности для этого центра событий, чтобы он мог управлять входящим трафиком событий, которые вы планируете отправлять через службу маршрутизации сообщений Центра Интернета вещей. Аналогично, при использовании очереди служебной шины Microsoft Azure в качестве конечной точки необходимо настроить такой максимальный размер, чтобы очередь могла вместить все входящие данных, пока они не будут извлечены объектами-получателями. При первой настройке решения Интернета вещей может потребоваться отслеживание других конечных точек и внесение необходимых корректировок фактической нагрузки.

Центр Интернета вещей задает общий формат для всех случаев обмена сообщениями с устройства в облако для взаимодействия по различным протоколам. Если сообщение соответствует нескольким маршрутам, которые указывают на одну и ту же конечную точку, то Центр Интернета вещей доставляет сообщение в эту конечную точку только один раз. Таким образом, не требуется настраивать дедупликацию для очереди или раздела служебной шины. В этом руководстве вы научитесь настраивать маршрутизацию сообщений.

Конечные точки маршрутизации

В Центре Интернета вещей имеется встроенная конечная точка по умолчанию (messages/events), совместимая с Центрами событий. Вы можете создать пользовательские конечные точки для маршрутизации сообщений, связав с Центром Интернета вещей другие службы в подписке.

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

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

Сейчас Центр Интернета вещей поддерживает следующие конечные точки.

  • Встроенная конечная точка
  • Хранилище Azure
  • Очереди и разделы служебной шины
  • Центры событий

Встроенная конечная точка в качестве конечной точки маршрутизации

Вы можете использовать стандартную интеграцию Центров событий и пакеты SDK, чтобы отправлять сообщения с устройства в облако из встроенной конечной точки (messages/events). После создания маршрута данные перестают поступать на встроенную конечную точку, если для нее не создан маршрут. Даже если маршруты не созданы, для маршрутизации сообщений во встроенную конечную точку необходимо включить резервный маршрут. Резервный маршрут включен по умолчанию, если концентратор создан с помощью портала или интерфейса командной строки.

Служба хранилища Microsoft Azure в качестве конечной точки маршрутизации

Есть две службы хранилища, к которым Центр Интернета вещей может маршрутизировать сообщения: Хранилище BLOB-объектов Azure и учетные записи Azure Data Lake Storage 2-го поколения (ADLS 2-го поколения). Учетные записи Azure Data Lake Storage являются учетными записями хранения с поддержкой иерархического пространства имен, созданными на основе хранилища BLOB-объектов. В обоих случаях для хранения используются BLOB-объекты.

Центр Интернета вещей поддерживает запись данных в службу хранилища Azure в формате Apache Avro и JSON. По умолчанию используется AVRO. Если используется кодирование JSON, для параметра contentType необходимо задать значение application/json, а для параметра contentEncoding — значение UTF-8 в свойствах системы обмена сообщениями. Оба этих значения не учитывают регистр. Если кодировка содержимого не задана, Центр Интернета вещей будет записывать сообщения в формате Base64.

Формат кодирования можно задать только при настройке конечной точки хранилища BLOB-объектов. Его нельзя изменить для существующей конечной точки. Чтобы переключить форматы кодирования для существующей конечной точки, необходимо удалить конечную точку и повторно создать ее в нужном формате. Одной из полезных стратегий может быть создание новой пользовательской конечной точки с нужным форматом кодирования и добавление параллельного маршрута к этой конечной точке. Таким образом, вы можете проверить данные перед удалением существующей конечной точки.

Формат кодирования можно выбрать с помощью REST API создания или обновления Центра Интернета вещей, в частности RoutingStorageContainerProperties, портала Azure, Azure CLI или Azure PowerShell. На следующем рисунке показано, как выбрать формат кодирования на портале Azure.

Blob storage endpoint encoding

Центр Интернета вещей собирает сообщения в пакеты и записывает данные в хранилище при каждом достижении определенного размера пакета или после истечения отведенного времени. По умолчанию Центр Интернета вещей использует следующее соглашение об именовании файлов:

{iothub}/{partition}/{YYYY}/{MM}/{DD}/{HH}/{mm}

Вы можете применять любое соглашение об именовании файлов, однако необходимо использовать все перечисленные токены. Центр Интернета вещей будет записывать пустой большой двоичный объект, если нет данных для записи.

Мы рекомендуем включить большие двоичные объекты или файлы в список, а затем выполнять перебор по ним, чтобы обеспечить считывание всех больших двоичных объектов или файлов независимо от раздела. Диапазон секций может измениться в процессе инициированной корпорацией Майкрософт отработки отказа или при переходе на другой ресурс вручную с помощью Центра Интернета вещей. Вы можете использовать API перечисления больших двоичных объектов или API перечисления ADLS 2-го поколения для составления списка файлов. Ознакомьтесь со следующим примером и используйте его в качестве руководства.

public void ListBlobsInContainer(string containerName, string iothub)
{
    var storageAccount = CloudStorageAccount.Parse(this.blobConnectionString);
    var cloudBlobContainer = storageAccount.CreateCloudBlobClient().GetContainerReference(containerName);
    if (cloudBlobContainer.Exists())
    {
        var results = cloudBlobContainer.ListBlobs(prefix: $"{iothub}/");
        foreach (IListBlobItem item in results)
        {
            Console.WriteLine(item.Uri);
        }
    }
}

Чтобы создать учетную запись хранения, совместимую с Azure Data Lake 2-го поколения, создайте новую учетную запись хранения v2 и выберите параметр включено в поле Иерархическое пространство имен на вкладке Дополнительно, как показано на рисунке.

Select Azure Date Lake Gen2 storage

Очереди служебной шины Microsoft Azure и разделы служебной шины в качестве конечной точки маршрутизации

Для очередей и разделов служебной шины, которые используются как конечные точки Центра Интернета вещей, сеансы или поиск повторяющихся данных должны быть выключены. Если одна из этих возможностей включена, на портале Azure конечная точка будет отображаться как недоступная.

Центры событий в качестве конечной точки маршрутизации

Помимо конечной точки, совместимой со встроенными Центрами событий, вы также можете направлять данные в пользовательские конечные точки типа Центров событий.

Чтение маршрутизированных данных

Вы можете настроить маршрут, следуя инструкциям в этом руководстве.

Из следующих руководств вы узнаете, как читать сообщения из конечной точки.

Резервный маршрут

Резервный маршрут позволяет отправить все сообщения, которые не соответствуют условиям запроса на любом из имеющихся маршрутов, ко встроенным Центрам событий (/messages/events), совместимым со службой Центры событий. Если маршрутизация сообщений включена, вы можете включить возможность резервного маршрута. После создания маршрута данные перестают поступать на встроенную конечную точку, если маршрут создан не к этой конечной точке. Если маршруты ко встроенной конечной точке отсутствуют и резервный маршрут включен, на встроенную конечную точку будут отправляться только те сообщения, которые не соответствуют каким-либо условиям запроса для маршрутов. Кроме того, если удалить имеющиеся маршруты, необходимо включить резервный маршрут, чтобы все данные поступали на встроенную конечную точку.

На портале Azure –>колонка "Маршрутизация сообщений" можно включить и отключить резервный маршрут. Вы также можете использовать Azure Resource Manager, чтобы свойства FallbackRouteProperties использовали пользовательскую конечную точку для резервного маршрута.

События без использования телеметрии

Помимо данных телеметрии, функция маршрутизации сообщений позволяет также отправлять события изменения двойников устройств, события жизненного цикла устройств, события изменения цифровых двойников и события состояния подключения устройств. Например, при создании маршрута с источником данных со значением события изменения двойников устройства Центр Интернета вещей отправляет сообщения на конечную точку, содержащую изменения двойника устройства. Аналогично, если маршрут создается с помощью источника данных со значением события жизненного цикла устройства, Центр Интернета вещей отправляет сообщения, указывающие, было ли удалено или создано устройство или модуль. Дополнительные сведения о событиях жизненного цикла устройств см. в разделе Уведомления о жизненном цикле устройств и модулей. При использовании Azure IoT Plug and Play разработчик может создавать маршруты с источником данных в значении события изменения цифрового двойника, а Центр Интернета вещей Azure отправляет сообщения при установке или изменении свойства цифрового двойника, замене цифрового двойника или изменении соответствующего двойника устройства. Наконец, если создать маршрут с источником данных в значении события состояния подключения устройства, Центр Интернета вещей будет отправлять сообщения о подключении или отключении устройства.

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

Ограничения для событий состояния подключения устройства

События состояния подключения устройства доступны для устройств, подключающихся с помощью протокола MQTT или AMQP или с помощью любого из этих протоколов через WebSockets. Запросы, созданные только с помощью протокола HTTPS, не будут активировать уведомления о состоянии подключения устройств. Чтобы Центр Интернета вещей начал отправку событий состояния подключения устройств, после открытия подключения устройство должно вызвать операцию приема сообщений из облака на устройство или операцию отправки данных телеметрии с устройства в облако. За пределами пакетов SDK для Интернета вещей Azure при использовании MQTT эти операции эквивалентны операциям SUBSCRIBE или PUBLISH в соответствующих разделах сообщений. При использовании AMQP эти операции эквивалентны операциям подключения или передачи сообщения по соответствующим путям ссылок.

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

Тестирование маршрутов

При создании маршрута или изменении имеющегося маршрута необходимо проверить запрос маршрута, отправив пример сообщения. Вы можете протестировать отдельные маршруты или проверить все маршруты за один раз и не отправлять сообщения на конечные точки во время теста. Тестирование можно выполнить с помощью портала Microsoft Azure, Azure Resource Manager, Azure PowerShell и Azure CLI. Исходные данные позволяют определить такие события: пример сообщения совпал с запросом, сообщение не совпало с запросом или не удалось провести тестирование из-за неверного синтаксиса запроса или примера сообщения. Дополнительные сведения см. в статьях о проверке маршрута и проверке всех маршрутов.

Задержка

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

В большинстве случаев среднее увеличение задержки не превышает 500 мс. Однако задержка может варьироваться и повышаться в зависимости от уровня центра Интернета вещей и архитектуры решения. Вы можете отслеживать задержки с помощью метрики Центра Интернета вещей Routing: message latency for messages/events (Маршрутизация: задержка сообщений для messages/events) или d2c.endpoints.latency.builtIn.events. Последующее создание или удаление любого маршрута не влияет на общую задержку.

Мониторинг и устранение неполадок

Центр Интернета вещей предоставляет несколько метрик, связанных с маршрутизацией и конечными точками, для получения представления о состоянии работоспособности центра и отправленных сообщений. Список всех метрик Центра Интернета вещей Azure, распределенных по функциональным категориям, см. в статье Метрики в Справочнике по данным мониторинга. Вы можете отслеживать ошибки, возникающие при оценке запроса маршрутизации и работоспособности конечной точки, воспринимаемых Центром Интернета вещей, с помощью категории маршруты в журналах ресурсов Центра Интернета вещей Azure. Дополнительные сведения об использовании метрик и журналов ресурсов в Центре Интернета вещей Azure см. в статье Мониторинг Центра Интернета вещей Azure.

Чтобы узнать состояние работоспособности конечных точек, можно использовать REST API Получить сведения о работоспособности конечной точки.

Используйте руководство по устранению неполадок маршрутизации для получения дополнительных сведений и поддержки по устранению неполадок маршрутизации.

Дальнейшие действия