Интернет вещей полон проблем, связанных с управлением разнородным оборудованием, а также обработкой и хранением больших массивов данных. Компании могут решить многие проблемы, построив IoT в масштабируемой и гибкой облачной архитектуре. Основные поставщики облачных услуг - AWS, Microsoft Azure и GCP - предоставляют высокопроизводительные возможности для таких облачных архитектур.
Подход Cloud Native
Облачный подход включает создание и управление приложениями, которые используют преимущества модели предоставления облачных вычислений.
Итак, вопрос в том, как создавать и развертывать приложения, а не где. Таким образом, эти приложения могут быть доставлены как в публичное, так и в частное облако.
Облачный подход, определенный в CNCF, характеризуется архитектурами микросервисов, контейнерной технологией, непрерывными поставками, конвейерами разработки и инфраструктурой, выраженной в коде (Infrastructure as a Code), что является важной практикой культуры DevOps.
Критические аспекты архитектуры Интернета вещей
Инфраструктура Интернета вещей состоит из трех основных компонентов:
- Парк фиксированных или мобильных подключенных объектов, распределенных географически
- Сеть, позволяющая соединять объекты посредством передачи сообщений; он может быть проводным или коротким беспроводным (Wi-Fi, Bluetooth и т. д.) или дальним, мобильным (2G, 3G, 4G, 5G и т. д.)
- Приложение, чаще всего разрабатываемое с помощью веб-технологий, которое собирает данные из сети объектов для предоставления агрегированной и повторно обработанной информации.
Система приема. Система приема данных лежит в основе архитектуры, поскольку она в основном отвечает за получение данных от активов (датчиков, автомобилей и других устройств Интернета вещей), проверку данных и их последующее сохранение в указанная база данных. Система приема получает данные по протоколу MQTT.
MQ Telemetry Transport - это легкий протокол, простой и способный работать в сетях с ограниченной пропускной способностью и высокой задержкой.
Отчетность: этот компонент в основном отвечает за отображение / создание информации об объектах и отправку предупреждений о них.
Лучше всего разделить отчетность на три службы: агрегирование временных рядов в автономном режиме, потоковая передача временных рядов в режиме онлайн и служба правил (системные триггеры).
Сервис агрегирования временных рядов в автономном режиме запрашивает данные активов.
Онлайн-мониторинг потоковых временных рядов в реальном времени за действиями данного актива. Служба правил будет предупреждать владельца актива всякий раз, когда правило запускается по SMS или электронной почте.
Встроенная система. Роль встроенной системы заключается в передаче данных с устройств Интернета вещей в пограничную службу / службу приема данных. Каждое устройство IoT может отправлять JSON с активами (id, token, tenantId) в пограничную службу / службу приема. Устройства передают документ JSON в пограничную службу / службу приема с информацией об активах (идентификатор, токен, tenantId) из встроенной системы.
Создание облачной архитектуры, готовой к Интернету вещей
Функция шлюза: функция шлюза - это шлюз для обмена сообщениями между приложением и парком объектов. Первая цель - аутентифицировать и авторизовать объекты для связи с приложением. Вторая цель - зашифровать сообщения, проходящие по сети, чтобы предотвратить их перехват.
Обработка сообщений: после прохождения шлюза необходимо будет получать, обрабатывать и интегрировать сообщения. Здесь вопрос масштабируемости имеет решающее значение для бесшовных облачных вычислений IoT. Эта функция должна уметь обрабатывать очень непостоянный объем сообщений. Успех первоначального развертывания может привести к быстрому расширению.
Управление парком: эта внутренняя функция, а не приложение для представления данных, должна развиваться в собственном темпе и независимо от остальной части приложения. Таким образом, хорошо, что он разработан как отдельный модуль, который можно обновлять без повторного развертывания всего приложения.
База данных. Группа подключенных объектов будет снабжать приложение растущим потоком данных, которые необходимо будет хранить, индексировать и анализировать.
В этом блоке должны быть реляционные базы данных и быстрые базы данных типов ключ-значение, инструменты индексирования или поиска и т. Д. Безопасность и целостность данных имеют решающее значение. Возможность совместного использования баз данных между несколькими интерфейсными серверами имеет важное значение для обеспечения доступности и масштабируемости приложения.
Поэтому с точки зрения дизайна важна многоуровневая архитектура с изолированным сервером базы данных. В частности, у нас может быть архитектура, которая позволяет иметь очень короткую RPO (цель точки восстановления) в случае инцидента.
Виртуализация данных. Целью приложения IOT является обработка и представление данных пользователям, которые будут подключаться к нему, в основном через веб-доступ. Объем подключений к серверу приложений будет зависеть от его аудитории: ограниченный для профессионального приложения целевой аудиторией, он может стать значительным для широкой аудитории. В последнем случае может потребоваться система автоматического масштабирования, чтобы добавить один или несколько серверов в случае пиков нагрузки и гарантировать время отклика.
Устройства Интернета вещей могут работать без больших ресурсов при подключении к облаку. Затраты могут быть снижены, что делает Интернет вещей удобным для использования в бизнесе. При правильной архитектуре потенциальная ценность вашего внедрения Интернета вещей для бизнеса неоценима.
Автор - Кирилл Морозов, технический директор и главный архитектор @ Cloudride
Первоначально опубликовано на https://www.cloudride.co.il.