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

Статья
04/07/2024

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

Что приводит к отключению

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

Истек срок действия маркера SAS или сертификата X.509. Истек срок действия маркера SAS устройства или сертификата проверки подлинности X.509.
Прерывание сети. Подключение устройства к сети прерывается.
Сбои в работе службы. Служба Центр Интернета вещей Azure испытывает ошибки или временно недоступна.
Перенастройка службы. После перенастройки Центр Интернета вещей параметров службы устройства могут потребовать повторной подготовки или повторного подключения.

Почему вам нужна стратегия повторного подключения

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

Попытки повторного подключения массы могут вызвать DDoS

Большое количество попыток подключения в секунду может вызвать состояние, аналогичное распределенной атаке типа "отказ в обслуживании" (DDoS). Этот сценарий относится к большим паркам устройств, нумерующих в миллионах. Проблема может выйти за пределы клиента, который владеет флотом, и повлиять на весь масштабируемый модуль. DDoS может привести к увеличению затрат для ресурсов Центр Интернета вещей Azure из-за необходимости горизонтального масштабирования. DDoS также может повредить производительности решения из-за нехватки ресурсов. В худшем случае DDoS может вызвать прерывание работы службы.

Сбой концентратора или перенастройка может отключить множество устройств

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

Повторная подготовка многих устройств может увеличить затраты

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

Проектирование для обеспечения устойчивости

Устройства Интернета вещей часто используют неконтинные или неустойчивые сетевые подключения (например, GSM или спутник). Это означает, что могут возникать ошибки при взаимодействии устройств с облачными службами из-за временных сбоев на уровне доступности службы, инфраструктуры и т. д. Работающее на устройстве приложение должно управлять механизмами подключения, восстановления подключения и повторных попыток при отправке и получении сообщений. Кроме того, требования к стратегии повторных попыток очень сильно меняются в зависимости от сценария, контекста и возможностей устройства Интернета вещей.

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

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

В следующих разделах описаны функции пакета SDK, поддерживающие подключение.

Подключение и повторные попытки

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

Шаблоны ошибок

Сбои подключения могут происходить на разных уровнях:

ошибки сети, например отключенные сокеты и ошибки разрешения имен;
ошибки уровня транспортных протоколов HTTP, AMQP и MQTT, например отключение каналов или истечение срока действия сеансов;
ошибки уровня приложения, которые происходят из-за локальных ошибок, например недопустимых учетных данных или особенностей поведения службы (превышение квоты, регулирование и т. п.).

Пакеты SDK для устройств обнаруживают ошибки на всех трех уровнях. Однако пакеты SDK для устройств не обнаруживают и не обрабатывают ошибки, связанные с ОС, и аппаратные ошибки. Пакеты SDK спроектированы на основе рекомендаций по обработке временных сбоев Центра архитектуры Azure.

Шаблоны повтора

Следующие шаги описывают процесс повторных попыток при обнаружении ошибок подключения.

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

Пакеты SDK обычно предоставляют три политики повторных попыток:

Экспоненциальная задержка с дрожание. Эта политика повтора применяется по умолчанию и действует довольно агрессивно в начале периода с постепенным замедлением вплоть до максимального периода задержки. Она спроектирована на основе рекомендаций по логике повтора из центра архитектуры Azure.
Пользовательская политика повтора. Для некоторых языков пакет SDK позволяет создать пользовательскую политику повтора, которая лучше соответствует конкретному сценарию работы, и поместить ее в объект RetryPolicy. Пользовательская повторная попытка недоступна в пакете SDK для C, и в настоящее время она не поддерживается в пакете SDK для Python. Пакет SDK для Python выполняет повторные подключения по мере необходимости.
Нет повторных попыток: политику повторных попыток можно задать как "без повторных попыток", которая отключает логику повторных попыток. Пакет SDK один раз пытается подключиться и, если подключение установлено, один раз пытается отправить сообщение. Эта политика обычно используется в сценариях, чувствительных к пропускной способности или затратам. Если вы выберете этот вариант, то неотправленные сообщения сразу теряются без возможности восстановления.

Интерфейсы API политики повтора

SDK	Метод SetRetryPolicy	Реализации политики	Методические указания по внедрению
О	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	См. IOTHUB_CLIENT_RETRY_POLICY	Реализация C
Java	SetRetryPolicy	По умолчанию: класс ExponentialBackoffWithJitter. Custom: реализация интерфейса RetryPolicy Без повтора:класс NoRetry.	Реализация для Java
.NET	DeviceClient.SetRetryPolicy	По умолчанию: класс ExponentialBackoff. Пользовательская: реализуйте интерфейс IRetryPolicy. Без повтора:класс NoRetry.	Реализация для C#
Узел	setRetryPolicy	По умолчанию: класс ExponentialBackoffWithJitter. Пользовательская: реализуйте интерфейс RetryPolicy. Без повтора:класс NoRetry.	Реализация для Node
Python	В настоящий момент не поддерживается	В настоящий момент не поддерживается	Встроенные повторные попытки подключения: удаленные подключения по умолчанию извлекаются с фиксированным интервалом в 10 секунд. Эта функция может быть отключена при необходимости, а интервал можно настроить.

Поток повторного подключения концентратора

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

Если устройство не удается подключиться к Центр Интернета вещей или отключено от Центр Интернета вещей:

Используйте экспоненциальный откат с функцией задержки jitter.
Повторно подключитесь к Центр Интернета вещей.

На следующей схеме приводится сводка потока повторного подключения:

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

Концентратор с потоком повторного подключения DPS

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

Если устройство не удается подключиться к Центр Интернета вещей или отключено от Центр Интернета вещей, повторно подключитесь в зависимости от следующих случаев:

Сценарий повторного подключения	Стратегия повторного подключения
Ошибки, разрешающие повторные попытки подключения (код ответа HTTP 500)	Используйте экспоненциальный откат с функцией задержки jitter. Повторно подключитесь к Центр Интернета вещей.
Для ошибок, указывающих, что повторная попытка возможна, но повторное подключение завершилось сбоем 10 раз подряд	Перепроизвести устройство в DPS.
Ошибки, не разрешающие повторные попытки подключения (HTTP-ответы 401, несанкционированные или 403, запрещено или 404, не найдено)	Перепроизвести устройство в DPS.