При разработке приложений довольно часто используются микросервисы и микросервисная архитектура. В большинстве случаев такой подход подразумевает тесное взаимодействие с API, что сопряжено с определенными особенностями.
Что такое микросервисы
Микросервисы представляют собой набор сервисов, созданных для решения определенной логической задачи. Чаще всего они взаимодействуют друг с другом по средствам API, при этом не зная об устройстве других аналогичных компонентов. Данный принцип работы микросервисов получил название микросервисная архитектура. На ее базе разрабатываются приложения, чьи независимые сервисы при развертывании могут функционировать независимо друг от друга.
Микросервисная архитектура имеет целый ряд отличительных особенностей, которые хорошо прослеживаются при сравнении с сервис-ориентированной и монолитной архитектурами. Именно поэтому, прежде, чем подробно разбирать микросервисы, стоит узнать о сильных и слабых сторонах двух данных подходов.
Монолитная архитектура
Данный метод принято считать классическим. Созданные на его базе приложения, представляют собой модуль, состоящий сразу из нескольких, связанных между собой, компонентов. На практике, структура подобных приложений состоит из трех сущностей: базы данных, пользовательского интерфейса и бизнес-логики. Управление всеми функциями сконцентрировано в одном месте.
Такой тип архитектуры подразумевает довольно тесную связь между всеми компонентами. В ряде случаев это является плюсом, однако при масштабировании возникают проблемы, поскольку приложение становится более сложным. Внесенные изменения замедляют процесс обработки данных, из-за чего появляется потребность в дополнительных вычислительных мощностях. В итоге, разработчикам приходится решать проблемы с некорректным распределением информационных ресурсов.
Для монолитной архитектуры свойственно использование объемных реляционных БД, в которых хранятся сведения всего приложения. Это приводит к снижению эффективности и еще больше усложняет архитектуру.
Плюсы монолитной архитектуры:
- отсутствие проблем с межкомпонентными задачами – общая кодовая база практически исключает возможные проблемы с компонентами приложения;
- простота разработки – единая кодовая база помогает избежать трудностей с разработкой и последующим развертыванием приложения. Более того, разработчики могут воспользоваться большим количеством инструментов, способных упростить процесс создания;
- хорошая производительность – наличие единого кода заметно ускоряет взаимодействие между разными компонентами.
Минусы монолитной архитектуры:
- проблемы при масштабировании – для добавления нового функционала нередко приходиться переписывать весь программный продукт, что занимает много времени и приводит к серьезным финансовым затратам;
- расширения программного кода – постепенно структура приложения начинает размываться и разобраться в кодовой базе становится крайне сложно;
- полное отсутствие гибкости – для исправления ошибок или внедрения нового функционала придется заново развертывать продукт.
Несмотря на довольно серьезные недостатки монолитной структуры, иногда ее использование полностью оправдано. К примеру, данный тип широко распространен в небольших командах, где перед разработчиками стоит задача, как можно скорее выпустить приложение. Однако по мере расширения приложения его достоинства полностью нивелируются недостатками. Попытки решить данную проблему привели к развитию совершенно нового подхода.
Сервис-ориентированная архитектура
Данная разновидность предполагает разработку приложения со слабосвязанными модулями. Концепция такой архитектуры основывается на простой интеграции и возможности использовать одни и те же модули несколько раз. Одной из ключевых особенностей подобного подхода является сервисная шина, без которой невозможно управлять операциями. В случае необходимости она может взять на себя работу по преобразованию данных.
Дробление приложения на модули помогает небольшим командам сосредоточиться на создании одного конкретного сервиса, что положительно сказывается на скорости разработки. Под сервисом понимают компонент программного обеспечения, в котором заключен определенный функционал. Им могут пользоваться как сторонние системы, так и другие компоненты создаваемого продукта.
В отличие от монолитной, в сервис-ориентированной структуре база данных не является главным звеном всей архитектуры. В БД хранятся только те данные, которые нужны для работы сервисов. Взаимодействие происходит посредством специальных интерфейсов, которые отвечают за обеспечение бесперебойного доступа к нужной информации.
Плюсы сервис-ориентированной структуры:
- простая поддержка – независимые сервисы хорошо масштабируются и легко заменяются, что в значительной мере упрощает создание приложений и их последующую поддержку;
- повторное использование сервисов – поскольку между компонентами довольно слабая связь, их можно использовать в разных частях программного продукта;
- возможность параллельной разработки – разбиение проекта на модули дает возможность создавать сразу несколько сервисов.
Минусы сервис-ориентированной структуры:
- требовательность к финансовым ресурсам – приложения, в основе которых лежит сервис-ориентированная архитектура, нуждаются в серьезном инвестировании;
- проблемы при управлении службами – некоторые компоненты часто обмениваются друг с другом сообщениями. Иногда их количество может превышать миллион в день;
- дополнительная нагрузка – поскольку входные данные проверяются еще до взаимодействия сервисов друг с другом, показатели общей производительности могут снижаться, особенно если одновременно используется большое количество сервисов.
Сервис-ориентированная архитектура позволила ускорить процесс создания приложений, облегчить их поддержку и обслуживание, а также повысить их адаптивность. Постепенно данный принцип развивался, часть решений оказалась неэффективной и от них отказались, а им на смену пришли новые технологии. Так сервис-ориентированная архитектура получила свой подтип, названный микросервисной архитектурой.
Микросервисная архитектура
Согласно принципу микросервисной архитектуры в ходе разработки ПО создаются небольшие, практически автономные модульные сервисы. Каждый из них является отдельной частью программного обеспечения, содержит конкретный функционал и располагает собственной базой данных. Более того, микросервисы можно создавать и масштабировать независимо друг от друга.
Чтобы определить принципы взаимодействия сервисов друг с другом была разработана специальная методология, получившая название DDD или Domain Driver Design. Данный подход позволяет создавать более качественные приложения, которые хорошо масштабируются и поддерживаются.
Совокупность методологии DDD и микросервисной архитектуры широко распространена при разработке слабосвязанных между собой микросервисов. Проще говоря, каждый из них является отдельным доменом с собственной бизнес логикой. Это позволяет создавать масштабируемые и гибкие продукты, которые хорошо переносят повышенные нагрузки и могут адаптироваться практически к любым условиям и требованиям.
Обычно работа микросервисов осуществляется согласно следующему алгоритму:
- через пользовательский интерфейс поступает запрос;
- далее он передается в сервис аутентификации;
- сервис аутентификации делает запрос к доменной среде, чтобы узнать имеет ли посетитель право заходить на запрашиваемую страницу;
- реализуется проверка перечня доступов пользователей через специальный запрос к БД, после чего информация возвращается обратно в сервис аутентификации;
- когда сервис аутентификации понимает, что пользователь располагает соответствующими правами доступа, он пускает его в логику приложения, которая в свою очередь возвращает ответ на первоначальный пользовательский запрос.
На первый взгляд, может показаться, что подобная архитектура только усложняет процесс разработки. На самом же деле, использование микросервисов позволяет воспользоваться большим количеством преимуществ. В подобные системы можно интегрировать новые модули, не беспокоясь о нарушениях в общей логике. Поскольку каждый сервис работает в автономном режиме, изменения в одном компоненте, никак не отразятся на других.
Разработка распределенных программных продуктов сопряжена с использованием таких сервисов, как Service Broker и Service Discovery. Первый дает возможность разработчикам быстро создавать приложения из нескольких микросервисов и гибко управлять ими. По сути, приложение разделяется на несколько независимых частей, каждая из которых развертывается на отдельном сервере.
Второй сервис позволяет сервисам общаться между собой, передавая друг другу сведения о настройках и доступности. Service discovery применяется в микросервисной архитектуре для того, чтобы сервисы могли в автоматическом режиме настроиться на совместную работу.
Что касается баз данных, то микросервисы пользуются разными инструментами и технологиями, в том числе NoSQL, API и ORM. Для каждого сервиса может быть создано отдельное хранилище или они могут брать информацию из общей БД при помощи API.
Плюсы микросервисной архитектуры:
- повышенная гибкость – при работе с модулями необязательно полностью отключать все приложение. В случае возникновения проблем, изменения можно в любое время откатить назад, при этом реализация данного механизма крайне проста;
- быстрый и простой деплой – добиться этого получается за счет автономного создания и тестирования микросервисов;
- выборочное масштабирование – при необходимости масштабировать можно только те компоненты которые в этом нуждаются. Остальные модули могут использовать более слабое аппаратное обеспечение.
Минусы микросервисной архитектуры:
- повышенные требования к безопасности – информация между компонентами передается по сети. Такой подход сопряжен с повышенным риском утечки данных, поэтому необходимо использовать дополнительные защитные меры;
- трудоемкий мониторинг – когда количество микросервисов ограничивается несколькими десятками, отследить их работу сложно, но возможно. Однако, чаще всего, в приложениях используются сотни, а то и тысячи компонентов, поэтому приходится обращаться за помощью к системам мониторинга и управления;
- обилие языков программирования – никто не запрещает использовать разные ЯП для каждого микросервиса, но такой подход чреват различными ошибками на этапе развертывания. Чтобы избежать проблем, стоит внимательно относиться к выбору используемых на проекте технологий.
Связь микросервисов и API
Как было сказано выше, микросервисы работают по принципу разделения функциональных возможностей. Множество небольших сервисов объединяются между собой, образуя тем самым общий макросервис. В отличии от него, микросервис выполняет только одну конкретную задачу. При этом объем этих небольших задач зависит от самого приложения и предъявляемых к нему требований.
Микросервисной архитектуре свойственна децентрализация серверов. Минимизировать этот эффект помогают контейнерные технологии. Задача контейнера – инкапсулировать код вместе с зависимостями в особую изолированную среду. Впоследствии она может быть перемещена в облако.
Сам по себе набор автономных модулей не несет никакой практической пользы программному продукту. Для этого микросервисы объединяются между собой при помощи API. Принцип этого механизма схож с тем, что используется при интеграции одного приложения с другим. Единственное отличие в том, что при взаимодействии микросервисов применяется не общедоступный API, а частный. Он есть у каждого микросервиса, и с его помощью сервис понимает какие запросы ему получать и как на них отвечать.
Нужно понимать, что микросервисная архитектура предполагает несколько вариаций использования API при взаимодействии с микросервисами. Например, один сервис может обращаться сразу к нескольким API, или же один API может использоваться для получения доступа к разным микросервисам. Возможных вариантов довольно много, и выбор зависит от особенностей конкретного проекта.
Заключение
Микросервисная архитектура является одной из разновидностей сервис-ориентированной архитектуры. Она предполагает одновременное взаимодействие автономных сервисов, каждый из которых выполняет одну строго поставленную задачу. Связать их в единую систему и гибко масштабировать позволяет API.
Микросервисная архитектура располагает широкими возможностями в области гибкой разработки. Но для их качественной реализации требуется грамотный подход к организации взаимодействия всех компонентов. Для создания надежной системы необходимо правильно провести планирование, мониторинг и тестирование.
При условии, что микросервисная архитектура считается наиболее актуальным подходом к созданию приложений, в ряде случаев ее использование не целесообразно. Прежде всего из-за риска привнести излишнюю сложность, которой можно было бы избежать при монолитном подходе. Более того, далеко не все программные продукты могут быть поделены на множество небольших автономных частей.
