Микросервисы vs Монолит

О "монолитах"

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

Преимущества

1. Проще разрабатывать. Все компоненты находятся в одном месте. Легче отслеживать выполнение всего цикла запроса. Легче настраивать среду разработки
2. Выше производительность (обычно). Отсутствуют сетевые вызовы между компонентами. Меньше задержка при обработке запросов.
3. Проще развертывание. Один “артефакт” для развертывания. Упрощенный CI/CD. Легче управлять версионированием.
4. Целостность данных. Мутации данных происходят в рамках всей системы. Проще обеспечить ACID-принципы для транзакций (объединенных операций, которые должны быть выполнены как одна). Единая база данных (обычно).

Недостатки 

1. Не эффективное и сложное масштабирование. Ресурсы тратятся на дублирование всех функций, даже если требуется масштабировать только одну. Сложности с горизонтальным масштабированием (из-за хранения состояния сессий, только одной БД и т.д.)
2. Технологические ограничения. Привязка к одному технологическому стеку. Сложность внедрения новых технологий (переход одного модуля требует изменения во всем приложении). Риск технологического устаревания.
3. Ограничение размера команды. Чем больше команда, тем выше вероятность, что несколько человек будут менять одни и те же файлы или модули одновременно). 
4. Риск конфликтов в коде. Из-за тесной связанности компонентов изменения в одной части приложения могут неожиданно повлиять на другие части.
5. Сложные циклы тестирования и развертывания. Ошибки, допущенные в одной части, могут привести к сбоям во всём приложении.

Пример "Монолита":

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

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

Преимущества

1. Независимое масштабирование. Масштабирование только нужных компонентов. Оптимальное использование ресурсов. Гибкость в выборе инфраструктуры.
2. Технологическое разнообразие. Разные технологии для разных сервисов. Возможность экспериментировать с новыми решениями. Постепенная модернизация системы.
3. Автономные команды разработки. Каждая команда работает над своим сервисом и не влияет на другой.
4. Быстрые циклы разработки и развертывания. Микросервисы проще релизить из-за их размеров и простоты тестирования (например, полного регресса). 
5. Отказоустойчивость. Изоляция отказов. Продолжение работы при сбое отдельных компонентов. Легче реализовать паттерны отказоустойчивости.

Недостатки

1. Новые классы проблем. Появляются риски потери сообщений, дублирования, таймаутов, частичной недоступности сервисов.
2. Требовательность к архитектуре и инфраструктуре. Требуется реализовать механизмы балансировки нагрузки, маршрутизации запросов, обработки ошибок, повторных запросов и т.д.
3. Кросс-сервисные ошибки. Ошибки могут возникать при взаимодействии нескольких сервисов, что затрудняет их воспроизведение и поиск причин.
4. Нагрузка на сеть. Каждый вызов между сервисами — это сетевой запрос, который медленнее, подвержен задержкам, может быть потерян или дублирован.
5. Мониторинг множества сервисов. Требуется централизованный мониторинг, алертинг, логирование, чтобы быстро выявлять и устранять проблемы.
6. Сложность развертывания и управления. Необходимо автоматизировать CI/CD, управлять версиями API, следить за совместимостью сервисов.
7. Необходимость в продвинутых DevOps практиках. Необходима работа с контейнеризацией, оркестрацией и облачными платформами.
8. Сложности с транзакциями. В микросервисах данные распределены по разным сервисам и базам, классические транзакции сложны.
9. Eventual consistency. Данные между сервисами могут быть не синхронизированы мгновенно, а только через некоторое время, необходимость в различных паттернах управления транзакциями и проч. 

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

Критерии выбора типа архитектуры

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

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

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

• Большие команды 
• Четко выделяемые бизнес-контексты
• Разные компоненты имеют разные нагрузки
• Необходимы разные технологии
• Развиты DevOps практики
• Требуется высокая отказоустойчивость
• Планируется быстрый рост и масштабирование
• Частые изменения и независимые релизы
• Много интеграций с внешними системами
• Долгосрочный проект

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

• Модульный монолит (Четкие модульные границы внутри монолита)
• Macroservices (Сервисы крупнее микросервисов, но меньше монолита)

Вертикальное масштабирование - увеличение ресурсов одного сервера: добавление процессоров (CPU), оперативной памяти (RAM), дискового пространства и т.д

Горизонтальное масштабирование - добавление новых серверов (экземпляров, узлов) и распределение нагрузки через балансировщик.

От монолита к микросервисам

1. Strangler Fig Pattern (Паттерн «удушающего дерева»). Новая функциональность реализуется как отдельные микросервисы, а не добавляется в монолит. Постепенно старые части монолита заменяются новыми сервисами. В какой-то момент монолит полностью «задушен» и может быть удалён.

Как реализовать:

• Вводится слой маршрутизации (например, API Gateway или прокси), который направляет запросы либо в монолит, либо в новые микросервисы
• Новые фичи сразу реализуются как микросервисы
• Старые компоненты постепенно переписываются и выносятся в отдельные сервисы
• После переноса всех функций монолит можно выключить

2. Database-per-Service. В монолите обычно используется одна общая база данных для всех модулей. В микросервисной архитектуре каждый сервис должен владеть своими данными и иметь отдельную базу данных.

Как реализовать:

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

3. API Gateway. Единая точка входа для всех внешних клиентов в микросервисную систему. 

• API Gateway может собирать данные из нескольких микросервисов и возвращать клиенту единый ответ
• Может преобразовывать протоколы (например, REST ↔ gRPC), форматировать ответы, фильтровать поля
• Скрывает внутреннюю структуру микросервисов от клиентов и позволяет централизованно управлять безопасностью и политиками доступа

Как реализовать:

• API Gateway разворачивается как отдельный сервис между внешними клиентами и внутренними микросервисами
• Все внешние запросы (от мобильных приложений, веб-клиентов, партнеров) направляются сначала на шлюз
• В шлюзе настраиваются правила маршрутизации: какой путь (endpoint) или метод должен быть направлен в какой микросервис