ОПИСАНИЕ ПЛАТФОРМЫ НА ОСНОВЕ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ ДЛЯ УПРАВЛЕНИЯ ЦЕПОЧКОЙ ПОСТАВОК СРЕДСТВАМИ IOT, СЕМАНТИЧЕСКИХ И AI-СЕРВИСОВ

Тип работы: Реферат
Бесплатно: Антиплагиат
Объем: 12 страниц
В избранное:

Тусупбеков А. О. (магистрант Карагандинского Технического Университета),

Смагулова А. С. (канд. техн. наук, преподаватель Карагандинского Технического Университета)

Карагандинский Технический Университет, г. Караганда, Казахстан

e-mail: atusupbekov98@gmail. com, asemgul_sss@mail. ru

ОПИСАНИЕ ПЛАТФОРМЫ НА ОСНОВЕ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ ДЛЯ УПРАВЛЕНИЯ ЦЕПОЧКОЙ ПОСТАВОК СРЕДСТВАМИ IOT, СЕМАНТИЧЕСКИХ И AI-СЕРВИСОВ.

Аннотация

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

Ключевые слова: Интернет вещей, микросервисная архитектура, виртуализация, сервисы, Node-RED, Docker.

Abstract

Through the use of technologies such as the Internet of Things and the cloud, spanning the entire spectrum of manufacturing and distribution, typical supply chain management systems rely on a variety of services to support. This article aims to present an integrated system architecture and implement microservices that consume and semantically annotate data streams from online systems while performing post-processing tasks such as supply chain monitoring, product location analysis, and anticipated delays. Provides a modern solution for deploying servers and applications on a remote host machine. The influence of the Internet of Things on the functioning and development of modern markets and organizations, changes in the professional structure of modern society is considered. It also provides an analysis of the latency of image deployment in container virtualization, which can run various programs written in different programming languages and different technologies.

Keywords : Internet of Things, microservice architecture, virtualization, services, Node-RED, Docker.

Введение

С появлением Интернета вещей (IoT) появляются новые возможности в отношении мониторинга, управления и оптимизации распределения товаров и цепочек поставок в реальном времени. Gartner включает искусственный интеллект (AI), IoT и прогнозную / предписывающую аналитику в число наиболее важных тенденций в области технологий цепочки поставок информации [1] . Новые возможности включают облачные сервисы, программное обеспечение как систему управления продуктами, которые могут обеспечивать мониторинг вещей (экземпляров этих продуктов) с помощью интеллектуальных датчиков, встроенных в продукты, которые можно сканировать и предоставлять такую информацию, как температура, влажность и местоположение [2], позволяя определять условные правила для оповещения заинтересованных сторон. Комбинации технологий, включая интеллектуальное зондирование, связь и централизованный облачный анализ, были разработаны для решения проблем, связанных с распределением, а также для мониторинга состояния чувствительных товаров в промышленных и сельскохозяйственных случаях [3] . Ориентация на данные также является ключевой особенностью. Благодаря этим решениям компании могут уменьшить недостаток информации о том, что происходит в их сложных цепочках поставок, и, таким образом, оптимизировать оценку рисков и стратегию устойчивого управления цепочками поставок [4] .

Однако с практической точки зрения эти комбинации очень сложны из-за разнообразия задействованных ИТ-систем и технической невозможности слияния и обоснования предоставленных данных семантически значимым образом. Хотя глобализация способствовала усилению конкуренции между поставщиками и должна обеспечить лучшие условия поставок для компаний, возросшая сложность, потребности в адаптации и риски, связанные с управлением глобальной цепочкой поставок, могут свести на нет эти преимущества. Гибкость, достигаемая за счет интеграции процессов и информации, является одним из основных факторов, способствующих оптимизации управления цепочкой поставок, а также внедрению новых технологий и адаптации к потребностям и процессам предприятия [2] .

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

Рисунок 1 - Микросервисная и монолитная архитектура

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

