• Что такое микросервисная архитектура простыми словами
• Принципы построения микросервисов
• Микросервисы и монолит: в чем разница
• Преимущества микросервисной архитектуры
• Недостатки и подводные камни
• Рост сложности инфраструктуры
• Зависимости между сервисами
• Требования к DevOps и автоматизации
• Сравнение микросервисной и монолитной архитектуры
• Отличия в разработке и сопровождении
• Стоимость внедрения и поддержки
• Монолит или микросервисы: что выбрать
• Реализация микросервисов: как это устроено на практике
• Ключевые компоненты микросервисной экосистемы
• Микросервисная архитектура — выбор банков, ИТ, телекома и e-commerce
• Примеры использования микросервисной архитектуры
• Подведем итог

Микросервисная архитектура — подход к созданию систем, при котором система разделена на независимые друг от друга компоненты, то есть модули, микросервисы. Они могут решать определенную бизнес-задачу (авторизация, аутентификация, безопасный обмен данными) или отвечать за определенную логическую цепочку (например, создание заказа). Сервисы общаются между собой синхронно через сетевые интерфейсы (HTTP/REST, gRPC) или асинхронно — через брокеры сообщений.

Микросервисы — один из типов организации архитектуры. Существуют и другие, например сервисно-ориентированная, монолитная. ИТ-консультант А. Н. Баланов приводит эволюцию подходов к организации архитектуры:

• до 2000 г. — монолиты и клиент-серверные системы. Все компоненты приложения — база данных, бизнес-логика, пользовательский интерфейс — находились на одном физическом узле (машине). 2000–2010 г. — с-ориентированная архитектура. Она подразумевала разделение бизнес-логики на независимые блоки, взаимодействующие друг с другом по протоколам REST, SOAP. Пример: веб-сервисы.
• после 2010 г. — микросервисная архитектура. Концепция микросервисов возникла с развитием технологий виртуализации и контейнеризации. Приложение разделяют на множество блоков. Каждый из них выполняет конкретную функцию, разрабатывается, разворачивается и масштабируется независимо от других. Пример: аутентификация, каталог товаров, обработка заказов в веб-приложениях.

Мартин Фаулер и Джеймс Льюис в 2014 году описали микросервисы как подход к разработке единого приложения в виде набора небольших сервисов. Они работают в отдельных процессах и взаимодействуют с применением упрощенных механизмов, которые строятся  вокруг бизнес-потребностей и развертываются независимо с помощью автоматизированного механизма. Эксперты перечислили девять характеристик микросервисной архитектуры, среди которых — компонентизация, организация с учетом бизнес-возможностей, децентрализованное управление.

С практикой внедрения появились шаблоны проектирования:

• управление данными — «База данных на сервис», «API-композиция», «Разделение команд и запросов»;
• декомпозиция «Разбиение по бизнес-возможностям», «Разбиение по поддоменам»;
• рефакторинг и/или переход на микросервисную архитектуру: «Душитель» , «Уровень защиты от повреждений»;
• коммуникация — «API-шлюз» (API Gateway), «Бэкенды для фронтендов» (Backends for Frontends, BFF) и другие.

Например, шаблон «База данных на сервис» (Database Per Service) подразумевает, что у каждого сервиса должна быть собственная БД, а коммуникация микросервисов происходит только согласно контрактам.

Пускай есть сервисы А и В. У В нет собственной базы данных, поэтому он обращается к А. Если А завтра изменит контракт и обновит версию, то В никто не уведомит. Допустим, в А изменили структуру БД: удалили колонку. Сервис А работает, так как его бизнес-логика верная. В никто не оповестил, он по-прежнему обращается к колонке и хочет читать данные, но структура БД уже другая. Как результат — ошибка.

Для управления базами данных используют Oracle Database, MS SQL, PostgreSQL, IBM DB2, MySQL и другие решения. Например, Platform V Pangolin DB — специальная сборка PostgreSQL уровня enterprise с более чем 80 доработками для повышения производительности, безопасности, удобства разработки и сопровождения. СУБД от СберТеха входит в ТОП-3 российских СУБД по версии CNewsMarket. Platform V Pangolin DB интегрируется с провайдерами Zabbix и Prometheus, обеспечивает маскировку security-данных, «из коробки» поддерживает мониторинг.

Монолит содержит одну комплексную единицу (приложение).

Микросервисы — это бизнес-компоненты, которые, как правило, распределены по разным узлам и общаются между собой через общую сетевую шину.

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

Микросервисная архитектура — один из подходов, а не универсальное решение. У него есть и минусы:

• усложнение инфраструктуры;
• зависимости между сервисами;
• требования к DevOps и автоматизации;
• «зоопарк технологий»;
• необходимость оркестрации и управления контейнерами.

Для работы нужны системы мониторинга, логирования и трассировки, сквозного наблюдения (Observability Engineering), инструменты проверки связанности.

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

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

Монолит можно развернуть на одной физической машине. В случае с микросервисами нужно настраивать хосты и DNS Resolver, чтобы обращаться к сервису по статическому имени, а не динамическому IP-адресу (IP обновляется каждый раз при перезапуске контейнера).

Монолит часто выбирают на старте или для небольших проектов. Но со временем появляются проблемы, которые эксперт в области микросервисов и основатель портала Microservices.io Крис Ричардсон назвал монолитным адом и большим комком грязи:

