Ближайший журнал
Ближайший Научный журнал
Paradigmata poznání. - 2022. - № 4

Научный мультидисциплинарный журнал

PP-4-22

русскийрусский, английскийанглийский, чешскийчешский

21-20.10.2022

Идёт приём материалов

Информатика Искусствоведение История Культурология Медицина Педагогика Политология Право Психология Религиоведение Социология Техника Филология Философия Экология Экономика


Литературный журнал Четверговая соль
Литературный журнал "Четверговая соль"

Каталог статей из сборников научных конференций и научных журналов- К вопросу о разработке микросервисных информационных систем и приложений

К-05.25.18
25.05-26.05.2018

К вопросу о разработке микросервисных информационных систем и приложений

И. Э. Гаглоева Кандидат технических наук, старший преподаватель,

Финансовый университет при Правительстве РФ,

г. Владикавказ, Республика Северная Осетия (Алания), Россия

 

Стремительное развитие IT-сферы накладывает новые требования: развитие технологий, меняющиеся потребности конечных пользователей – на все это нужно быстро реагировать [1, с. 308]. В настоящее время изменяются запросы многих крупных компаний и организаций к разрабатываемым информационным системам и приложениям [2, с. 3]. Одним из ключевых критериев реализации программного обеспечения является применение микросервисной архитектуры.

Микросервисная архитектура — это способ построения информационной системы, при котором она предстает в виде комплекса отдельных сервисов. Каждый из этих сервисов развертывается автономно и выполняет определенные функции общего приложения. Важной технической особенностью такой структуры является то, что данные хранятся децентрализовано, а за интеграционные процессы, такие как трансформация форматов сообщений, отвечают сами микросервисы вместо шин данных. При разработке приложений отсутствуют какие-либо ограничения в выборе технологий для реализации каждого микросервиса, что позволяет выбрать наиболее подходящее решение для удовлетворения конкретной бизнес-потребности. В результате организации перестают быть зависимы от конкретного вендора [3, с. 23–24].

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

У микросервисов есть особые свойства, которые являются преимуществами: 

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

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

- масштабируемость: чтобы увеличить производительность системы, нужно расширить лишь те сервисы, которые в этом нуждаются.

- гетерогенность: возможность построить систему с помощью разных языков программирования и технологий;

К недостаткам микросервисного подхода можно отнести:

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

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

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

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

- монолит полностью заменяется на микросервисы. 

- монолит остаётся в качестве центрального компонента системы, окружённого отделившимися микросервисами, а большинство доработок системы выполняется в виде новых микросервисов. 

При выборе второго направления можно устранить главный недостаток создания микросервисной архитектуры с нуля: не нужно тратить много времени на первоначальное деление системы на компоненты и организацию взаимодействия между ними. Главное выбрать правильный момент для начала разделения на сервисы: на слишком ранней стадии – микросервисы не будут наполнены необходимой бизнес-логикой, а на поздних стадиях перехода – границы модулей будут размыты, и разделить на микросервисы будет сложно. Оптимальным моментом перехода к микросервисам является период, когда стоимость нового функционала становится выше, чем польза от него.

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

Архитектура микросервисов оказывает положительное влияние не на все приложения. Приложение должно быть достаточно сложным, для того чтобы его можно было разбить на компоненты. Если приложение предназначено для выполнения только одной функции, потребности в микросервисах, как правило, нет. А вот сложное приложение, состоящее из множества компонентов, заметно выигрывает микросервисная архитектура так как:

- проще изменить один из микросервисов и сразу внедрить его, чем изменять весь монолит и перезапускать инфраструктуру целиком;

- новые разработчики легче включаются в работу – для этого им не нужно изучать систему целиком, можно работать только над своей частью;

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

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

Библиографический список

1. Гаглоева И.Э. К вопросу об оптимизации бизнес-процессов предприятия // Современные проблемы науки и образования: вопросы теории и практики: материалы Международной научно-практической конференции НИЦ «Поволжская научная корпорация». – Самара: ООО «Офорт», 2016. – С.308-310.

2. Гаглоева И.Э. Интеграция информационных систем предприятий электроэнергетики // Проблемы и перспективы современной науки: материалы XIV Международной научно-практической конференции. – Ставрополь: Логос, 2016.– С.3-6.,

3. Ньюмен С. Создание микросервисов. – СПб.: Питер, 2016. –304 с.

Полный архив сборников научных конференций и журналов.

Уважаемые авторы! Кроме избранных статей в разделе "Избранные публикации" Вы можете ознакомиться с полным архивом публикаций в формате PDF за предыдущие годы.

Перейти к архиву

Издательские услуги

Научно-издательский центр «Социосфера» приглашает к сотрудничеству всех желающих подготовить и издать книги и брошюры любого вида

Издать книгу

Издательские услуги

СРОЧНОЕ ИЗДАНИЕ МОНОГРАФИЙ И ДРУГИХ КНИГ ОТ 1 ЭКЗЕМПЛЯРА

Расcчитать примерную стоимость

Издательские услуги

Издать книгу - несложно!

Издать книгу в Чехии