Кроме того, если какой-либо программный компонент должен быть обновлен, все приложение должно быть переписано, тогда как в модульном приложении любой отдельный модуль (например, микросервис) может быть изменен, не затрагивая другие части программы. Модульные архитектуры снижают риск того, что изменение, внесенное в один элемент, приведет к непредвиденным изменениям в других элементах, поскольку модули относительно независимы. Модульные программы также легче поддаются итерационным процессам, чем монолитные программы.

Сервисы в микросервисной архитектуре (MSA) часто представляют собой процессы, которые обмениваются данными по сети для достижения цели с использованием независимых от технологии протоколов, таких как HTTP [5] . Услуги организованы вокруг бизнес-возможностей. Услуги могут быть реализованы с использованием разных языков программирования, баз данных, аппаратной и программной среды, в зависимости от того, что подходит лучше всего. Сервисы имеют небольшой размер, поддерживают обмен сообщениями, ограничены контекстом, разрабатываются автономно, развертываются независимо, децентрализованы и создаются с помощью автоматизированных процессов.

Микросервис - это не уровень внутри монолитного приложения (например, веб-контроллера или внутреннего интерфейса для внешнего интерфейса) . Скорее, это автономная часть бизнес-функциональности с понятными интерфейсами, которая может через свои внутренние компоненты реализовывать многоуровневую архитектуру [6] . В то время как монолитное приложение представляет собой единый унифицированный блок, архитектура микросервисов разбивает его на набор более мелких независимых блоков (рисунок 1) . Эти подразделения выполняют каждый процесс подачи заявки как отдельную услугу. Таким образом, все службы имеют свою собственную логику и базу данных, а также выполняют определенные функции. Такая архитектура легко поддается непрерывному процессу разработки программного обеспечения. Изменение небольшой части приложения требует перестройки и повторного развертывания только одной или небольшого количества служб. Придерживается таких принципов, как детализированные интерфейсы (для независимо развертываемых сервисов), разработка на основе бизнеса (например, дизайн на основе предметной области) . Архитектура микросервисов обычно применяется для облачных приложений, бессерверных вычислений и приложений, использующих облегченное развертывание контейнеров. По словам Фаулера, из-за большого количества (по сравнению с реализациями монолитных приложений) сервисов для эффективной разработки, поддержки и эксплуатации таких приложений необходимы децентрализованная непрерывная доставка и DevOps с целостным мониторингом сервисов [7] . Следствием (и обоснованием) такого подхода является возможность индивидуального масштабирования отдельных микросервисов. При монолитном подходе приложение, поддерживающее три функции, должно быть полностью масштабировано, даже если только одна из этих функций имеет ограничение ресурсов. При использовании микросервисов необходимо масштабировать только микросервис, поддерживающий функцию с ограниченными ресурсами, что обеспечивает преимущества по оптимизации ресурсов и затрат.

Архитектура микросервисов использует подход принципа единой ответственности и расширяет его до слабосвязанных сервисов, которые можно разрабатывать, развертывать и поддерживать независимо [8] . Каждая из этих служб отвечает за отдельную задачу и может взаимодействовать с другими службами через простые API-интерфейсы для решения более сложной бизнес-задачи. Поскольку составляющие сервисы невелики, они могут быть созданы одной или несколькими небольшими группами с самого начала, разделенными границами сервисов, что облегчает наращивание усилий по разработке, если это необходимо.

Структура системы представлена на рисунке 2. Она состоит из трех основных блоков: промежуточного программного обеспечения Node-RED, реализующего пользовательский интерфейс и блок координации / адаптации, а также внутренние компоненты, реализующие такие подсистемы, как семантическая служба и подсистема управления данными / искусственного интеллекта. Существует также вертикальная связь между всеми элементами системы за счет использования RabbitMQ в качестве уровня обмена сообщениями, где необходимы взаимодействия, не основанные на REST (например, асинхронные уведомления для прослушивающих пользователей о нарушениях, потоки данных и т. д. ) [9] .

Рисунок 2 - Архитектура микросервисной платформы

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

