Монолит vs микросервисы: что выбрать веб-студии для разработки ПО

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

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

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

Коротко: какой вариант выбирать

• Один продукт и одна команда - основание рассматривать модульный монолит первым: у него один основной контур сборки, развертывания и отката.
• Для условного проекта на 600 часов разработки переход к 4-6 сервисам может добавить 180-360 часов на инфраструктуру и распределенные взаимодействия.
• Микросервисы полезны, если хотя бы 1 компонент имеет подтвержденную потребность в независимом выпуске или существенно иной профиль нагрузки.
• Отдельные процессы не дают автоматической отказоустойчивости: нужны тайм-ауты, ограниченные повторы, наблюдаемость и проверенное восстановление.
• Перед разделением системы измеряйте 3 показателя: время выпуска, стоимость эксплуатации и долю изменений, затрагивающих несколько модулей.

Чем отличаются монолит, модули и отдельные сервисы

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

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

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

Размер репозитория не определяет архитектуру: 1 репозиторий может содержать несколько независимо выпускаемых сервисов. И наоборот, несколько репозиториев не устраняют связанность, если любое изменение требует синхронной доработки всех приложений.

Сколько стоят разработка и первый год поддержки

Самая дорогая граница иногда выглядит как короткая стрелка на схеме. Для сравнения возьмем B2B-кабинет с каталогом, заказами, платежным провайдером и уведомлениями; команда - 5 человек, ставка - 3 000 рублей за час. Базовые 600 часов включают одинаковый функциональный объем и обычное тестирование во всех вариантах.

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

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

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

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

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

Основание для выделения сервиса - измеримая проблема конкретного компонента. Например, обработчик изображений потребляет 70% процессорного времени приложения в часы массовой загрузки, а каталог почти не меняется. Отдельный обработчик позволяет масштабировать эту работу без копирования всего приложения; процент здесь иллюстрирует сценарий, который нужно подтвердить профилированием.

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

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

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

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

Какие риски поддержки появляются после разделения

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

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

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

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

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

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

Алексей Миронов - условный архитектор команды сопровождения; редакционная экспертная персона LuxeSite, а не цитата реального специалиста.

Как проверить выбор за 10 рабочих дней

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

1. Дни 1-2: описать границы каталога, заказов и платежей; указать владельцев данных и операции, требующие атомарности.
2. Дни 3-4: собрать вертикальный прототип одного заказа от запроса пользователя до подтверждения результата.
3. Дни 5-6: проверить ожидаемую нагрузку и один повышенный режим; записать p95 времени ответа, ошибки и потребление ресурсов.
4. Дни 7-8: воспроизвести тайм-аут, повтор события и перезапуск; проверить отсутствие повторного списания и потерянного заказа.
5. Дни 9-10: выполнить выпуск и откат, составить смету сопровождения и зафиксировать архитектурное решение.

В протоколе нужно разделять цели и измерения. «p95 не выше 500 мс при 50 запросах в секунду» - пример проверяемой цели для выбранного маршрута, а не обещание производительности любого монолита. Результат имеет смысл только вместе с характеристиками окружения, объемом данных и составом запросов.

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

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

Как развивать монолит без дорогой переписи

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

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

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

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

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

Частые вопросы

Что выбрать веб-студии для разработки MVP: монолит или микросервисы?

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

Во сколько микросервисы обходятся дороже монолита?

В редакционной модели проекта на 600 базовых часов вариант с 4-6 сервисами добавляет 360-720 тысяч рублей к первому выпуску относительно модульного монолита. Расчет использует ставку 3 000 рублей за час. Реальная разница зависит от готовности инфраструктуры, опыта команды и требований к восстановлению.

Можно ли масштабировать монолит без перехода на микросервисы?

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

Когда пора выделять первый микросервис?

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

Нужен ли Kubernetes для микросервисов?

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

Как избежать распределенного монолита?

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

Источники

Для проверки технических принципов полезны 4 источника ниже. Денежные диапазоны в статье рассчитаны по редакционным допущениям и не приписываются этим публикациям.

• Martin Fowler - MonolithFirst: условия выбора монолита на раннем этапе продукта.
• Microsoft Azure Architecture Center - Microservices architecture style: независимость сервисов и эксплуатационные компромиссы.
• AWS Prescriptive Guidance - Transactional outbox pattern: согласование записи данных и публикации событий.
• OpenTelemetry Documentation - Signals: трассировки, метрики и логи распределенных приложений.

Что зафиксировать перед началом разработки

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

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