Поделиться через


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

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

Примечание.

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

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

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

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

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

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

Схема, показывающая список встроенных конечных точек IoT Hub.

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

  • Поставщик ресурсов: интерфейс 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, и ни одна конечная точка никогда не предоставляется по незашифрованным или незащищенным каналам.

Внимание

Следующие функции для устройств, использующих проверку подлинности центра сертификации X.509 (ЦС), пока недоступны, и режим предварительной версии должен быть включен:

  • протоколы HTTPS, MQTT через WebSockets и AMQP через WebSockets;
  • передача файлов (по всем протоколам).

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

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

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

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

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

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

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

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

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

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

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

Формат кодирования можно задать только в том случае, если конечная точка хранилища BLOB-объектов настроена; Его нельзя изменить для существующей конечной точки.

Центр Интернета вещей пакетирует сообщения и записывает данные в хранилище всякий раз, когда пакет достигает определенного размера или определенного периода времени. Центр Интернета вещей по умолчанию используется следующее соглашение об именовании файлов: {iothub}/{partition}/{YYYY}/{MM}/{DD}/{HH}/{mm} Вы можете использовать любое соглашение об именовании файлов, но необходимо использовать все перечисленные маркеры. IoT Hub записывает в пустой 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 конечная точка будет отображаться как недоступная.

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

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

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

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

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

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

Внимание

Если вы используете управляемое удостоверение, назначаемое системой для проверки подлинности в Cosmos DB, необходимо использовать Azure CLI или Azure PowerShell, чтобы назначить управляемому удостоверению встроенную роль Участника данных Cosmos DB. Назначение ролей для Cosmos DB в настоящее время не поддерживается в портале Azure. Дополнительные сведения о различных ролях см. в статье "Настройка доступа на основе ролей для Azure Cosmos DB". Сведения о назначении ролей с помощью интерфейса командной строки см. в статье "Управление ресурсами роли SQL Azure Cosmos DB".

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

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

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

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

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