Микросервисная архитектура: чем она хороша и кому нужна

Микросервисная архитектура — подход к разработке программного обеспечения, при котором приложение строится из небольших автономных и управляемых компонентов. Каждый из этих компонентов — микросервисов (microservices/MS) — выполняет определенные функции и взаимодействует с остальными через API. 

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

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

Что такое микросервисы и как они работают 

Микросервисы — это небольшие независимые модули, каждый их которых отвечает за конкретный элемент логики приложения. Между собой эти модули «общаются» с помощью программного интерфейса приложения (API, Application Programming Interface). При этом каждый из них запускается в изолированной среде.

Микросервисная архитектура дает множество преимуществ для разработки и поддержки приложений. При ее использовании: 

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

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

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

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

Краткий обзор монолитной и сервис-ориентированной архитектуры (SOA)

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

Монолитная архитектура. Приложение с монолитной архитектурой выстраивается из компонентов, объединенных в единый неделимый блок — монолит. Все они связаны между собой напрямую и тесно взаимодействуют. 

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

Пик популярности монолитная архитектура переживала в 90-е и 2000-е годы, когда приложения были проще и чаще всего разворачивались на едином сервере. Но и сегодня монолитный подход нельзя считать устаревшим — он все еще активно используется. Причем не только в разработке небольших проектов, но и в таких крупных, как Booking или GitHub. 

Сервис-ориентированная архитектура (Service-Oriented Architecture, SOA). 

Судя по названию «сервис-ориентированная архитектура» несложно догадаться, что именно сервисы выступают ключевыми элементами приложений, построенных на ее базе. При этом эти сервисы автономны, обладают определенным интерфейсом и могут быть объединены в более крупные компоненты. 

В основу сервис-ориентированного подхода заложена идея переиспользования сервисов. Это становится возможным благодаря применению так называемой корпоративной шины (Enterprise Service Bus, ESB), которая позволяет сервисам взаимодействовать. 

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

Преимущества микросервисов перед монолитом

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

Однако причины для стремительного роста популярности микросервисов налицо. В их числе: 

• Простое масштабирование. Отдельные микросервисы внутри приложения можно масштабировать независимо друг от друга. 

• Независимость компонентов. Функциональные модули внутри микросервисного приложения полностью автономны, что позволяет разрабатывать, развертывать и обновлять их, не влияя на работу всего ПО. 

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

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

• Легкая «работа над ошибками». Если один из микросервисов нуждается в обновлении или замене, процесс внесения доработок не приводит к полной остановке системы. Это упрощает поддержку приложения и повышает уровень клиентского сервиса. 

• Легковесность компонентов. Легковесные протоколы взаимодействия между микросервисами, такие как HTTP или REST, ускоряют обмен данными. 

Отличия микросервисной архитектуры от SOA

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

Однако по стилю архитектуры эти подходы фундаментально различны: 

• SOA-архитектура централизована и слабо разграничена; 

• микросервисная архитектура децентрализована и предполагает создание ПО с распределенными системами.

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

Несмотря на массу достоинств, которыми обладает микросервисный подход, он не лишен и ряда недостатков: 

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

• Большое количество модулей. С одной стороны, как мы отмечали выше, это хорошо. С другой — затрудняет мониторинг и поддержку. 

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

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

• Дорогая разработка. Микросервисы — это недешево. Для их разработки, развертывания и поддержки понадобится команда (а то и не одна) квалифицированных специалистов. А еще потребуются специализированные инструменты и сервисы для управления модулями и мониторинга работы приложения. 

Мы обсудили преимущества и особенности микросервисов — самое время поговорить о том, как они работают.

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

Взаимодействие микросервисов через API

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

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

Основные паттерны интеграции микросервисов

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

• синхронная интеграция с помощью HTTP/REST API;

• асинхронная интеграция через очереди сообщений (Message Queues), которая реализуется с помощью таких сервисов как RocketMQ и Kafka;

• группировка API c API Gateway;

• и многие другие. 

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

Типы проектов, для которых микросервисы подходят лучше всего

Говоря детальнее, микросервисная архитектура будет эффективна для таких проектов, как: 

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

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

• Cloud-native приложения. Облако — идеальная база для микросервисного приложения. Оно всегда готово к большим нагрузкам и масштабированию, а также позволяет распределить микросервисы по разным серверам, что еще увеличивает показатели отказоустойчивости ПО.

Примеры известных компаний, использующих микросервисную архитектуру

Тенденция на переход к микросервисной архитектуре впервые обнаружила себя еще в 2000-х. Тогда такие гиганты зарубежного рынка, как Google, Amazon и Microsoft начали развивать облачную инфраструктуру, чтобы дать своим клиентам возможность создавать сервисы без использования собственных мощностей. Параллельно начали развиваться как технологии контейнеризации, в том числе Docker, так и платформы оркестрации контейнеров, например Kubernetes. А уже в 2010-х микросервисный подход начали применять многие крупные игроки: Netflix, Twitter, Airbnb, Adidas и многие другие. 

Сегодня интерес к микросервисам только растет. В России, согласно опросу CNews, микросервисную архитектуру уже используют 35% российских компаний. Об опыте перехода сообщали крупные банки, а также, например, «М.Видео-Эльдорадо» и «МегаФон». 

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

• Один из самых популярных инструментов для создания микросервисов — платформа для развертывания и управления приложениями на основе контейнеризации Docker. Он позволяет создавать для приложений отдельные контейнеры с виртуальным представлением серверной операционной системы. С его помощью вы также можете создавать Docker-образы, загружать их в приватный реестр Evolution Artifact Registry и развертывать контейнеры на их основе в готовой облачной среде Evolution Container Apps.  

• Для управления большими наборами контейнеров — то есть для их «оркестрации» — чаще всего используется Kubernetes. В Cloud.ru для этого предусмотрен сервис Evolution Managed Kubernetes.

• Чтобы контролировать распределение нагрузки между модулями микросервисного проекта, также необходимы балансировщики. По принципу работы они могут быть программными, аппаратными и облачными. Например, для распределения сетевого трафика между виртуальными машинами в условиях повышенной нагрузки можно использовать Evolution Load Balancer. 

• Также для эффективной работы микросервисного проекта важны брокеры сообщений и платформы потоков событий, такие как Apache Kafka. Они помогают микросервисам непрерывно общаться почти в реальном времени, маршрутизируя потоки, как этого требует текущая схема взаимодействия. А для управления брокерами сообщений в облаке можно использовать Evolution Managed Kafka. 

Согласно отчету аналитического агентства IKS-Consulting, в следующие четыре года объем рынка облачных инфраструктурных сервисов в России вырастет в 3,8 раза, до 464 млрд руб. Параллельно его росту интерес к микросервисам также будет только расти, ведь именно микросервисная архитектура считается наиболее естественным подходом для разработки облачных приложений. Причиной тому ее очевидные преимущества, особенно в сфере Agile-разработки и развертывания сложных приложений корпоративного уровня, в числе которых: 

• простота обновления кода;

• возможность использования разных технологических стеков; 

• возможность независимого масштабирования модулей и, как следствие, сокращение затрат на масштабирование приложения в целом.  

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