Микросервисная архитектура: что это, принципы, плюсы и минусы

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

Команда LDM разработала свою микросервисную платформу для управления контентом, которая позволяет структурировать,  безопасно хранить документы и управлять корпоративным контентом.

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

Дальше возникает практический вопрос. Как все это запускать и поддерживать?

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

Но когда сервисов становится много, одних контейнеров уже недостаточно. Их нужно как-то координировать. Здесь обычно появляется Kubernetes. Это инструмент оркестрации контейнеров. Он распределяет нагрузку, следит за состоянием сервисов и при необходимости автоматически перезапускает их.

Есть еще один важный момент — взаимодействия между сервисами. В распределенной архитектуре это происходит постоянно. Чтобы управлять запросами, часто используют API Gateway. Он принимает входящие запросы и направляет их в нужный сервис.

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

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

У микросервисных систем есть одна важная особенность. Их довольно трудно обновлять вручную.
Представим приложение из нескольких десятков сервисов. Каждый из них может обновляться отдельно. Делать это вручную — не самая удобная идея.

Поэтому в таких проектах почти всегда используют DevOps-подходы и CI/CD.

Начинается все с непрерывной интеграции. Разработчики регулярно добавляют изменения в код. После этого автоматически запускаются тесты и сборка сервисов. Если появляется ошибка, ее обычно видно сразу.
Дальше работает непрерывная доставка. Новые версии сервисов подготавливаются к запуску автоматически. Иногда обновления выходят несколько раз в день.

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

Для сложных распределенных систем это уже практически стандартный подход. Автоматизация снижает объем ручной работы разработчиков и упрощает поддержку нескольких версий. Но CI/CD не отменяет архитектурных требований: каждый релиз требует автоматической проверки совместимости API, миграций данных и сценария отката.

Чаще всего микросервисы встречаются там, где системы быстро усложняются.

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

Банковские системы тоже постепенно переходят к такой архитектуре. Финансовые сервисы регулярно добавляют новые функции: мобильные приложения, онлайн-платежи, цифровые продукты. Микросервисная модель упрощает развитие таких систем.

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

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

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

Плюсы:

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

Минусы:

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

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

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

Есть и другой плюс. Отказоустойчивость.

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

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

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

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

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