Монолит или микросервисы: что выбрать для нового веб-сервиса и почему не стоит переплачивать за архитектуру «на вырост»

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

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

Чем монолит отличается от микросервисов простыми словами?

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

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

Классическое определение дали в 2014 году Джеймс Льюис и Мартин Фаулер в статье «Microservices»: это стиль, при котором приложение строится как набор независимо разворачиваемых сервисов, каждый работает в своём процессе и организован вокруг бизнес-возможности — оплаты, каталога, уведомлений. Ключевое слово — «независимо»: смысл микросервисов в том, чтобы разные команды выпускали свои части, не дожидаясь друг друга.

Что в монолите, что в микросервисах есть одинаковые слои: интерфейс, который видит пользователь, серверная логика и база. Поэтому «у нас отдельно фронтенд и бэкенд» — это ещё не микросервисы. Сайт плюс API плюс база — обычный монолит с отдельной клиентской частью.

Что такое модульный монолит и почему с него разумно начинать?

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

Почему этот вариант разумен для старта:

• Границы ещё неизвестны. На старте никто точно не знает, какие части продукта станут главными. Мартин Фаулер в заметке «MonolithFirst» пишет, что почти все известные ему успешные микросервисные системы начинались как монолит, который вырос и был разделён, а системы, сразу построенные на микросервисах, часто попадали в серьёзные трудности. Передвинуть границу модуля внутри одного кода — работа на часы или дни, границу между сервисами — на недели.
• Скорость обратной связи. Первая версия нужна, чтобы проверить спрос. Каждая функция в монолите — одно изменение и одна выкладка, а не согласование нескольких сервисов.
• Одна база — честные данные. Заказ и оплата меняются в одной транзакции: не бывает «деньги списали, а заказ не создался», которое в распределённой системе приходится специально обрабатывать.
• Путь к разделению сохраняется. Если через пару лет модуль «отчёты» начнёт тормозить остальных, его выносят в отдельный сервис, и граница уже проведена.

Пример из наших работ — магазин AleksFurs: витрина, корзина, панель магазина и обмен с 1С работают одним приложением на Node.js с одной базой PostgreSQL. Поиск с опечатками сделан на индексе самой базы, без отдельного поискового движка, а медиана ответа страницы каталога в замере на боевом объёме — 12 мс. Отдельный сервис под поиск здесь добавил бы сервер и точку отказа, но не скорость.

	Монолит	Модульный монолит	Микросервисы
Как устроено	Одно приложение и одна база, код без чётких внутренних границ	Одно приложение и одна база, но код разбит на модули с правилами, кто к кому обращается	Несколько отдельных приложений, у каждого своя база или своя часть данных, общаются по сети
Стоимость первой версии	Минимальная	Почти как у монолита: время уходит на продуманную структуру, а не на инфраструктуру	Заметно выше: к самим функциям добавляются связи между сервисами, очереди, общая авторизация, мониторинг
Срок до запуска	Самый короткий	Сопоставим с монолитом	Дольше: каждую функцию приходится проводить через несколько сервисов
Хостинг	Один сервер, часто с базой на нём же	Один сервер или пара: приложение и база	Несколько серверов или кластер, отдельный сбор логов и мониторинг
Поддержка	Дёшево, пока код небольшой; дорожает, когда всё связано со всем	Дёшево: одна выкладка, одна база, понятные границы	Нужен человек, который следит за инфраструктурой, а не только за кодом
Риск	Через год-два превращается в «клубок», который страшно трогать	Требует дисциплины: границы модулей надо соблюдать	Ошибки в границах сервисов дорого исправлять, сбой одного звена ломает сценарий
Кому подходит	Прототипу, внутреннему инструменту на одну команду	MVP, SaaS и личным кабинетам, над которыми работают одна-две команды	Крупному продукту с несколькими командами и частями с разной нагрузкой

Что дороже: разработка, хостинг и поддержка?

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

Откуда берутся лишние затраты:

• Связи между сервисами. Каждый вызов по сети может упасть или задержаться. Нужны повторы, таймауты, очереди, проверка, что сообщение не обработали дважды.
• Общие вещи делаются несколько раз. Авторизация, логи, настройки, выкладка — для каждого сервиса.
• Инфраструктура. Несколько серверов или кластер, оркестратор, сбор логов и трассировка запросов, чтобы понять, где именно сломался сценарий.
• Тестирование. Проверить сквозной сценарий «заказ → оплата → письмо» можно, только подняв все участвующие сервисы.
• Люди. Кроме разработчиков нужен тот, кто отвечает за инфраструктуру. У монолита эту роль обычно закрывает тот же разработчик.

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

