CC BY
102Проектирование сложного программного обеспечения с использованием микросервисной архитектуры
Кугушева Дарья Сергеевна
студент Института экономики, математики и информационных технологий, Российская академия народного хозяйства и государственной службы при Президенте Российской Федерации, [email protected]
Объектом исследования данной статьи являются два подхода проектирования программного обеспечения- микросервисный и монолитный. Предметом исследования является процесс разработки сложного программного обеспечения, требующего гибкости, отказоустойчивости и возможности расширения функционала по требованию заказчика. Цель исследования-выявление основных преимуществ микросервисного подхода над монолитным при разработке сложного программного обеспечения. В статье рассмотрен монолитный подход к проектированию ПО описана его архитектура и выявлены основные трудности разработки сложных программ с использованием этого подхода, также дано описание принципа работы микросервисной архитектуры приведены ее отличительные особенности, позволяющие существенно упростить процесс разработки больших продуктов, а также упомянуты основные технологические особенности микросерисного подхода, которые необходимо учитывать при выборе этой технологии разработки. Ключевые слова: микросервисная архитектура, микросервисы, проектирование, разработка программного обеспечения, монолитная архитектура
о см о см
1С
О!
^
I-О ш т х
<
т о х
X
Введение
С развитием технологий, логика работы программных продуктов постоянно усложняется, более того, от них требуется возможность постоянного расширения функционала и увеличение производительности. Основным инструментом, позволяющим создать конкурентно-способное приложение, является его архитектура. Используемый долгое время при разработке монолитный подход в современных реалиях не позволяет создать гибкое и масштабируемое приложение, на смену ему приходит современный микросервисный подход. Он позволяет разбить одну бизнесс-задачу на более мелкие функциональные части и реализовать из в виде отдельных независимых сервисов, которые и называют микросервисами.
Монолитная архитектура программного обеспечения
Монолитный подход считается классическим и подразумевает, что весь функционал такого приложения реализуется на одной кодовой базе. Монолитные приложения состоят из тесно вязаных компонентов и модулей, реализующих необходимые бизнес-задачи. Такой подход относительно прост в разработке и позволяет быстро реализовывать необходимый функционал, не задумываясь над проблемами коммуникации компонентов.
Монолитные решения как правило используют стандартную трехслойную архитектуру(рис 1): на рабочей станции пользователя располагается тонкий клиент, который обращается непосредственно в серверу приложений при помощи HTTP-запросов, сервисная часть же обрабатывает полученные от клиентской части запросы, а также взаимодействует с сервером баз данных, на котором расположена монолитная реляционная база данных приложения [1]. При внесении изменений в одни из компонентов требуется остановка и обновление всего приложения целиком.
■ т
1-1— КОМЛОНФШ 1—I— - 4» IX» ИГ« л 1-1— Нстивоигмт 1-1— М1
Г 1
С ^ 1ь* 1 < ДОИИМД 1
Рис 1. Трехслойная архитектура монолитного приложения
Однако по мере наращивания функционала разработчики монолитных продуктов зачастую сталкиваются с тем, что рамки модулей постепенно «стираются», между компонентами возникает все больше неочевидных взаимосвязей, а каждая реализация новых бизнес-задач оказывает влияние на код все большего числа модулей, что увеличивает трудозатраты разработчиков и требует серьезного тестирования на баги и регресс. Даже незначительная ошибка одного из компонентов может оказывать влияние на функционирование всего продукта и даже приводить к его полному отказу. Кроме того, стек технологий, используемых для написания нового функционала ограничен средствами, которые доступны в среде разработки монолита.
Также следует отметить трудности понимания монолитных программ. Если на начальном этапе приложение быстро развивается и имеет простую и понятную структуру, то с его развитием код многократно усложняется, привлекать новых сотрудников в команду разработки все сложнее, так как доскональное изучение всех нюансов работы продукта начинает занимать длительное время.
Микросервисная архитектура программного обеспечения
Описанные проблемы привели к появлению микросервисной архитектуры. При таком подходе все решаемые бизнес-задачи выделяются в отдельные небольшие, автономные, совместно работающие сервисы-микросервисы. Такие сервисы запущены в собственных процессах и являются независимыми друг от друга, а их границы четко обозначены решаемыми ими бизнес-задачами.
Монолитная сервисная часть приложения разделяется на множество компонентов, при этом каждый сервис обращается к собственной базе данных (database per instance) или же несколько копий одного сервиса могут обращаться к одной базе (database per microservice) (рис 2). В связи с такой децентрализацией возникает проблема неконсистентности данных. Распределенные транзакции могут решить данную проблему, но при этом существенно снизится производительность системы, потому вопрос согласованности данных «в конечном счете» необходимо решать на программном уровне. Широкое распространение получило решение управления транзакциями, называемое «сага» или «повествование», которое подразумевает приведение системы в согласованное состояние путем последовательных локальных транзакций на основе сообщений в каждом сервисе. [2, c. 146-147]
Рис 2. Архитектура приложения, реализованного с использованием микросервисов
При использовании такого подхода наращивание функционала производится путем внесения изменений только в тот сервис, который реализует соответствующую задачу, изменение других сервисов при этом не требуется, что делает разработку простой и понятной, а также снимает необходимость проверки всей системы на регресс.
Тестирование также упрощается за счет того, что для осуществления выпуска не нужно «копить» изменения, которые на протяжении длительного времени могут вноситься разработчиками, формируя большие разрывы между функциональностью релизов. В микросервисной архитектуре становится возможным выпуск отдельного микросервиса независимо от остальной системы. Независимость выпуска сервисов также ускоряет устранение программных ошибок и получение новых функциональных возможностей конечными пользователями, что дает продукту конкурентные преимущества перед его аналогами на рынке ПО.
Каждый микросервис может использовать для решения бизнес задачи свой набор технологий (языки програ-мирования, фреймвоки), такая технологическая независимость позволяет разделять разработку компонентов системы между командами разработчиков. Данный подход проектирования также позволяет решить трудности освоения новыми специалистами сложной системы, поскольку теперь новому разработчику не нужно разбираться в работе всего приложения: ему достаточно изучить функциональные особенности только того микросервиса, с которым ему предстоит работать. Более того, разработку одного микросервисного приложения теперь можно разбить между несколькими самодостаточными командами с различными компетенциями. При этом стоит отметить, что несмотря на всю независимость компонентов, на практике иногда при доработке продукта требуется внесение изменений в несколько микросервисов. В таком случае необходимо наладить грамотное взаимодействие между командами, а также предусмотреть версионность программных интерфейсов для поддержки бесперебойного взаимодействия новых версий микросервиса с предыдущими версиями смежных, так как команды осуществляют релизы своих сервисов в разное время.
Представление приложения в виде независимых сервисов в разы упрощает его горизонтальную масштабируемость, если монолитное приложение можно масштабировать только его запуском на нескольких физических серверах с использованием балансировщика нагрузки, то в микросервисной архитектуре каждый компонент приложения может независимо масштабироваться, в зависимости он частоты его вызовов в системе.
Еще одним достоинством приложений, использующих микросервисы становится их отказоустойчивость, так как при выходе из строя одного микросервиса происходит сбой в работе только части функционала, в то время как остальные сервисы продолжают работать в штатном режиме. В данной архитектуре отсутствуют неявные межмодульные взаимосвязи, потому определение сервиса, в котором произошла ошибка становится тривиальной задачей, а ее устранение, в виду простоты кода занимает меньше времени, в сравнении с монолитной архитектурой. [3, c 25-29].
Также следует отметить, что поскольку каждый сервис реализует свою конкретную функцию, он может быть повторно использован в последующих продуктах
X X
о
го А с.
X
го m
о
ю
2 О M
о
компании, сокращая таким образом стоимость их разработки.
Заключение
Разработка с применением микросервисной архитектуры является оптимальным решением для разработки сложного программного обеспечения. Она решает многие проблемы, с которыми сталкивается разработчик при написании большого монолитного приложения, упрощает разработку, тестирование и поддержку продукта, повышает отказоустойчивость. С использованием микросервисов система становится более гибкой, в ней могут использоваться различные технологии, а задачи расширения функционала требуют меньших трудозатрат и компетенций работника. Однако стоит отметить, что при использовании микросервисной архитектуры также имеет ряд трудностей, таких как работа с распределенными данными, сложная инфраструктура и возникновение накладных расходов при коммуникации между компонентами. Решение этих проблем зачастую нетривиально и требует от разработчиков больших компетенций, потому необходимо грамотно оценивать сложность разрабатываемого программного обеспечения, и понимать целесообразность его применения в действительно сложных системах, когда выгоды от его применения превышают трудозатраты.
Литература
1. Хабрахабр. [Электронный ресурс]: Микросервисы (Microservices). Режим доступа: (дата обращения: 09.05.20)
2. Ричардсон Крис Микросервисы. Паттерны разработки и рефакторинга. - СПб.: Питер, 2019. - 554 с.: ил.-(Серия «Библиотека програмиста»).
3. Ньюмен С. Создание микросервисов. — СПб.: Питер, 2016. — 304 с.: ил. — (Серия «Бестселлеры O'Reilly»).
Designing sophisticated software using microservice architecture
Kugusheva D.S.
RANEPA
The object of the article are the two approaches of developing software - monolithic architecture and microservice architecture. The purpose of the study is the process of developing sophisticated software that requires flexibility, fault tolerance and should also include the ability for extension of the system functional if required. This article discovers main difficulties of developing sophisticated software while using monolithic architecture and describes main principles and distinctive features of microservice architecture that help to reduce those difficulties and make the process of developing multifunctional systems easier and cheaper. It also mentions some technological aspect that should be taken into account in case of using this technology. Keywords: microservice architecture, microcervices, software development, monolithic architecture. References
1. Habrahabr. [Electronic resource]: Microservices. Access mode:
(accessed date: 05/09/20)
2. Richardson Chris Microservices. Development and refactoring
patterns. - SPb .: Peter, 2019. - 554 p.: Ill .- (Series "Programmer's Library").
3. Newman S. Creation of microservices. - SPb .: Peter, 2016 .--
304 p .: ill. - (O'Reilly Best Sellers Series).
о es о es
in
О Ш
m
X
<
m О X X
