Задачи и эволюция микросервисной архитектуры

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

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

Краткая история создания микросервисов

Микросервисная архитектура появилась в результате эволюции сервисно ориентированной архитектуры (SOA). Впервые над идеей микросервисов начал работать Питер Роджерс, ИТ-архитектор компании NetKernel, в 1999 году. Целью его исследования было сделать код менее хрупким, более гибким и устойчивым к большим изменениям.

Клоков Владимир Николаевич

Первые результаты исследования были представлены им на конференции Web Services Edge в 2005 году. Он выдвинул идею, что необходимо не просто создавать отдельные сервисы по SOA – самой популярной архитектуре веб-разработки на тот момент, но распределять данные по конкретным микросервисам и передавать их с помощью коннекторов. В своей презентации Роджерс наглядно пояснил, как распределение данных между отдельными сервисами позволяет гибко подстраиваться под любые изменения, а также увеличить простоту кода в отдельно взятых сервисах.

Параллельно с ним Юваль Леви, архитектор программного обеспечения и руководитель компании IDesign, в 2007 году высказал свою идею, весьма схожую с понятием «микросервис», он призвал к созданию систем, где каждый отдельный класс является сервисом. Это требует использования технологий, которые могут поддерживать такое детальное использование сервисов, и Леви самостоятельно расширил Windows Communication Foundation (WCF), взяв каждый класс и рассмотрев его как сервис, сохраняя при этом традиционную модель программирования классов.

Также в 2005 году Алистер Кокберн, американский ученый-компьютерщик, написал о гексагональной архитектуре, которая представляет собой шаблон проектирования программного обеспечения, используемый наряду с микросервисами. Этот шаблон делает возможным проектирование микросервиса, поскольку он многоуровнево изолирует бизнес-логику от вспомогательных служб, необходимых для развертывания и запуска микросервиса, полностью независимого от других [1]. Широкое применение идеи микросервисов началось в 2011 году, когда на различных конференциях (например, “A Workshop of Software Architects”, май 2011 года) всё чаще стали использовать термин «микросервис». С 2012 по 2014 годы о глобальном внедрении микросервисов в архитектуру своих сервисов сообщили такие компании, как Amazon, Netflix и Twitter. По данным компании O’Reilly, на 2020 год микросервисы использовались в 77 % компаний мира, и таких компаний становилось всё больше [2].

Определение и основные понятия микросервисов

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

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

Затем появились микросервисы. Программные системы стали разбиваться на небольшие элементы, которые можно разрабатывать и развертывать независимо друг от друга. Микросервисная архитектура развивалась при поддержке приверженцев DevOps, которым требовалась быстрая поставка обновлений – новых возможностей, исправлений багов и улучшений безопасности. Кроме того, с такой архитектурой многие компании могли переписать устаревшие приложения с использованием современных языков программирования и обновленного стека технологий [3].

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

Микросервисы неразрывно связаны с DevOps, поскольку лежат в основе методики непрерывной поставки, благодаря которой команды могут быстро адаптироваться к требованиям пользователей. Микросервис – это веб-сервис, отвечающий за один элемент логики в определенной предметной области. Приложения создаются как комбинации микросервисов, каждый из которых предоставляет функциональные возможности в своей предметной области. Микросервисы взаимодействуют друг с другом через API-интерфейсы, такие как REST или gRPC, но не обладают информацией о внутреннем устройстве других сервисов.

На Рисунке 1 представлен пример использования микросервисной архитектуры [3].

Рисунок 1. Пример использования микросервисов Источник: Микросервисная архитектура от А до Я [6].

Микросервисы как противопоставление монолиту

Ни одна архитектура не известна так хорошо, как проверенное и настоящее монолитное приложение. Сторона клиента, сторона сервера и база данных соединяются в один JAR-файл и отправляются на сервер для развертывания. Его легко разрабатывать, тестировать и развертывать. Однако при попытке сделать сервис более быстрым и эффективным у монолитной архитектуры выявляется много недостатков. Решением проблемы может быть переход на микросервисы. Микросервисная архитектура является альтернативой классическому монолиту и решает многие проблемы, связанные с последним. Основная идея микросервисов состоит в том, чтобы разбить бизнес-логику и уровни доступа к данным на независимые сервисы. Каждая служба имеет собственную базу данных и ориентирована на определенные бизнес-возможности. Микросервис может взаимодействовать как с клиентской стороной, так и с другими службами через четко определенный API [4]. В Таблице представлен свод плюсов и минусов монолитов и микросервисов.

Таблица

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

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

*Источник: Монолитная vs Микросервисная архитектура [7].

На Рисунке 2 представлено наглядное сравнение монолитной и микросервисной архитектур.

Кейсы применения микросервисной архитектуры

Для понимания, в каких ситуациях лучше использовать микросервисы, следует рассмотреть несколько кейсов, где может быть использована микросервисная архитектура [5].

Приложения, работающие с большими данными. AL/ML – один из лучших вариантов использования архитектуры микросервисов. Приложения для работы с большими данными требуют сложной архитектуры, ориентированной на конвейер данных, где каждый этап управляет одной (или несколькими) конкретными задачами, например, сбором, обработкой, доставкой, хранением и др. Такие слабо связанные блоки отлично подходят для микросервисов.

Приложения для обработки данных в реальном времени. Наиболее распространенными вариантами использования являются потоковые платформы, такие как YouTube или SoundCloud, приложения электронного банкинга, системы управления дорожным движением, онлайн-бронирование и др., – приложения, выполняющие операции в режиме реального времени для быстрого получения результата.

Задачи и эволюция микросервисной архитектуры

Рисунок 2. Сравнение монолита и микросервисов

Источник: Монолитная vs Микросервисная архитектура [7].

Крупномасштабные системы со сложной логикой. Стремительно растущие организации (например, социальные сети, средства массовой информации, e-commerce) требуют выдающейся гибкости и масштабируемости, которые в точности обеспечивает архитектура микросервисов. Это помогает компаниям быстро находить узкие места или задействовать новые передовые технологии. Более того, возможность частого развертывания на уровне взаимодействия обеспечивает еще более быструю масштабируемость [8].

Заключение

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

• •    при работе с большим количеством данных, которые необходимо пересылать и обрабатывать между большим количеством сервисом;

• •    в больших компаниях, поскольку это позволяет распределить микросервисы между небольшими командами, которые будут минимально зависимы друг от друга;

• •    при увеличении производительности сервиса. Если функциональность сервиса выросла до таких масштабов, что ее производительность начала ухудшаться, то необходимо задуматься над переходом к микросервисной архитектуре.

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