Конечные точки Центра Интернета вещей

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

Имена центров Интернета вещей

Имя узла Центра Интернета вещей можно найти на портале Azure на панели обзора Центра Интернета вещей. По умолчанию DNS-имя центра Интернета вещей выглядит следующим образом:

{your iot hub name}.azure-devices.net

Центр Интернета Вещей: конечные точки для разработки и управления

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

В следующем списке описываются конечные точки.

• Поставщик ресурсов: интерфейс Azure Resource Manager . С помощью этого интерфейса владельцы подписки Azure могут создавать и удалять Центры Интернета вещей, а также обновлять их свойства. Свойства центра Интернета вещей управляют политиками общего доступа на уровне концентратора, а не контролем доступа на уровне устройства, а также функциональными параметрами для обмена сообщениями от облака к устройствам и от устройств к облаку. Поставщик ресурсов для Центра Интернета вещей также позволяет экспортировать удостоверения устройств.

• Управление удостоверениями устройств: набор конечных точек REST HTTPS для управления удостоверениями устройств (создание, извлечение, обновление и удаление). Удостоверения устройств нужны для аутентификации устройств и контроля доступа к ним.

• Управление двойниками устройств: набор конечных точек HTTPS REST, ориентированных на сервис, для запроса и обновления двойников устройств (обновление тегов и свойств).

• Управление заданиями: набор конечных точек REST для обслуживания HTTPS-запросов для управления и обработки заданий.

• Конечные точки устройства: набор конечных точек для каждого устройства в реестре удостоверений. Если не указано иное, эти конечные точки предоставляются по протоколам MQTT v3.1.1, HTTPS 1.1 и AMQP 1.0. Протоколы AMQP и MQTT также доступны в WebSockets через порт 443. К этим конечным точкам устройства относятся:

  • Отправка сообщений устройства в облако

  • Получение сообщений из облака на устройство

  • Запуск отправки файлов

  • Получение и обновление свойств двойника устройства (HTTPS не поддерживается)

  • Получение запросов метода прямого доступа (HTTPS не поддерживается)

• Конечные точки службы: набор конечных точек для серверной части вашего решения, чтобы взаимодействовать с вашими устройствами. За одним исключением эти конечные точки предоставляются только через протоколы AMQP и AMQP в WebSockets. Конечная точка для вызова прямого метода предоставляется по протоколу HTTPS.

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

  • Отправка сообщений из облака на устройство и подтверждение доставки

  • Получение уведомлений о отправке файлов

  • Вызов прямого метода

В статье пакеты SDK для Azure IoT Hub описываются различные способы доступа к этим конечным точкам.

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

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

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

Центр Интернета вещей поддерживает следующие службы Azure в качестве пользовательских конечных точек:

• Контейнеры для хранения
• Центры событий
• Очереди шины Service Bus
• Разделы служебной шины
• Cosmos DB

Ограничения конечных точек на концентратор см. в разделе "Квоты и регулирование".

Встроенная конечная точка

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

Полезная нагрузка сообщения не закодирована в Base64 на встроенной конечной точке.

Хранилище Azure в качестве конечной точки маршрутизации

Центр Интернета вещей может направлять сообщения в две службы хранилища: хранилище BLOB-объектов Azure и учетные записи Azure Data Lake Storage 2-го поколения (ADLS 2-го поколения). Обе эти службы используют blob для их хранилища. Чтобы использовать Azure Data Lake 2-го поколения, учетная запись хранения должна иметь иерархические пространства имен. Дополнительные сведения см. в статье "Создание учетной записи хранения для использования с Azure Data Lake Storage".

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

Если вы не задаете необходимые системные свойства, Центр Интернета вещей применяет кодировку Base64. Чтобы избежать кодировки Base64, установите оба свойства: contentType как application/json и contentEncoding как UTF-8 в системных свойствах сообщения. Если эти свойства не заданы, Центр Интернета вещей записывает сообщения в кодировке Base64.

Формат кодирования можно задать только при настройке конечной точки хранилища блобов. Невозможно изменить формат кодирования для существующей конечной точки.

Центр Интернета вещей пакетирует сообщения и записывает данные в хранилище всякий раз, когда пакет достигает определенного размера или определенного периода времени. Центр Интернета вещей по умолчанию используется следующее соглашение об именовании файлов: {iothub}/{partition}/{YYYY}/{MM}/{DD}/{HH}/{mm}

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

Чтобы убедиться, что все объекты BLOB или файлы считываются без каких-либо предположений о разделе, перечислите объекты BLOB или файлы, а затем произведите их итерацию. Диапазон разделов может измениться в случае отработки отказа, инициированной корпорацией Microsoft, или ручной отработки отказа с помощью IoT Hub. Вы можете использовать API перечисления BLOB-объектов или API перечисления ADLS 2-го поколения для составления списка файлов. Например:

public void ListBlobsInContainer(string containerName, string iothub)
{
    var storageAccount = CloudStorageAccount(Microsoft.Azure.Storage.Auth.StorageCredentials storageCredentials, bool useHttps);
    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.

Кодировка Base64 никогда не применяется при маршрутизации в очереди или топики Service Bus. Сообщения записываются без изменений в конечную точку.

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

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

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

Azure Cosmos DB в качестве конечной точки маршрутизации

Данные можно отправлять непосредственно в Azure Cosmos DB из IoT Hub. Центр Интернета вещей поддерживает запись в Cosmos DB в ФОРМАТЕ JSON (если указан в типе содержимого сообщения) или в виде двоичного файла в кодировке Base64.

Кодировка Base64 применяется, если необходимые системные свойства не заданы. Для записи в формате JSON установите свойство contentType как application/json и свойство contentEncoding как UTF-8 в свойствах системы сообщений. Если эти свойства не заданы, данные кодируются в кодировке Base64 при записи в Cosmos DB.

Для поддержки высокомасштабируемых сценариев можно включить синтетические ключи секций для конечной точки Cosmos DB. Так как Cosmos DB — это хранилище данных гипермасштабирования, все данные и документы, записанные в него, должны содержать поле, представляющее логическую секцию. Каждая логическая секция имеет максимальный размер 20 ГБ. Имя свойства ключа раздела можно указать в имени ключа раздела. Имя свойства ключа партиции определяется на уровне хранилища и не может быть обновлено.

Можно настроить значение искусственного ключа секции, указав шаблон в шаблоне ключа секции на основе предполагаемого тома данных. Например, в производственных сценариях логический раздел может подойти к максимальному ограничению в 20 ГБ в течение месяца. В этом случае можно определить искусственный ключ секции как сочетание идентификатора устройства и месяца. Созданное значение ключа секции автоматически добавляется в свойство ключа секции для каждой новой записи Cosmos DB, обеспечивая создание логических секций каждый месяц для каждого устройства.

Здоровье конечной точки

Чтобы узнать состояние работоспособности конечных точек, можно использовать REST API Получить сведения о работоспособности конечной точки. Рекомендуется использовать метрики маршрутизации центра Интернета вещей, связанные с задержкой сообщений маршрутизации, для определения и отладки ошибок, когда конечная точка неисправна или неработоспособна, поскольку предполагается, что задержка увеличивается, если конечная точка находится в одном из этих состояний. Дополнительные сведения об использовании метрик центра Интернета вещей см. в статье Мониторинг центра Интернета вещей.

Следующие шаги

Дополнительные сведения об этих разделах:

• Язык запросов IoT Hub для твинов устройств и модулей, заданий и маршрутизации сообщений
• Квоты и ограничение в IoT-хабе
• Взаимодействие с Центром Интернета вещей с помощью протокола MQTT
• IP-адреса IoT-хаба