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

Статья
01/26/2024

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

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

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

Использование ошеломленного расписания подготовки

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые устройства не имеют достаточно большого объема или памяти для кэширования строка подключения из прошлого успешного подключения Центр Интернета вещей. Эти устройства должны повторно подготовиться через 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.");
}

Мониторинг устройств

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

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

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

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