Архитектура ПО определяет проект задолго до первой строки кода. Ошибка в выборе дорого стоит позже; понимание вариантов делает выбор осознанным.
Шесть распространённых архитектур: что каждая даёт и чем за это платить.
1. Монолитная архитектура
Традиционная модель: интерфейс, бизнес-логика и доступ к данным живут в одном развёртываемом модуле.
- Плюсы: просто разрабатывать, тестировать и разворачивать; вызовы внутри процесса быстрые.
- Минусы: трудно масштабировать отдельные части; сопровождение растёт вместе с кодовой базой.
2. Микросервисная архитектура
Приложение делится на небольшие независимые сервисы, общающиеся через API. Каждый сервис отвечает за свою функцию и разворачивается и масштабируется отдельно.
- Плюсы: независимое масштабирование, гибкость технологий, изоляция отказов.
- Минусы: распределённая сложность, согласованность данных, сетевые накладные расходы.
3. Сервис-ориентированная архитектура (SOA)
Похожа на микросервисы, но сервисы крупнее и общаются через шину сообщений или брокер, а также переиспользуются между приложениями.
- Плюсы: переиспользование между проектами, стандартизированная интеграция.
- Минусы: нужна зрелая инфраструктура; шина добавляет задержку.
4. Событийно-ориентированная архитектура
Компоненты порождают, обнаруживают, потребляют и обрабатывают события - асинхронная обработка становится естественной.
- Плюсы: масштабируется добавлением обработчиков; слабая связанность.
- Минусы: сложность потоков событий, тяжелее отладка и согласованность.
5. Слоистая архитектура
Приложение делится на слои - представление, бизнес-логика, доступ к данным, - каждый отвечает за своё.
- Плюсы: чёткое разделение ответственности, слои развиваются независимо.
- Минусы: накладные расходы между слоями; изменения могут задевать несколько из них.
6. Микроядерная архитектура
Небольшое ядро даёт минимум функциональности, остальное приходит плагинами и расширениями.
- Плюсы: расширяемость без правок ядра; маленький и управляемый центр.
- Минусы: управление зависимостями плагинов; накладные расходы слоя расширений.
Как выбирать на практике
Начните с модульного монолита. Один деплой, явные границы модулей, своя схема у каждого модуля, никаких запросов в чужие таблицы в обход. Большинство продуктов живут так годами, а границы потом удешевляют выделение сервиса.
Выделяйте сервис, когда у модуля свой профиль нагрузки, свой темп релизов или своя зона отказа. Генератор PDF, который съедает процессор на каждой загрузке, подходит. Форма входа нет.
События берите, когда работа может идти после ответа: письма, выгрузки, биллинг, индексация поиска. Не делайте события основным транспортом для запроса и ответа, иначе год будете разбирать поток, который нельзя воспроизвести.
SOA нужна, когда несколько продуктов уже есть и должны делить общую шину. Микроядро подходит, когда ядро стабильно, а вариации живут в расширениях: CMS, IDE, браузер.
Чем выбор обходится после запуска
- Операционная нагрузка. Каждому деплою нужны логи, метрики, трейсинг, алерты и план отката. Пять сервисов означают пять комплектов.
- Согласованность данных. Транзакция через несколько сервисов превращается в сагу или таблицу исходящих, и кто-то должен отвечать за путь ошибки.
- Форма команды. Один сервис на команду работает. Один сервис на разработчика превращает каждый релиз в согласование.
- Найм и дежурства. Распределённые системы требуют людей, которые умеют их эксплуатировать в три часа ночи, а не только рисовать на доске.
Переход это норма
Архитектура не решается один раз. Модульный монолит, который перерос базу, сначала выделяет модуль с тяжёлым чтением. Парк микросервисов, который тонет в согласовании, укрупняют обратно. Полезный вопрос не в том, какой паттерн современный, а в том, какое изменение будет дешевле в следующем году.
Как выбирать архитектуру ПО
Паттерн микросервисов подробно разобран у Мартина Фаулера. Лучшей архитектуры не существует - есть подходящая под требования. Задайте три вопроса: какой масштаб нужен, как быстро будут меняться команда и продукт, сколько операционной сложности вы можете себе позволить?
Монолит - отличный ответ для небольшого продукта с неясным будущим. Микросервисы оправданы, когда независимое масштабирование и автономия команд перевешивают операционную цену. Событийная архитектура окупается, когда асинхронные потоки - ядро бизнеса. Ошибка не в выборе простой архитектуры, а в выборе модной, которую вы не можете эксплуатировать.
Понимайте компромиссы, начинайте с самого простого работающего решения и давайте архитектуре развиваться вместе с продуктом.
Как выбрать архитектуру ПО под задачу
Архитектура ПО выбирается по ограничениям: нагрузка, команда, скорость изменений, цена ошибки. Заметки Мартина Фаулера дают язык для такого разговора. Мода здесь плохой советчик.
Ещё по теме: Важность правильного нейминга в коде и Глубина SQL: один запрос вместо бэкенд-сервиса.