В качестве уровня реализации пользовательского интерфейса, который включает графические интерфейсы, через которые различные участники могут объявлять об использовании продуктов, зависимостях, а также создавать экземпляры определенных элементов своей цепочки поставок (таких как местоположения и типы этапов) . Они также вставляют необходимую практическую информацию, такую как ключи API для связи с внешними платформами IoT.
В качестве подключаемого механизма к существующим платформам управления IoT (например, EVRYTHNG) для извлечения продуктов (с помощью клиентских методов для их соответствующих API), а также потоков уведомлений от этих продуктов на основе данных сканирования от интеллектуальных датчиков в потоковой мода.
Промежуточное программное обеспечение и уровень интеграции, с помощью которого могут выполняться соответствующие модификации и адаптации из одного источника данных в другой (например, преобразование объявлений пользовательского интерфейса в семантические тройки для подачи в соответствующую службу), а также реализация специальной логики приложения (например, на основе правил на котором аномалии будут обнаруживаться и распространяться) в удобной для пользователя модели, основанной на потоковом программировании. Кроме того, он использует семантическую службу, чтобы обогащать входящие потоки данных аннотациями, относящимися к цепочке поставок, и пересылать эти данные в блок управления данными для использования в процессе ИИ.

Рисунок 3 - Поток UI Node-RED логики программирования

Второй важный блок - это семантический сервис. Это включает онтологию платформы, которая коррелирует концепции из цепочки поставок, такие как этапы, типы местоположений и отношения между участниками. Посредством применения этих связей входящие потоки данных от продуктов могут быть сопоставлены с семантическими концепциями цепочки поставок и могут быть определены зависимости от других участников или объектов. Семантическая структура построена на трех фронтах: База знаний, которая использует онтологию OWL для логических выводов и рассуждений, влеченные запросы SPARQL 1. 1 и интеграция с программными правилами на стороне Node-RED, а также дополнительные настраиваемые правила для логического аргумента Jena в База знаний (БЗ) (рисунок 3) . Архитектура ориентирована на службы, поэтому база знаний фактически является службой семантической сети. По этой причине используется сервер Apache Jena Fuseki, который обслуживает данные RDF через HTTP, используя SPARQL для передачи знаний в форме RDF.

Третий основной блок состоит из службы искусственного интеллекта (на основе Tensorflow) и хранилища данных (на основе MongoDB), цель которой - делать выводы о ключевых показателях каждого этапа (например, среднее время отдыха в заданном месте) и обнаруживать аномалии из изучение аннотированных исторических данных. С этой целью он хранит перенаправленные аннотированные потоки данных о входе и выходе продуктов на соответствующих этапах цепочки (идентификатор продукта, идентификатор вещи, тип этапа цепочки, день, месяц и время) . Далее можно использовать расширенные входные данные для извлечения моделей прогнозирования на основе исторических данных для времени перехода на каждом этапе цепочки поставок. Эта модель (основанная на глубокой нейронной сети DNNRegressor) должна создать прогноз ожидаемого времени, в течение которого вещь (экземпляр продукта или партия) должна оставаться на определенном этапе цепочки. Затем, основываясь на данных в реальном времени, можно обнаружить отклонения от нормального поведения и, следовательно, инициировать ранние уведомления вовлеченным объектам. Параметры прогнозирования также могут быть дополнены данными, поступающими из внешних уведомлений (например, событиями большой концентрации людей, обнаруженными из социальных сетей, информацией о дорожном движении и погоде и т. Д. ) . Платформа AI основана на Tensorflows с использованием Python 3.

Все элементы системы инкапсулированы как образы Docker, чтобы упростить процессы управления, обновления и развертывания [12] . Развертывание Docker может быть основано либо на отдельных контейнерах, либо на сгруппированных вместе элементах, образующих общую службу. Последнее более выгодно, так как оно позволяет выполнить развертывание в один клик после наличия соответствующего файла компоновки Docker. Этот файл описывает множество аспектов, среди которых виртуальные сети, к которым присоединяются все службы, виртуальные IP-адреса (для автоматического обнаружения между службами), порты служб, последовательность их запуска (если существуют зависимости), команды запуска и установки, количество желаемые экземпляры и т. д. Кроме того, Docker Swarm использовался в качестве системы управления кластером для балансировки нагрузки между узлами при развертывании службы [10] .

... продолжение

Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.