В чём отличие монолитной архитектуры от микросервисной? Какие плюсы и минусы каждого подхода?

Монолитная vs Микросервисная архитектура

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

Монолитная архитектура

Определение

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

Монолитное приложение:

┌─────────────────────────────────┐
│        Single Process            │
├─────────────────────────────────┤
│ ┌──────────────────────────────┐ │
│ │      User Service           │ │
│ ├──────────────────────────────┤ │
│ │      Order Service          │ │
│ ├──────────────────────────────┤ │
│ │      Payment Service        │ │
│ ├──────────────────────────────┤ │
│ │      Inventory Service      │ │
│ └──────────────────────────────┘ │
│                                 │
│      Shared Database (1 БД)     │
└─────────────────────────────────┘

Плюсы монолитной архитектуры

Простота разработки — для маленьких команд и проектов монолит проще

• Все в одной кодовой базе
• Одна build система
• Простое локальное развитие

Производительность — нет сетевых задержек

• Прямые вызовы функций между компонентами
• Нет HTTP overhead
• Транзакции ACID для данных

Простое развёртывание — для маленьких систем

• Один Docker контейнер
• Один процесс запуска
• Простое масштабирование (просто копируем приложение)

Мониторинг и отладка — проще отслеживать

• One place для логов
• Single error trace
• Полный контекст операции

Сбор данных ACID транзакции — если всё в одной БД

• Гарантированная консистентность
• Rollback при ошибках

Простая локальная разработка — разработчик может запустить локально

• Вся система на ноутбуке
• Нет зависимостей от других сервисов
• Быстрый feedback loop

Минусы монолитной архитектуры

Масштабируемость — сложно масштабировать отдельные части

• Приходится масштабировать всё целиком
• Дорогостоящее масштабирование (нужна большая машина)
• Нельзя оптимизировать отдельный компонент
• Пример: нужна масштабируемость только Payment service, но приходится масштабировать всё

Развитие и deployment — изменение одной части требует деплоя всей системы

• Нельзя деплоить отдельные части
• Риск: ошибка в Feature A ломает Feature B
• Deployment downtime для всей системы
• Медленный release cycle

Технологический выбор — заблокирован одним стеком

• Весь код на одном языке (Java, Python, Node.js)
• Нельзя использовать оптимальную технологию для задачи
• Сложно обновляться на новую версию (требует деплоя всей системы)

Сложность кода — со временем код становится очень сложным

• Разбухший codebase
• Сложные зависимости между компонентами
• Сложно нанимать и обучать разработчиков
• Сложно найти багу

Отказоустойчивость — отказ одного компонента может сломать всю систему

• Один баг в User Service → вся система падает
• Memory leak в одном сервисе → весь монолит используется полностью

Отказ от функционала — нельзя отключить ненужный функционал

• Если Payment Service не используется, он всё равно в памяти
• Все данные в одной БД

Команда bottleneck — большие команды конфликтуют -많은 разработчиков → merge conflicts

• Много веток → сложно mergeить
• Синхронизация требирует координации

Микросервисная архитектура

Определение

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

Микросервисная архитектура:

┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ User Service │  │ Order Service│  │Payment Service│  │InventoryServ│
├──────────────┤  ├──────────────┤  ├──────────────┤  ├──────────────┤
│  UserDB      │  │  OrderDB     │  │  PaymentDB   │  │InventoryDB   │
└──────────────┘  └──────────────┘  └──────────────┘  └──────────────┘
       │                  │                  │                │
       └──────────────────┼──────────────────┼────────────────┘
                    API Gateway / Message Bus

Плюсы микросервисной архитектуры

Независимое масштабирование — каждый сервис масштабируется отдельно

• Payment service медленный? Масштабируем только его
• User service не требует масштабирования? Не масштабируем
• Экономия ресурсов

Независимое развитие и деплойменты — каждая команда может деплоить отдельно

• Нет зависимостей от других команд
• Быстрый deployment (только одного сервиса)
• Нет downtime всей системы
• Быстрый release cycle (несколько раз в день)

Технологическая свобода — каждый сервис может использовать свою технологию

• User Service на Node.js, Payment на Java, Analytics на Python
• Можно обновлять отдельные сервисы
• Выбираем оптимальную технологию для каждой задачи

Простота понимания — каждый сервис маленький и понятный

• Сфокусированная ответственность
• Легче нанимать (специалист по Payment может писать только Payment service)
• Легче найти баг (ошибка локализована)