Когда монолит начинает мешать?

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

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

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

Как монолит масштабируют без деления на сервисы?

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

• Индексы и запросы. Первое, что проверяют при замедлении: какие запросы к базе выполняются дольше всего.
• Фоновые задачи. Письма, отчёты, импорт и обработка файлов выполняются отдельным процессом того же приложения, не задерживая ответ пользователю.
• Кэш. Каталог, справочники и тяжёлые подсчёты не пересчитываются при каждом открытии страницы.
• Несколько копий приложения. Если приложение не хранит состояние в памяти сервера, его запускают в двух-трёх экземплярах — это и запас по нагрузке, и выкладка без простоя.
• Отдельный сервер базы и файлов. База и хранилище файлов уезжают со своих ресурсов, приложение остаётся одним кодом.

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

Какие вопросы задать подрядчику об архитектуре?

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

1. Почему именно такая схема? Какая проблема моего сервиса требует микросервисов уже в первой версии?
2. Сколько серверов нужно на старте и сколько примерно стоит хостинг в месяц по текущим ценам провайдера?
3. Кто будет сопровождать инфраструктуру после запуска и входит ли это в поддержку?
4. Как устроены модули внутри и можно ли будет вынести часть в отдельный сервис без переписывания?
5. Как выглядит выкладка обновления: сколько шагов, есть ли тестовый стенд, будет ли простой?
6. Что будет, если упадёт одна часть системы — например, отправка писем или интеграция с 1С?
7. Смогу ли я передать проект другой команде: где лежат исходники, есть ли инструкция по запуску и развёртыванию?

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

Типичные ошибки при выборе архитектуры

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

• Микросервисы для MVP. Бюджет первой версии уходит на инфраструктуру, а не на функции, которые проверяют спрос.
• «Распределённый монолит». Сервисы формально отдельные, но выкладываются только вместе и ходят в одну базу. Сложность микросервисов есть, а их выгоды нет.
• Монолит без структуры. Всё связано со всем, любая правка задевает соседние разделы. Это не повод для микросервисов — это повод для рефакторинга и границ модулей.
• Деление по техническим слоям. Отдельный «сервис базы», «сервис API», «сервис интерфейса» — не микросервисы, а тот же монолит, разрезанный поперёк.
• Переписать всё сразу. Вместо постепенного выноса одной проблемной части команда месяцами строит новую систему параллельно со старой.
• Архитектура «как у крупных компаний». У них сотни разработчиков и свои платформенные команды — у сервиса на несколько тысяч клиентов этих задач нет.

Когда микросервисы действительно нужны с самого начала?

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

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

Как мы выбираем архитектуру и сколько это стоит?

Архитектуру мы не продаём отдельной строкой: она часть проектирования на этапе брифа и ТЗ. По умолчанию предлагаем модульный монолит, отдельные сервисы — только там, где есть причина, и объясняем её в ТЗ. Веб-приложение или SaaS по прайсу — от 160 000 ₽ и от 10 дней.

Что входит в работу по заказной разработке, если говорить об архитектуре:

• схема базы данных и границы модулей согласуются вместе с прототипом экранов, до сборки;
• исходный код фронтенда и бэкенда — в вашем Git-репозитории, доступы к серверу и базе — у вас, плюс инструкция по запуску и развёртыванию;
• до 2 раундов правок на прототипе и до 2 на готовой сборке, 14 дней поддержки после запуска и гарантия по договору 30 календарных дней с даты акта;
• дальше — развитие итерациями: поддержка от 7 900 ₽ в месяц или разово по задачам.

Если сервис уже работает и вы не уверены, что его архитектура выдержит следующий год, начните с разбора: посмотрим код, нагрузку и планы и скажем, достаточно ли навести порядок внутри или пора выносить часть в отдельный сервис. Как в целом устроен многопользовательский сервис, мы описали в статье про устройство SaaS, а как сузить первую версию — в материале «MVP или полная версия».

Короткие ответы на частые вопросы

Что такое монолит в разработке простыми словами?

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

Чем модульный монолит отличается от обычного?

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

Выдержит ли монолит рост пользователей?

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

Можно ли потом перейти с монолита на микросервисы?

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

Нужно ли заказчику разбираться в архитектуре?

Глубоко — нет. Но стоит задать подрядчику несколько вопросов: почему выбрана такая схема, сколько серверов она требует, сколько стоит поддержка и как её будут менять при росте. Ответы покажут, думали ли о вашем бюджете.

Услуги и кейсы по теме: заказная разработка · кейс AleksFurs · цены и сроки