• сложность кодовой базы увеличивается экспоненциально;
• сборка занимает 2–5 часов, среда разработки тормозит;
• цикл «Написание → сборка → запуск → тестирование» затягивается;
• доставка изменений в промышленную среду усложнена, происходит раз в месяц или реже;
• архитектура монолита заставляет разработчиков использовать устаревший стек.

Части приложения в микросервисной архитектуре автономны, поэтому их проще обновлять и масштабировать. 

Модульный монолит легче разрабатывать и сопровождать, когда кодовая база небольшая. Например, на старте разработки или внебольших проектах. Но по мере разрастания приложения его сложнее поддерживать и масштабировать. Кодовая база увеличивается, ее сложнее понимать, а, значит, вносить подходящие изменения. Брайан Фут и Джозеф Йодер назвали это джунглями спагетти-кода, неряшливым комом, перемотанным проводами и изолентой.

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

Монолит дешевле. Не нужна команда DevOps-инженеров для поддержки, сервисы-агрегаторы состояний, анализ и мониторинг (трейсинг), инструменты оркестрации.

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

При выборе архитектуры учитывают особенности проекта и доступные команде ресурсы.

Микросервисы подходят для проектов супераппов), корпоративных систем, enterprise- или cloud-native приложений. Данное решение выбирают, когда на проекте сложные потоки развертывания и несколько команд разработчиков.

Монолит актуален для простых проектов с небольшими командами и/или ограниченными ресурсами.

Простая реализация выглядит таким образом:

1. От клиента (браузер, мобильное приложение) поступает запрос.
2. Первая точка входа — API Gateway. API Gateway передает запрос роутеру.
3. Роутер API Gateway выбирает, к какому сервису обратиться: например, аутентификации, каталогу, корзине.
4. Микросервис обращается к своей базе данных или по контракту — к БД другого сервиса.

Микросервисы (аутентификация, каталог, корзина, скидки) объединяют в кластер. Его размещают на отдельной стойке. Кластер обслуживает определенный сегмент пользователей: например, покупателей из Москвы.

• Инфраструктура. Реплики микросервисов размещают на одной или нескольких физических нодах. Минимальная мощность на легковесный микросервис (API, обработчик) — 0.5–1 vCPU, 1–2 ГБ RAM. Для среднего (с БД, очередями) нужны 2 vCPU, 4 ГБ RAM.
• Контейнеры и кластеры. Сервисы изолированы в отдельных контейнерах. Когда контейнеров больше 100, их объединяют в кластеры. Нужны мониторинг, логирование, отслеживание состояния с автоматической заменой неработающих экземпляров. Чтобы работать с контейнерными приложениями, используют Platform V DropApp, OpenShift, Kubernetes. Для управления взаимодействием в облачных средах подходят Istio или Platform V Synapse Service Mesh. Для размещения самих кластеров нужна безопасная сертифицированная основа, например Platform V SberLinux OS Server.
• База данных. Паттерн проектирования Database Per Service подразумевает, что должна быть одна база данных на сервис. Для управления данными, обеспечения изоляции сервисов и оптимизации масштабирования используют СУБД. К примеру, Platform V Pangolin DB, Oracle Database, MS SQL, PostgreSQL, IBM DB2, MySQL и другие.
• API Gateway. Это единая точка входа. Шлюз отвечает за маршрутизацию запросов, агрегацию данных, управление доступом и трафиком. Для управления жизненным циклом API используют Platform V Synapse API Mesh, IBM API Connect, Gravitee, Kong, TYC.
• Доставка сообщений между системами. Для обработки потоковых данных используют Apache Kafka или Platform V Corax, Apache ActiveMQ Artemis или Platform V Synapse Messaging, RabbitMQ, IBM MQ.

Система может усложняться: для безопасности и сетевой коммуникации нужен Service Mesh, для защиты от чрезмерной нагрузки — Rate Limiter, для обнаружения новых сервисов — справочник (Service Discovery). Подключают системы мониторинга (трассировки), инструменты развертывания и CI/CD, системы управления конфигурациями, балансировщики нагрузок.

На Platform V доступны портфели «Инфраструктурные решения», «Работа с данными», «Интеграционные сервисы», «Кибербезопасность» и иные. Команды могут использовать комплексный подход или отдельные компоненты платформы. Чтобы получить тестовую версию продуктов, оставьте заявку или напишите на platformv@sbertech.ru.

Ретейл, банковский и финансовый сектор, электронная коммерция, ИТ и телеком, промышленность и производство, транспорт и логистика, государственный сектор — сферы, в которых необходимо обрабатывать миллионы транзакций и большие объемы трафика. Крупным предприятиям важно масштабирование отдельных компонентов независимо друг от друга, высокая производительность при пиковых нагрузках.

Малые и средние компании выбирают данное решение, когда необходимо быстро масштабировать отдельные функции.

«Аэрофлот», СберТех, СберБанк Онлайн подтвердили, что в своих решениях используют микросервисную архитектуру. Продукты СберТеха позволили «Аэрофлоту» создать систему обработки данных авиакомпании — СОДА. Среди сценариев использования — начисление миль при отправке рейса, рассылка пассажирам информации об изменении места, уведомления о необходимости оплатить бронь.

Сбер перевел текущие сервисы на платформу Platform V Synapse, что позволило решить проблему пропускной способности корпоративной сервисной шины и в семь раз увеличить скорость отклика. Стоимость разработки интеграции уменьшилась на 54%, а совокупная стоимость владения снизилась в шесть раз.

За рубежом архитектурный подход применяют в Google, Amazon, Netflix, Uber, Microsoft, Oracle.

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