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

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

Чем отличаются три подхода

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

Важно различать границы кода и границы запуска. Можно улучшить структуру проекта, не создавая сеть из сервисов. Microsoft показывает варианты организации обычного приложения в обзоре веб-архитектур.

Как архитектура влияет на повседневную работу

Вопрос	Модульный монолит	Микросервисы
Как выходит изменение?	Обычно выпускается всё приложение	Сервис может выпускаться отдельно, если контракт совместим
Где искать сбой?	Чаще в одном процессе и его зависимостях	В нескольких службах и соединениях между ними
Как менять данные?	Локальная транзакция часто доступна напрямую	Изменения разных владельцев данных требуют координации
Как увеличивать мощность?	Масштабируется приложение или его отдельные процессы	Можно отдельно масштабировать нужный сервис
Что нужно для эксплуатации?	Один понятный контур выпуска и наблюдения	Несколько контуров, общие правила диагностики и взаимодействия

Когда одного приложения достаточно

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

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

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

Когда выделение сервиса оправдано

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

Возможность независимо выпускать и масштабировать сервисы — одно из преимуществ подхода. Цена этой независимости — сложность связи, согласованность данных и эксплуатация распределённой системы. Эти компромиссы описаны в руководстве Microsoft по микросервисам.

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

Что меняется, когда появляется сеть

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

Повторять любую операцию автоматически опасно: можно создать два заказа или два списания. Для повторяемых запросов проектируют идемпотентность — повтор с тем же идентификатором не создаёт дополнительный результат. Практический разбор даёт AWS Builders’ Library.

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

Почему общая база может сохранить тесную связь

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

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

Как переходить постепенно

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

Постепенное вынесение функций вместо одномоментной переписи рассматривается в паттерне Strangler Fig. Для конкретного проекта путь миграции зависит от данных, контрактов и допустимого простоя.

Что обсудить с подрядчиком

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

Выбор языка — отдельный вопрос: монолит можно написать на Go, Node.js или Python, как и отдельный сервис. Сценарии выбора разобраны в статье о серверных технологиях. Если система уже работает, начните с проверки инфраструктуры и текущих ограничений. Обсудим задачу и состав изменений, которые можно проверить на рабочих сценариях.