Используйте маршрутизацию сообщений IoT Hub для отправки сообщений от устройства в облако в службы Azure.

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

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

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

Центр Интернета вещей задает общий формат для всех случаев обмена сообщениями с устройства в облако для взаимодействия по различным протоколам. Дополнительные сведения см. в статье Создание и чтение сообщений Центра Интернета вещей.

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

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

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

• Встроенная конечная точка
• Контейнеры для хранения
• Очереди шины служб
• Темы Service Bus
• Event Hubs
• Cosmos DB

Дополнительные сведения о каждой из этих конечных точек см. в разделе точки взаимодействия IoT Hub.

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

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

Сведения о создании конечных точек см. в статье "Управление маршрутами и конечными точками" с помощью портала Azure.

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

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

Маршрут к конечной точке в другой подписке

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

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

Запросы маршрутизации

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

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

Для получения дополнительной информации см. раздел Синтаксис запросов маршрутизации сообщений для IoT Hub.

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

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

• Чтение из встроенного конечного узла

• Чтение из облачного хранилища Blob

• Чтение из Event Hubs

• Чтение из очередей Service Bus

• Чтение из разделов служебная шина

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

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

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

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

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

• События изменения цифровых двойников устройств
• События жизненного цикла устройства
• События жизненного цикла операций с устройством
• События изменений цифрового двойника
• События, связанные с состоянием подключения устройства

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

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

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

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

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

• Связь с Центром Интернета вещей с помощью MQTT
• Взаимодействие с Концентратором IoT с помощью AMQP

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

Тестовые маршруты

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

Задержка

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

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

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

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

Для получения состояния работоспособности конечных точек можно использовать REST API Get Endpoint Health .

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