Микросервисная архитектура: преимущества и недостатки

Что такое микросервисная архитектура?

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

Что такое микросервис на практике

Формального размера у микросервиса нет. Работает другой признак: сервис можно выкатить, откатить и перезапустить независимо от остальных, у него своя база или своя схема, а с соседями он общается только через объявленный интерфейс. Если для выкладки одного сервиса приходится синхронно выкатывать ещё три, это распределённый монолит: минусы обоих подходов сложились, а плюсы не появились.

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

Когда монолит остаётся правильным выбором

Разделение на сервисы стоит денег постоянно, а не один раз на старте, и эти расходы должны окупаться. Предпосылок нет, если:

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

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

Монолит и микросервисы: сравнение по критериям

Как проводить границы сервисов

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

1. Описать сценарии: что происходит от события до результата и какие данные меняются.
2. Сгруппировать сценарии вокруг понятий со своими правилами: заказу, складу и бухгалтерии про один товар нужны разные поля и состояния.
3. Разнести то, что правится каждую неделю, и то, что не менялось год.
4. Проверить связность: если типовая операция дёргает три чужих сервиса, граница проведена неверно.
5. Зафиксировать контракты: какие запросы сервис принимает, какие события публикует, что обещает по времени ответа.

Взаимодействие сервисов и данные

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

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

Что должно быть готово до первого релиза

• Контейнеризация. Docker даёт одинаковое окружение у разработчика, на тестовом стенде и на бою.
• Оркестрация. Кто перезапускает упавший контейнер, как раскатывается и откатывается версия — решается до релиза, а не в момент аварии.
• Логи и сквозная трассировка. Записи собираются в одно место с идентификатором, который присваивается запросу на входе и идёт по всей цепочке.
• Метрики и оповещения. Время ответа, доля ошибок, длина очередей, соединения с базой — с порогами для уведомлений.
• Проверки состояния. Сервис сообщает о своей готовности, и оркестратор понимает, можно ли направлять на него трафик.

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

Преимущества микросервисной архитектуры

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

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

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

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

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

Также стоит учитывать возможное усложнение процесса развертывания из-за необходимости организации автоматизированных средств CI/CD (Continuous Integration/Continuous Deployment) для каждого из сервисов отдельно. Это требует дополнительных ресурсов на настройку и поддержку инфраструктуры.

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