Все говорят о микросервисной архитектуре приложений. Чем она хороша и как на нее перейти?

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

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

К 2021 году микросервисная архитектура в центре внимания, причём, не только специалистов: о ней пишут в блогах, в соцсетях, обсуждают в прессе и на различных конференциях. Об успешном внедрении микросервисов заявляют представители Amazon, Google, Netflix и Twitter. В России об опыте перехода на микросервисы сообщали крупные банки, а также, например, «М.Видео-Эльдорадо» и «МегаФон»^[1].

При этом в сообществе программистов всё чаще звучат голоса скептиков, не считающих микросервисы чем-то принципиально новым. По их мнению, это просто реализация сервис-ориентированной архитектуры (SOA) на более низком уровне. Как бы то ни было, микросервисная архитектура имеет очевидные преимущества, особенно в сфере Agile-разработки и развёртывания сложных приложений корпоративного уровня.

Микросервисы как естественная архитектура облачных приложений

По состоянию на 2021 год микросервисная архитектура считается наиболее естественным подходом для разработки облачных приложений. Таковые состоят из множества слабо связанных и независимо разрабатываемых мелких модулей — сервисов. Для этих сервисов, как правило, характерны три свойства:

• у них есть собственный стек, включающий базу и модель данных;
• они взаимодействуют друг с другом посредством сочетания REST API, потоков событий и брокера сообщений;
• модули приложения подбираются исходя из конкретных потребностей бизнеса^[2].

С точки зрения бизнеса и чисто организационных задач, преимущества микросервисов сводятся к трём основным:

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

Микросервисы, монолитная архитектура и SOA

Чтобы уточнить отличия микросервисов от других архитектур, их чаще всего сравнивают с монолитной архитектурой и сервис-ориентированной архитектурой (service-oriented architecture, SOA). Микросервисное приложение состоит из множества мелких независимых и слабо связанных между собой сервисов, в то время как в монолите все его компоненты тесно взаимосвязаны и работают как единый сервис. Помимо прочего, это значит, что если какой-то один процесс в приложении с монолитной архитектурой становится более востребованным, приходится масштабировать всё приложение в целом. Сбой в каком-то одном процессе может поставить под угрозу всю систему. Наконец, такая сложность ограничивает возможности модернизации и затрудняет внедрение новых идей.

Монолитная архитектура (Monolithic) отличается тесной взаимосвязью между компонентами, включая бизнес-логику (Business Logic) и слой доступа к данным (Data Access Layer), и выступает как единый сервис. В микросервисной архитектуре (Microservices) клиент через общий пользовательский интерфейс (UI) получает доступ к отдельным слабо связанным между собой микросервисам (Microservice). Источник: Red Hat, Inc

Отличия микросервисов от SOA не столь очевидны. Можно пойти по сложному пути и перечислить множество технических деталей, в том числе связанных с ролью сервисной шины предприятия (ESB), но можно поступить проще и оценить уровни, на которые распространяются эти архитектуры. Если SOA — это архитектура уровня предприятия, призванная стандартизировать взаимодействие всех служб, то микросервисы относятся к какому-то одному конкретному приложению.

Микросервисы, менеджеры и разработчики

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

Отдельные сервисы чрезвычайно просты и могут развёртываться независимо друг от друга, а это значит, что для того чтобы поменять какую-то строчку в коде, не требуется принятие решений на самом верхнем уровне. Тем самым внесение мелких изменений больше не отнимает лишнего времени. Небольшие команды, независимо работающие над отдельными сервисами, могут также объединяться в многофункциональные коллективы по Agile-методологии.Чекап для искусственного интеллекта: зачем и как тестировать ИИ-решения?

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

Микросервисы и DevOps

Методология DevOps (от англ. development и operations; набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга) часто рассматривается как одно из важнейших и непременных достоинств микросервисов, что неудивительно, поскольку речь идёт о частом развёртывании небольших сервисов. Более того, именно следование принципам DevOps делает микросервисы успешной архитектурой. В отличие от монолитной архитектуры, микросервисная — это сложная распределённая система с множеством независимых элементов, которая требует оперативного взаимодействия между разработчиками и пользователями, частого обновления и максимального уровня автоматизации. А это именно то, в чём заключается суть концепции DevOps.

Ключевые технологии и инструменты

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

Прежде всего, речь идёт о Docker^[3] — ПО для развертывания и управления приложениями на основе контейнеризации — модели вычислений, наиболее тесно ассоциируемой с микросервисами. Поскольку индивидуальные контейнеры для приложений не обладают всеми атрибутами полноценной операционной системы, они меньше и легче по объёму, чем обычные виртуальные машины. Благодаря этому они запускаются и отключаются быстрее, и тем самым идеально подходят для небольших и лёгких микросервисов.

Пример организации сервиса по аренде автомобиля с водителем (Trip Management) на облачной платформе Amazon EC2. В процессе работы сервис отвечает на несколько запросов, каждый из которых обрабатывается в отдельном Docker-контейнере (Docker Container). Передача информации осуществляется через REST API по протоколу HTTP. Распределением запросов занимается балансировщик нагрузки (Load Balancer), такой как nginx. Источник: NGINX

С появлением множества сервисов на базе контейнеризации стали чрезвычайно востребованы средства автоматизации управления большими наборами контейнеров. Одной из самых популярных в мире технологий «оркестровки» контейнеров, то есть автоматического развёртывания, управления, масштабирования и сетевого подключения на сегодняшний день является Kubernetes^[4].

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

Однако связь через API не является эффективным и практичным способом оперативного взаимодействия в реальном времени, поэтому наряду с ним в этих случаях применяются обмен сообщениями или потоками событий. С этой задачей лучше всего справляются брокеры сообщений и платформы потоков событий, такие как Apache Kafka^[5].

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

Микросервисы и облачные сервисы

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

Недостатки микросервисной архитектуры

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

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

Из-за этих и других подобных ограничений специалисты не рекомендуют^[6] переходить на микросервисы просто в погоне за модой: бизнес должен располагать грамотной и подготовленной командой разработчиков и администраторов, а также достаточной инфраструктурой. Кроме того, эксперты не советуют использовать эту архитектуру без облачных технологий, а также практик Agile и DevOps.

Примечания

Смотрите также

• Чек-лист: Как минимизировать риски при переходе на микросервисную архитектуру
• SOA Архитектурные особенности и практические аспекты
• SOA 2.0
• SOA (рынок России)
• SOA (мировой рынок)