Рекомендации по крупномасштабным развертываниям IoT (Интернета вещей)

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

Подготовка новых устройств

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

Использование поэтапного графика поставок

Для развертывания устройств в масштабе миллионов, регистрация всех устройств одновременно может привести к перегрузке инстанса DPS из-за ограничения скорости (код ответа HTTP 429, Too Many Requests) и сбоя регистрации ваших устройств. Чтобы предотвратить такое регулирование, используйте ступенчатое расписание регистрации для устройств. Настройте размеры пакетов регистрации устройств в соответствии с квотами и ограничениями DPS. Например, если скорость регистрации составляет 200 устройств в минуту, размер пакета для подключения будет составлять 200 устройств на пакет.

Повторные операции

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

Вместо того чтобы немедленно повторять развертывание при ограничении, подождите, пока не наступит время, указанное в заголовке retry-after. Если в службе нет заголовка повторных попыток, этот алгоритм может помочь добиться более плавного подключения устройства:

min_retry_delay_msec = 1000
max_retry_delay_msec = (1.0 / <load>) * <T> * 1000
max_random_jitter_msec = max_retry_delay_msec

С помощью этой логики устройства задерживают повторное подключение в течение случайного периода времени между min_retry_delay_msec и max_retry_delay_msec. Максимальная задержка повторных попыток вычисляется со следующими переменными:

<load> — это настраиваемый фактор со значениями > 0, что указывает, что нагрузка выполняется в среднем по времени загрузки, умноженной на число подключений в секунду.
<T> является абсолютным минимальным временем для холодной загрузки устройств (вычисляется как T = N / cpsN общее число устройств и cps является ограничением службы для количества подключений в секунду).

Дополнительные сведения о времени выполнения операций повторных попыток см. в разделе "Время повтора".

Повторная подготовка устройств

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

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

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

Устройства, которые могут хранить строку подключения

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

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

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

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

Устройства, которые не могут хранить строку подключения

Некоторые устройства не имеют достаточно места или объема памяти для кэширования строки подключения из предыдущего успешного подключения к IoT-хабу. Эти устройства должны переподключаться через DPS после перезагрузки. Используйте API для регистрации DPS для повторной регистрации. Помните, что количество повторных регистраций в минуту ограничено на основе ограничения регистрации устройств DPS.

Пример повторной подготовки

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

using Newtonsoft.Json;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;

namespace ProvisioningCache
{
  public class ProvisioningDetailsFileStorage : IProvisioningDetailCache
  {
    private string dataDirectory = null;

    public ProvisioningDetailsFileStorage()
    {
      dataDirectory = Environment.GetEnvironmentVariable("ProvisioningDetailsDataDirectory");
    }

    public ProvisioningResponse GetProvisioningDetailResponseFromCache(string registrationId)
    {
      try
        {
          var provisioningResponseFile = File.ReadAllText(Path.Combine(dataDirectory, registrationId));

          ProvisioningResponse response = JsonConvert.DeserializeObject<ProvisioningResponse>(provisioningResponseFile);

          return response;
        }
      catch (Exception ex)
      {
        return null;
      }
    }

    public void SetProvisioningDetailResponse(string registrationId, ProvisioningResponse provisioningDetails)
    {
      var provisioningDetailsJson = JsonConvert.SerializeObject(provisioningDetails);

      File.WriteAllText(Path.Combine(dataDirectory, registrationId), provisioningDetailsJson);
    }
  }
}

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

IProvisioningDetailCache provisioningDetailCache = new ProvisioningDetailsFileStorage();

var provisioningDetails = provisioningDetailCache.GetProvisioningDetailResponseFromCache(registrationId);

// If no info is available in cache, go through DPS for provisioning
if(provisioningDetails == null)
{
  logger.LogInformation($"Initializing the device provisioning client...");
  using var transport = new ProvisioningTransportHandlerAmqp();
  ProvisioningDeviceClient provClient = ProvisioningDeviceClient.Create(dpsEndpoint, dpsScopeId, security, transport);
  logger.LogInformation($"Initialized for registration Id {security.GetRegistrationID()}.");
  logger.LogInformation("Registering with the device provisioning service... ");

  // This method will attempt to retry in case of a transient fault
  DeviceRegistrationResult result = await registerDevice(provClient);
  provisioningDetails = new ProvisioningResponse() { iotHubHostName = result.AssignedHub, deviceId = result.DeviceId };
  provisioningDetailCache.SetProvisioningDetailResponse(registrationId, provisioningDetails);
}

// If there was IoT Hub info from previous provisioning in the cache, try connecting to the IoT hub directly
// If trying to connect to the IoT hub returns status 429, make sure to retry operation honoring
//   the retry-after header
// If trying to connect to the IoT hub returns a 500-series server error, have an exponential backoff with
//   at least 5 seconds of wait-time
// For all response codes 429 and 5xx, reprovision through DPS
// Ideally, you should also support a method to manually trigger provisioning on demand
if (provisioningDetails != null)
{
  logger.LogInformation($"Device {provisioningDetails.deviceId} registered to {provisioningDetails.iotHubHostName}.");
  logger.LogInformation("Creating TPM authentication for IoT Hub...");
  IAuthenticationMethod auth = new DeviceAuthenticationWithTpm(provisioningDetails.deviceId, security);
  logger.LogInformation($"Testing the provisioned device with IoT Hub...");
  DeviceClient iotClient = DeviceClient.Create(provisioningDetails.iotHubHostName, auth, TransportType.Amqp);
  logger.LogInformation($"Registering the Method Call back for Reprovisioning...");
  await iotClient.SetMethodHandlerAsync("Reprovision",reprovisionDirectMethodCallback, iotClient);

  // Now you should start a thread into this method and do your business while the DeviceClient is still connected
  await startBackgroundWork(iotClient);
  logger.LogInformation("Wait until closed...");

  // Wait until the app unloads or is cancelled
  var cts = new CancellationTokenSource();
  AssemblyLoadContext.Default.Unloading += (ctx) => cts.Cancel();
  Console.CancelKeyPress += (sender, cpe) => cts.Cancel();

  await WhenCancelled(cts.Token);
  await iotClient.CloseAsync();
  Console.WriteLine("Finished.");
}

Вопросы подключения IoT Hub

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

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

При получении любого ответа сервера с ошибкой из серии 500 повторите подключение, используя кэшированные учетные данные или результаты запроса состояния регистрации устройства через API.
При получении 401, Unauthorized, 403, Forbidden или 404, Not Found, выполните полную повторную регистрацию, путем вызова API регистрации DPS.

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

Если устройства отключены от Центра Интернета вещей, устройства должны попытаться повторно подключиться непосредственно к тому же центру Интернета вещей в течение 15–30 минут, прежде чем пытаться вернуться к DPS.

Другие сценарии IoT Hub с использованием DPS:

Центр Интернета вещей: при восстановлении после сбоя устройства должны продолжать работать, так как сведения о подключении не должны изменяться, а логика повторной попытки подключиться будет задействована, как только концентратор станет доступен снова.
Изменение Центра Интернета вещей. Назначение устройств другому Центру Интернета вещей должно выполняться с помощью настраиваемой политики выделения.
Повторите попытку подключения к IoT-хабу: не следует использовать агрессивную стратегию повторного подключения. Вместо этого позвольте пройти как минимум минуте прежде чем повторить попытку.
Разделы IoT Hub: Если ваша стратегия устройств сильно зависит от телеметрии, необходимо увеличить число разделов от устройства к облаку.

Мониторные устройства

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

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

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

Использование политик выделения для подготовки устройств в центрах Интернета вещей
Время повтора при повторных операциях

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-08-07