В этой статье рассматривается стратегия единиц масштабирования для поддержки масштабирования количества подключенных устройств в решении Интернета вещей (IOT). В этой статье также подробно описано, как развертывать устройства и приложения Интернета вещей между единицами масштабирования.
Стратегия единиц масштабирования для решений Интернета вещей основана на конструктивном шаблоне Единица масштабирования. Единицы масштабирования — это единицы, состоящие из разнородных компонентов, поддерживающих определенный парк устройств. Использование единиц масштабирования увеличивает количество подключенных устройств Интернета вещей путем репликации единиц масштабирования, а не независимого масштабирования отдельных частей решения.
Преимущества группирования развертываний по единицам масштабирования:
- Размещение и распределение устройств по таким критериям, как географическая зависимость, жизненный цикл или состояние выпуска.
- Уменьшение влияния сбоев или замедления производительности служб на определенные единицы масштабирования.
- Развертывание новых функций, возможностей и архитектурных изменений в определенные единицы масштабирования, которые могут их поддерживать.
- Поддержка управления устройствами нескольких поколений путем согласования возможностей и служб с указанными парками устройств.
- Предоставление модели масштабирования и затрат на основе единиц масштабирования для прогнозирования будущего роста.
Архитектура единиц масштабирования IoT
Скачайте файл Visio этой архитектуры.
На предыдущей схеме показана стратегия единиц масштабирования для Azure IoT. Это решение создает атомарные единицы масштабирования, каждая из которых состоит из:
- Центра интернета вещей Azure;
- конечных точек маршрутизации, таких как Центры событий Azure;
- компонентов обработки.
Единицы масштабирования всегда нужно проектировать с поддержкой явно заданной емкости. Чтобы определить правильное количество устройств, которые нужно поддерживать, определите ожидаемый объем трафика с устройств. В этом решении каждая единица масштабирования оптимально поддерживает определенный парк устройств от 1000 до 1 000 000 устройств. По мере роста парка устройств их работу обеспечивают дополнительные экземпляры единиц масштабирования.
Перемещение устройств и приложений между единицами масштабирования
Единицы масштабирования предназначены для атомарного развертывания, но иногда нужно переместить парки устройств между единицами масштабирования. Например, вам может понадобиться:
- Перемещение парков устройств из тестовых единиц масштабирования в рабочие единицы масштабирования в рамках цикла выпуска.
- Перемещение устройств и пользователей в другую единицу масштабирования в рамках устранения простоя в стратегии высокой доступности.
- Балансировка нагрузки для более равномерного распределения парка устройств между единицами масштабирования.
Перемещение устройств между центрами
Если компоненты единицы масштабирования определяются поведением передачи данных с устройства в облако, перемещение устройств между центрами аналогично миграции устройств из одной единицы масштабирования в другую. Служба подготовки устройств к добавлению в Центр Интернета вещей (DPS) предоставляет возможность перемещать устройства между экземплярами Центра Интернета вещей. Чтобы использовать службу DPS в стратегии группирования по единицам масштабирования, изучите понятия и терминологию службы подготовки к добавлению в Центр Интернета вещей.
Примечание
Служба DPS использует идентификаторы регистрации, а Центр Интернета вещей — идентификаторы устройств. Такие идентификаторы часто имеют одно значение, но могут отличаться. При запросам к устройствам или управлении ими с помощью API DPS обязательно используйте идентификаторы регистрации.
Перемещение устройств и приложений между автономными единицами масштабирования
Если единицы масштабирования развертываний включают веб-интерфейсные части или приложения API, которые обмениваются данными с Центром Интернета вещей, такие компоненты также нужно перенести в новые центры для последующего обмена данными с перенесенными устройствами. Вы можете перемещать все приложения и устройства между единицами масштабирования.
Если каждая единица масштабирования включает комплексное приложение, Диспетчер трафика Azure может перемещать трафик из одной единицы масштабирования в другую. Эта стратегия подразумевает создание нескольких единиц масштабирования, каждая из которых содержит все приложение с собственным URL-адресом. Все парки устройств и пользователи приложений переходят из одной единицы масштабирования в другую.
Такая полностью автономная стратегия:
- Простая реализация.
- Оптимальна при использовании в рамках стратегии высокого уровня доступности.
- Полезна для переноса устройств и пользователей между средами тестирования и рабочими средами.
Скачайте файл Visio этой архитектуры.
На схеме выше приведен процесс перемещения набора устройств из единицы масштабирования 1 в единицу масштабирования 2:
- Устройства получают конечную точку Центра Интернета вещей через DPS, если она не известна или недопустима.
- При перемещении устройств в единицу масштабирования 2 диспетчер трафика настраивает URL-адрес приложения для перехода на экземпляр приложения 2.
- Служба подготовки устройств к добавлению в Центр Интернета вещей перемещает весь набор устройств из одной единицы масштабирования в другую.
- Каждая единица масштабирования приложения включает интерфейсную часть приложения и ссылается на соответствующий Центр Интернета вещей для такой единицы масштабирования.
Перемещение устройств между единицами масштабирования за одним шлюзом приложений
Если одна клиентская часть приложения поддерживает несколько единиц масштабирования устройств, клиентская часть приложения должна динамически обновлять свое сопоставление устройства и концентратора, чтобы обеспечить взаимодействие между облаком и устройством. Для поддержки устройств, которые перемещаются в другие единицы масштабирования и Центры Интернета вещей, шлюзы могут использовать механизм кэширования с сопоставлением устройств центру. Клиенты службы могут использовать общую подпрограмму поиска для динамического обнаружения и переноса вызовов устройств в новые центры Интернета вещей.
Скачайте файл Visio этой архитектуры.
В этой модели шлюз использует кэш для сопоставления устройств с центрами Интернета вещей и по умолчанию использует кэшированную конечную точку. Если шлюз получает сообщение об ошибке "Устройство не найдено", он использует пакет SDK службы DPS для запроса регистрации отдельных устройств и определения центра Интернета вещей, который теперь используется устройством. Затем шлюз обновляет кэш с использованием нового сопоставления.
Ниже приведены некоторые рекомендации относительно этой стратегии.
Хотя кэширование при общем поиске позволяет избежать повторного согласования конечных точек при каждом вызове, конечная точка кэша может завершить работу со сбоем. Вторичный кэш или резервный план повторного согласования с DPS может улучшить надежность решения.
При выполнении регистрации устройства оно будет недоступно. Используйте API DPS, например для получения состояния регистрации устройства, чтобы получить сведения о Центре Интернета вещей, которому назначено устройство, и текущем состоянии регистрации.
В случае использования "только устройства", устройства отключаются от Центра Интернета вещей при переходе с одной единицы масштабирования на другую. В сценариях "из приложения на устройство" ошибка возникает в результате попытки обратиться к устройству через Центр Интернета вещей.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими авторами.
Основной автор:
- Джейсон Уодсворт | Главный инженер по программному обеспечению
Дальнейшие действия
- Устройства, платформа и приложения Интернета вещей
- Команды для передачи данных из приложения на устройство Интернета вещей
- Шаблон проектирования единица масштабирования развертываний