Главная
АИ #30 (57)
Статьи журнала АИ #30 (57)
Плюсы и минусы микросервисной архитектуры в Spring Boot

10.5281/zenodo.12508348

Плюсы и минусы микросервисной архитектуры в Spring Boot

Рубрика

Информационные технологии, телекоммуникации

Ключевые слова

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

Аннотация статьи

Объектом данного исследования стал метод реализации программного обеспечения – микросервисная архитектура в феймворке Spring Boot. Создание приложений на основе микросервисов характеризуются большей производительностью и изменчивостью в результате добавления инновационных технологических решений. Разобщенное состояние компонентов системы позволяет тестировать и экспериментировать с разными форматами для обеспечения максимальной эффективности приложения. Так как микросервисы плотно взаимодействуют друг с другом, но находятся в малой зависимости, у разработчиков присутствует возможность работы с каждым компонентом отдельно, а именно их видоизменения, присоединения дополнительных модулей, либо полного исключения из структуры. Плюсы и минусы микросервесной архитектуры рассмотрены через призму сравнения с монолитной, из которой она и появилась. В заключительной части исследования сформирована общая оценка реализации микросервисной архитектуры на текущий период времени. 

Текст статьи

Введение

В текущее время возможно разрабатывать программное обеспечение с помощью микросервисной и монолитной архитектур в различных фреймворках. В свою очередь, модуль одного из таких вспомогательных инструментов —Spring Boot – позволяет значительно сокращать временные затраты на процесс системного проектирования, и в целом оптимизирует многие текущие процессы в ходе реализации проекта. Во время обработки информации данный модуль способен присоединять к себе сторонние для ускоренного решения задачи. Данный фреймворк способен разрабатывать микросервисную архитектуру, предоставляя широкий функционал в создании приложений на её основе.

Методологической основой данного исследования послужил анализ интернет-ресурсов и литературных источников, посвящённых созданию программного обеспечения посредством микросервисной архитектуры. Исследование проводилось посредством системного анализа, который позволяет рассмотреть изучаемую проблематику как в общем плане, так и уделить внимание отдельным аспектам поставленного вопроса. Включение в работу дополнительных источников литературы даёт подкрепление к выдвигаемым гипотезам, признаваемых в научном сообществе. Spring Boot является способом разработки с открытым исходным кодом на Java языке. Его активно применяют для создания многих проектов ввиду обширного функционала и способов реализации.

Принципы микросервисной архитектуры в Spring Boot

Микросервисная архитектура представляет собой некоторую взаимосвязь отдельных компонентов (обычно слабо связанных друг с другом). Разработка и повсеместное использование микросервисов обусловлено тем, что с ними можно работать обособленно от общей работы с приложением. Элементы микросервисной архитектуры поддаются любому взаимодействию и видоизменению без создания препятствий в функционировании других её компонентов и самого приложения в целом [1]. Принцип её работы имеет схожесть с созданием изображения в цифровом формате, которое содержит различные слои, на каждом из которых располагается отдельный объект. В случае повреждения файла или допущения ошибки в процессе иллюстрирования, специалист может вернуться на предыдущий этап и откорректировать его.

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

Такой подход широко используется в создании сложных программ с большим количеством содержащихся данных. Это достигается не только за счёт возможности внесения корректировок в отдельные элементы, но и благодаря отсутствию необходимости трансформирования всего кода. Последний фактор является основным недостатком в монолитной архитектуре программного обеспечения. Косов С.Г. в своей работе «Разработка и тестирование приложений с микросервисной архитектурой» также противопоставляет микросервисы монолитной архитектуре: «Микросервисная архитектура представляет собой приложение, разбитое на атомарные сервисы, которые имеют api, использующее какой-либо сетевой протокол. Каждый микросервис реализует операции в выделенной бизнес-области. Микросервисаная архитектура противопоставляется монолитной архитектуре, в которой все бизнес-процессы выполняются в одном большом приложении. Основными недостатками монолитной архитектуры являются сложность горизонтального масштабирования и высокий порог вхождения для нового разработчика» [2].

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

image.png

Рис. 1. Инструменты феймворка Spring Boot

Положительные аспекты применения микросервисов

Осипов Д.Б. в своём исследовании «Проектирование программного обеспечения с помощью микросервисной архитектуры» отмечал еще одно преимущество деления кодовой базы на микросервисы: «Так как большинство языков программирования поддерживают определение публичного интерфейса только на уровне документирования, то инкапсуляция у компонента может быть нарушена, что приводит к слишком высокой связанности компонентов». Данный пример отображает возможность микросервисной архитектуры программного обеспечения недопустить этого путем «использования удалённых вызовов» [3]. Нередко разработчики приложений и сервисов делают выбор в пользу микросервисной архитектуры, так как она имеет многоступенчатую систему, компоненты которой не имеют строгой иерархии. В таком случае при обнаружении технического повреждения одного модудя можно отрегулировать его в индивидуальном порядке, либо вычленить из структуры. Микросервисы выстраиваются в структуре таким образом, что, если очаг проблемы появится в одном из компонентов, то он останется в нем и не вызовет повреждение всей системы, что характерно для монолитной архитектуры [4].

