Это моя первая публикация на Medium, в которой я делюсь отрывком из моей магистерской диссертации; как Архитектура микросервисов помогла мне разработать структуру для Промышленного Интернета вещей за 6 месяцев.
Это также с намерением написать для студентов, которые стремятся к своей диссертации (или проекту последнего года), для новых разработчиков, стремящихся изучить поток того, как несколько небольших приложений могут играть большую роль в приложении корпоративного уровня, и для всех моих опытная / квалифицированная аудитория, которая дала бы обратную связь о том, как я мог бы достичь блестящих результатов в реализации моей диссертации. Эта диссертация является частью моей степени магистра в RWTH Ахенском университете, Германия 🇩🇪.
«Идея заключалась в том, чтобы использовать технологии, использованные в Интернете вещей, и совместить их с промышленной революцией 4-го поколения, то есть Индустрией 4.0».
К настоящему времени почти каждый слышал слово «микросервисы»; небольшое приложение / сервис, предназначенный для выполнения определенной задачи независимо от любого другого программного обеспечения или сервиса. Это не что-то слишком сложное для новичка, это просто концепция слабо связанных (почти не зависимых) программных сервисов, объединенных в одно полное приложение.
Архитектура микросервисов (иногда также называемая сервис-ориентированной архитектурой) - это набор сервисов, составляющих сложное приложение. Его концепция заключается в том, что если какая-либо часть приложения выходит из строя, это не должно влиять на другие функции и функции, связанные с ней. Звучит надежно и крепко, правда?
Хотя формального определения архитектуры микросервисов (MSA) нет, есть определенные характеристики, позволяющие идентифицировать это утверждение. Мартин Фаулер описывает микросервисы как: Программные приложения с масштабируемостью, бизнес-возможностями, автоматическим развертыванием, интеллектом в конечных точках и децентрализованным контролем языков и данных.
* альтернативой архитектуры микросервисов было монолитное приложение, построенное на едином программном стеке, и каждый компонент сильно зависел друг от друга.
Сочетание всего: программные приложения, которые могут развертываться независимо, модульные по своей природе, запускать уникальный процесс с четко определенной областью действия, обладают легким механизмом для обслуживания бизнес-целей и слабо связаны с высокой степенью согласованности, в конечном итоге становятся частью микросервисов. Архитектура. Такие архитектуры лучше всего подходят для обработки разных программных стеков и для совместной работы в соответствии с конвейером реализации.
Вот что я сделал ... создал конвейер из нескольких небольших приложений в качестве строительного блока для реализации моей магистерской диссертации. Эти реализации приложений были основаны на Apache Kafka (используется для системы обмена сообщениями), Apache Spark (для потоковой передачи и обработки данных в реальном времени) , MEAN Stack (Node.js, Angular для приема и визуализации данных) , Python для RaspberryPi (вместе с программированием датчиков), MySQL (образцы данных), JAVA Spring (для сопоставления карт) и MongoDB как озеро данных. Таким образом, учитывая общие временные рамки в 6 месяцев, мне было удобно выбрать архитектуру микросервисов. Таким образом, я смог познакомиться с этими технологиями для реализации и сэкономил время на написание подробного отчета в соответствии с требованиями магистерской диссертации.
«Магистерские диссертации обычно рассчитаны на 6 месяцев. В течение этих 6 месяцев каждый студент должен разработать POC / MVP (подтверждение концепции / минимально жизнеспособный продукт) вместе с исследовательской статьей / работой, которую нужно защищать перед профессорами (супервайзерами) университета. Таким образом, он может быть частью какого-либо исследовательского проекта или может стать основой какого-либо промышленного проекта ».
Теперь ограничиваем объем разбивкой на реализацию магистерской диссертации, которая включает в себя различные технологические стеки, и как я смог использовать их с архитектурой микросервисов в течение 6 месяцев?
Во время написания моей диссертации руководители университетов выразили две основные озабоченности. Первый был связан с разнообразием задействованных технологий, а второй - с возможностью реализации в течение 6 месяцев. Ответ на вторую проблему уже прояснен в предыдущем параграфе, а что касается первой проблемы, да, разнообразие предназначалось для реализации. Поскольку цель заключалась в разработке «Расширяемой структуры для данных датчиков в контексте промышленного Интернета вещей». Таким образом, мне требовалось множество датчиков, чтобы они работали в соответствии с моим конвейером с Node и Python, аналогично для обработки такого разнообразия входящих данных от датчиков мне нужна была система обмена сообщениями, которая должна быть достаточно быстрой и надежной, чтобы обрабатывать несколько потоков в любой момент. времени, поэтому я выбрал Кафку. Точно так же входящие данные должны были обрабатываться на ходу с помощью Spark Streaming Engine, а затем данные сбрасывались в базу данных на основе документов, которой была MongoDB.
Поэтому, когда у вас есть такое разнообразие технологий, вы не можете полагаться на монолитную архитектуру (монолитные приложения строятся как единое автономное устройство, где изменение одного компонента влияет на приложение в целом). Следовательно, на помощь приходит микросервисная архитектура (MSA)! MSA придерживается концепции, согласно которой, если какая-либо часть приложения выходит из строя, это не должно влиять на другие функции и функции, связанные с ней. Я немного его отлепил и сделал конвейер таких микроприложений (сервисов) для реализации своей магистерской диссертации.
Контекст промышленного Интернета вещей
Идея заключалась в том, чтобы использовать технологию, использовавшуюся в Интернете вещей, и наложить ее на промышленную революцию 4-го поколения, то есть Индустрию 4.0. Все мы знаем об идее, лежащей в основе Интернета вещей (IOT), о том, что все без исключения электронные устройства подключены друг к другу значимым образом, чтобы облегчить нашу жизнь; обеспечивая удобство в повседневной жизни. Точно так же Индустрия 4.0 предполагает автоматизацию. Сделать фабрики полностью основанными на роботе; то есть меньшее участие человека приведет к меньшему количеству человеческих ошибок и меньшим поводам для беспокойства. Простым примером может служить обрабатывающая промышленность: вы поставляете сырье и получаете готовый продукт с ограниченным участием человека или без него. Отсюда и заводы будущего.
Города будущего и фабрики будущего
Идея заключалась в разработке такой структуры, которая была бы достаточно гибкой, чтобы адаптироваться к характеру входящих данных. В контексте промышленного Интернета вещей эти входящие потоки данных в основном поступают от машинного датчика и промышленного робота. Затем эти данные обрабатываются и используются в моей структуре на ходу. В результате получаются значимые данные, которые могут стать исходными данными для последующего транспортно-экспедиционного оборудования в конвейере этой конкретной отрасли.
В реальной реализации эти данные, которые были загружены в озеро данных, на самом деле являются входными данными для следующего компонента Industry Pipeline.
Framework обрабатывает входящий поток данных из нескольких разных источников, анализирует его на ходу и загружает значимую информацию в озеро данных. Где входящие данные поступают от нескольких гигантских промышленных роботов, работающих по разным протоколам связи, генерирующих данные в разных типах и форматах с очень высокой скоростью. Протоколы связи варьируются от OPC-UA до традиционных веб-сокетов, тогда как форматы данных варьируются от двоичных файлов низкого уровня до JSON и XML. Вот еще одна блок-схема, изображающая архитектуру в контексте того, как данные передаются от промышленных роботов в озеро данных.
Это объясняет часть «Franework for Sensor Data», но как насчет «Extensible»? Полученная структура могла выполнять вышеупомянутую задачу в контексте промышленного Интернета вещей, но также была достаточно надежной, чтобы обрабатывать входящие данные из других доменов; с идеей plug-and-play с небольшой конфигурацией без изменения или обновления каких-либо компонентов Приложения.
Чтобы защитить расширяемость Framework, я также разработал POC на основе приложения Car-to-X, которое может помочь в мониторинге перегрузок на дорогах в реальном времени с использованием сопоставления карт.
Этап №1 - Обертки для входящих данных с машин
Поскольку промышленные системы основаны на разнородных источниках данных, нам нужны такие программные компоненты, которые были бы достаточно динамичными, чтобы адаптироваться к изменениям, которые могут произойти. Функциональность, которая начинается с системы очередей сообщений и задействования механизма потоковой передачи, останется более или менее неизменной, но источник данных изменится в соответствии с изменением входящих данных или связанных протоколов датчика. Изначально роботы, над которыми мне пришлось работать, были нацелены на веб-сокеты, TCP-клиенты и клиенты OPC-UA. Их можно настроить в соответствии с входными данными, ожидаемыми от датчиков, через связанный с ними файл ресурсов XML, который помогает им эффективно взаимодействовать с экосистемой, созданной для этой диссертации. Приложение Wrapper, которое я написал для этих входных данных, обрабатывает данные через файлы конфигурации, с помощью которых можно управлять потоком данных, который инициируется датчиками, роботами и промышленными машинами.
Этап № 2 - Система очереди сообщений с Apache Kafka
API, основанный на Apache Kafka, фреймворке распределенного обмена сообщениями, был разработан и развернут в одном из университетских облаков (получил специальный облачный сервер для реализации системы обмена сообщениями, благодаря моему профессору 😃). Целевой функциональностью Apache Kafka была обработка сгенерированных данных с нескольких датчиков. Я выбрал Apache Kafka из-за его функциональности по воспроизведению данных и реализации тематических подписок. Сама тематическая подписка Kafka выступала в качестве основы для подписки, и отдельные производители и потребители обрабатывали входящие данные на основе разных источников. Таким образом, использование Apache Kafka в качестве отказоустойчивой системы с низким потреблением памяти значительно снизило нагрузку до Streaming Engine. Вот блок-схема, показывающая роль Кафки в моей магистерской диссертации. Другим вариантом был бы Apache Flume, но да, Kafka побеждает!
Этап № 3 - Механизм потоковой передачи в реальном времени
Apache Spark используется в качестве потокового движка для обработки входящего потока данных в реальном времени. Эта обработка в реальном времени использует данные и упрощает дальнейший анализ. Apache Spark поставляется с множеством поддерживаемых функций, таких как методы работы с окнами, скользящие шаги и анализ потоков данных. Apache Kafka также может выступать в качестве движка потоковой передачи, но мы выбираем Apache Spark, поскольку он может быть расширен, когда требуется использование машинного обучения, Spark MLib может играть важную роль в прогнозировании в реальном времени. Apache Spark предоставляет такую потрясающую экосистему, которую не предоставляет ни Apache Kafka, ни какой-либо другой потоковый движок. Это включает встроенную поддержку динамического языка запросов, библиотек для графов и машинного обучения.
Как и множество источников сбора данных, Apache Kafka и эта реализация механизма потоковой передачи в реальном времени также были отдельным проектом, не зависящим от других компонентов в конвейере моей диссертации. Реализация Spark была основана на Scala, ее можно настроить и запустить в любой системе с виртуальной машиной Java.
Фаза №4 - Попадание в озеро данных
Процесс, инициированный машинами, генерирующими данные датчиков, завершается в Data Lake. В моей диссертации база данных MongoDB на основе документов действовала как озеро данных для последующего использования собранных значимых данных. Было несколько причин, по которым я выбрал MongoDB, но я считаю, что они не предназначены для объяснения в этом отрывке. Однако, помимо MongoDB, у меня был выбор: использовать Apache Cassandra или Apache Hbase.
В дополнение к этой загрузке данных в их окончательное местоположение я написал небольшое приложение MEAN Stack (MongoDB, Express, Angular, Node) для визуального представления данных, идущих к озеру данных.
Визуализированный MongoDB был простым приложением и являлся альтернативой использованию консоли MongoDB, которая представляет текстовый формат документов в коллекциях конкретной базы данных MongoDB. С помощью этого приложения мы можем избежать текстовой команды на консоли для проверки данных в нашей базе данных. Эта альтернатива помогла мне отслеживать вставку каждого набора данных, который, если бы он не был реализован, должен был бы выполняться вручную на очень частой основе для отслеживания приема данных.
Это приложение стека MEAN не было частью моего первоначального предложения на магистерскую диссертацию, а было дополнительным усилием, чтобы показать мою преданность… было признано моим профессором за это небольшое усилие.
Подключенный автомобиль, реализация сопоставления карт
И последнее, но не менее важное: чтобы оправдать расширяемость моей магистерской диссертации, я придумал вариант использования, основанный на Connected Cars. Без каких-либо изменений в моей реальной реализации, я просто переключил источник данных. Я поменял местами входящие данные от машин с данными, генерируемыми датчиками в машине, и я начинаю получать местоположение каждой машины в реальном времени. Эта дополнительная реализация алгоритма сопоставления карт в моем движке потоковой передачи Spark позволила мне доказать расширяемость моей инфраструктуры, обнаружив заторы на дороге. Вот визуальное представление в виде изображения в формате GIF.
Сопоставление карт - это проблема сопоставления записанных географических координат с логической моделью реального мира, обычно с использованием той или иной формы географической информационной системы. через Википедию
Вот и все, надеюсь, это поможет всем, кто читает.
Хлопайте, чтобы оценить. Один, два или много хлопков. Спасибо 😃
Вы можете найти / подписаться на меня @ok_ansari. С уважением, Омер Калим Ансари