Отказоустойчивость — отказ одного сервиса не ломает всю систему

• Payment service упал → остальные работают
• Can gracefully degrade (например, выключить отзывы если Rating service упал)
• Better resilience patterns (circuit breaker, timeout, retry)

Масштабирование команды — большие команды могут работать параллельно

• Разные команды → разные сервисы
• Нет merge conflicts
• Independent deployment
• Two-pizza teams (маленькие команды)

Data locality — каждый сервис может optimizировать свои данные

• Payment может использовать SQL (ACID важна)
• Analytics может использовать NoSQL (нужна скорость)
• User может кешировать в Redis

Минусы микросервисной архитектуры

Сложность операций — значительно сложнее управлять и мониторить

• Десятки или сотни сервисов
• Нужны логирование, мониторинг, трейсинг через все сервисы
• Distributed debugging сложнее
• Требуется obsevability (logging, metrics, traces)

Сетевые задержки — вызовы между сервисами медленнее

• HTTP roundtrips
• Network latency
• Может быть медленнее чем прямые вызовы функций
• Требует кеширования

Консистентность данных — сложнее гарантировать ACID

• Распределённые транзакции
• Eventual consistency
• Саги и компенсирующие транзакции
• Сложная логика

Операционная сложность — требуется более зрелая инфраструктура

• Kubernetes или Docker Swarm
• Service mesh (Istio, Linkerd)
• Distributed tracing (Jaeger, Zipkin)
• Centralized logging (ELK, Splunk)
• Message queue (RabbitMQ, Kafka)

Развёртывание — нужна автоматизация

• Нельзя деплоить вручную (слишком много сервисов)
• Нужен CI/CD pipeline
• Нужна инфраструктура и DevOps опыт
• Требуется orchestration

Testing сложнее — нужно тестировать интеграцию сервисов

• Unit tests (для каждого сервиса)
• Integration tests (между сервисами)
• Contract testing
• E2E tests (через всю систему)
• Больше тестов = медленнее разработка

Разработка локально сложнее — нельзя просто запустить всё на ноутбуке

• Нужны Docker и Docker Compose
• Нужно запустить 10+ сервисов
• Медленнее, чем монолит
• Требует большей вычислительной мощности

Сетевая безопасность — больше поверхность атаки

• Больше endpoints
• Inter-service communication нужно защищать
• mTLS, API keys, OAuth
• Более сложная security архитектура

Сложность для маленьких команд — может быть overkill

• Нужно 10+ людей для управления
• Для маленькой team (2-3 человека) слишком сложно

Сравнение таблица

Когда выбрать монолит?

✓ Маленький проект или MVP — нужно быстро запустить ✓ Маленькая команда (1-5 разработчиков) — не нужна сложность микросервисов ✓ Простой домен — мало интеграций ✓ Высокие требования к performance — нужны прямые вызовы ✓ Ранняя стадия — требования еще не ясны ✓ Limited DevOps — нет инфраструктуры для микросервисов ✓ ACID транзакции критичны — нужна распределённая транзакция ✓ Real-time requirement — нет место для network latency

Когда выбрать микросервисы?

✓ Большая система — много функционала ✓ Большая команда (10+ разработчиков) — разные teams для разных сервисов ✓ Независимое масштабирование — разные компоненты растут по-разному ✓ Быстрый deployment — каждая команда может деплоить независимо ✓ Разные технологии — оптимальный выбор для каждого компонента ✓ Зрелая инфраструктура — Kubernetes, Istio, LogAggregation ✓ Отказоустойчивость критична — нужна graceful degradation ✓ Eventually consistent ok — не требуется ACID везде ✓ Two-pizza teams — независимые маленькие teams

Гибридный подход

Modular monolith — промежуточное решение

• Один монолит, но с четкими модулями
• Каждый модуль может быть извлечен в микросервис позже
• Лучшее из обоих миров на начальном этапе

Strangler Fig pattern — постепенная миграция

• Начать с монолита
• Постепенно извлекать части в микросервисы
• API Gateway в front
• Мигрировать функционал по частям

Вывод

Нет идеального выбора — только оптимальный для вашей ситуации:

• Монолит: для маленьких систем и команд, требует меньше инфраструктуры
• Микросервисы: для больших систем и команд, требует зрелой инфраструктуры

Системный аналитик должен понимать trade-offs и рекомендовать подход на основе requirements, team size, и infrastructure readiness.