Если приложение отличается большим объёмом данных, либо связано с корпоративным управлением, то приостановка всей его деятельности может привести к серьёзным последствиям. Например, в работе компаний, специализирующихся на логистике, навигационные системы в которой должны работать бесперебойно и отображать текущую ситуацию по маршрутам. В противном случае, помехи в работе программного обеспечения платформы могут вызвать издержки производства и пошатнуть конкурентоспособность предприятия. Поэтому своевременная диагностика и исправление повреждённых элементов, что подразумевает микросервисная архитектура, позволит избежать подобного исхода. Гудков М.С. в своем исследовании «Анализ архитектур информационных систем: монолитная и микросервисная» подробно описывает преимущества микросервисной архитектуры в контексте сравнения с классической – монолитной:

image.pngРис. 2. Преимущества микросервисной архитектуры

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

Сравнительный анализ монолитной и микросервисной структур

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

Сервисы, созданные на основе монолитной архитектуры, часто не позволяют вносить изменения в код ввиду необходимости полного его преобразования. В отличие от микросервисной архитектуры, монолитную в разы сложнее масштабировать, отсутствие которого приводит к дополнительному потреблению энергии и сбоям в работе приложения во времена высокой нагрузки, и, при одновременном использовании приложения большим количеством пользователей. Кугушева Д.С. в своем исследовании «Проектирование сложного программного обеспечения с использованием микросервисной архитектуры» описывает недостатки применения данного метода, которые заключаются преимущественно в необходимости настройки управленческой структуры и введения дополнительных методов для защиты информации.

image.pngРис. 3. Минусы микросервисной архитектуры в % соотношении

Основным недостатком микросервисной архитектуры в Spring Boot является увеличение нагрузки на передачу данных в результате постоянного обмена информативными данными компонентов системы, что может вызвать технологические затруднения в работе системы. Несмотря на то, что элементы микросервисной архитектуры, в случае возникновения сбоя в каком-то из них, могут замкнуть источник проблемы в себе, ее диагностика может занять большее количество времени, так как необходимо провести проверку состояния каждого из них.

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

Заключение

Таким образом, многие научные исследования и практический опыт разработчиков программного обеспечения подтверждают, что приложения, построенные на основе монолитной архитектуры, значительно уступают микросервисной. Её основные преимущества на Spring Boot заключаются в гибкости системы и адаптивности под изменения, масштабировании и преобразования модулей, а в случае повреждения системы можно разобраться с источником проблемы точечно, заменяя или корректируя компоненты. Ввиду того, что микросервисная архитектура получила свое распространение сравнительно недавно, она имеет и ряд несовершенств, которые выражаются в осуществлении регулярного мониторинга за состоянием микросервисов и их разобщенного состояния, что повышает риски утечки данных в результате кибератаки. Для исключения данных негативных последствий важно более детально прорабатывать каждый компонент системы для повышения её общей устойчивости.

Список литературы

  1. Spring Boot Documentation. 2021. Available from: https://docs.spring.io/spring-boot/docs/2.5.4/reference/html/ 
  2. Косов С.Г., Кальянов Л.В. Разработка и тестирование приложений с микросервисной архитектурой // Форум молодых ученых. – 2019. – №4. – С. 567-571.
  3. Осипов Д.Б. Проектирование программного обеспечения с помощью микросервисной архитектуры // Вестник науки и образования. – 2019. – №5. – С. 41-46.
  4. Гудков М.С. Анализ архитектур информационных систем: монолитная и микросервисная // Вестник науки. – 2021. – №1. – С. 48-51.
  5. Кугушева Д.С. Проектирование сложного программного обеспечения с использованием микросервисной архитектуры // Инновации и инвестиции. – 2020. – №5. – С. 188-190.
  6. Spring Blog. 2020. Available from: https://spring.io/blog
  7.  Baeldung. Articles on Spring Boot. 2020. Available from: https://www.baeldung.com/spring-boot
  8. SpringOne Conference. 2020. Available from: https://springone.io/
  9.  IEEE Xplore Digital Library. 2020. Available from: https://ieeexplore.ieee.org/
  10.  ACM Digital Library. 2020. Available from: https://dl.acm.org/

Поделиться

Ф. Е. Плюсы и минусы микросервисной архитектуры в Spring Boot // Актуальные исследования. 2021. №30 (57). URL: https://apni.ru/article/2749-plyusy-i-minusy-mikroservisnoj-arhitektury-v-spring-boot

Обнаружили грубую ошибку (плагиат, фальсифицированные данные или иные нарушения научно-издательской этики)? Напишите письмо в редакцию журнала: info@apni.ru

Похожие статьи

Актуальные исследования

#49 (231)

Прием материалов

30 ноября - 6 декабря

осталось 4 дня

Размещение PDF-версии журнала

11 декабря

Размещение электронной версии статьи

сразу после оплаты

Рассылка печатных экземпляров

24 декабря