Микросервисы или монолит: как выбрать правильную архитектуру

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

Архитектура должна помогать компании безопасно менять продукт с необходимой скоростью. Сравнивайте реальные ограничения: устойчивость предметной области, число и самостоятельность команд, конфликты при выпуске, различия в нагрузке, требования к согласованности данных, доступности и восстановлению, регуляторное обособление, возможности платформы и полную стоимость сопровождения. Сам объём трафика редко определяет модель. Качественно спроектированное приложение способно масштабироваться задолго до того, как ему понадобятся десятки сервисов, тогда как зависимость между командами иногда оправдывает разделение раньше, чем вычислительная нагрузка.

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

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

Монолит — способ развёртывания, а не изъян проектирования

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

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

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

Независимость микросервисов имеет цену распределённой системы

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

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

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

Сравнивайте компромиссы, которые действительно влияют на выпуск изменений

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

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

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

Стоимость: учитывайте затраты времени людей и нагрузку на знания команды, а не только вычислительные ресурсы. Каждый сервис добавляет хранилища кода или модули, цепочки развёртывания, учётные записи, панели показателей, оповещения, обновления, контракты, знания для дежурств и работу на всём протяжении жизненного цикла. Изменения: сравнивайте время от постановки задачи до выпуска, частоту развёртываний, долю неудачных изменений, скорость восстановления и ожидание между командами. Ответственность: сервис без постоянной команды становится бесхозным; монолит без закреплённой ответственности за модули превращается в общий ресурс, за который не отвечает никто. Архитектура должна делать ответственность понятнее, а не просто переносить её.

Выбирайте по ограничениям, а не по архитектурной моде

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

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

Проверьте готовность организации: надёжный CI/CD, автоматизацию инфраструктуры, управление секретами и учётными данными, проверку контрактов, централизованную телеметрию с распределённым отслеживанием, каталог сервисов, порядок управления инцидентами, планирование мощности, реагирование на угрозы и поддержку платформы. Это постоянные компетенции, а не разовый проект настройки. Используйте запись решения со взвешенными критериями: наблюдаемыми ограничениями, вариантами, последствиями, предположениями и условием пересмотра. «Когда-нибудь мы, возможно, вырастем» — предположение; измеренное исчерпание ресурсов или длительная блокировка команд — доказательство.

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

Выделяйте сервис, только когда польза от разделения оправдывает затраты

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

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

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

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

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

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

Проектируйте минимальную архитектуру, достаточную по имеющимся фактам

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

GARNO.TECH помогает командам проектировать новые системы, делить на модули существующие приложения и выделять сервисы, когда такой шаг подтверждён фактами. Работа может охватывать определение предметных областей, архитектурные решения, анализ зависимостей, контракты API и событий, разделение данных, инфраструктуру и CI/CD, наблюдаемость, устойчивость, последовательность миграции, критерии приёмки и передачу знаний внутренним командам.

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

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