Архитектура приложения: монолит, микросервисы и что выбрать

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

Монолит

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

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

Модульный монолит

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

Микросервисы

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

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

Serverless и управляемые сервисы

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

Критерии выбора

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

Слои внутри приложения

Независимо от выбора, внутри полезно разделять слои: представление (API, интерфейс), бизнес-логика, доступ к данным, интеграции. Бизнес-правила не должны зависеть от того, откуда пришёл запрос — с сайта, из бота или мобильного приложения. Тогда новый канал подключается без дублирования логики.

Признаки, что архитектуру пора менять

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

Как менять без остановки бизнеса

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

Что зафиксировать в документах

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