✨ Монолит ⚔ Сервисы (SOA) ⚔ Микросервисы (MSA) ✨


👉 Архитектура

◽️ Монолит:
Один большой блок - единая кодовая база Backend.
Вся логика в одном месте.

🟡 SOA:
Отдельные сервисы с независимыми кодовыми базами.
Логика распределена.
В SOA сервисы крупные и многофункциональные, их можно назвать "микромонолитами".

💚 MSA:
Небольшие, автономные сервисы, каждый из которых отвечает за управление одной сущностью, процессом или задачей.
В MSA сервисы более узкоспециализированные по сравнению с SOA.

Сравнение сервисов в SOA и MSA на примерах:

🔹 Каталог товаров
SOA:
+ Сервис "Каталог" – управляет товарами, категориями, характеристиками, поиском и рекомендациями.
MSA:
+ Сервис управления товарами – добавляет, редактирует, удаляет товары
+ Сервис поиска – отвечает только за фильтрацию, поиск и выдачу результатов
+ Сервис рекомендаций – анализирует покупки пользователей и предлагает похожие товары

🔹 Корзина покупок
SOA:
+ Сервис "Корзина" – хранит товары пользователя, управляет ценами и скидками
MSA:
+ Сервис корзины – добавляет и удаляет товары.
+ Сервис расчёта цен – отдельно высчитывает итоговую сумму с учётом акций, налогов и доставки
+ Сервис промокодов и скидок – управляет купонами, скидками, программами лояльности



------------------

👉 База данных

◽️ Монолит:
Обычно одна на всю систему, но может быть и больше.

🟡 SOA:
Сервисы могут иметь общую БД или отдельные схемы внутри одной БД.

💚 MSA:
У каждого микросервиса своя БД.

Сравнение SOA и MSA:
Например, обновление платежного модуля в интернет-магазине с MSA не затронет каталог товаров, так как у них разные БД. В то время как в SOA архитектуре могут быть проблемы с обновлениями из-за наличия общей БД.



------------------

👉 Независимость, масштабируемость и отказоустойчивость

◽️ Монолит:
Если отказывает что-то в монолите, то он ломается целиком.
Релиз обновлений приводит к полной недоступности всего Backend.
Сложно масштабировать:
- постоянно надо добавлять новые мощности (память, ядра и другие) к существующему серверу при добавлении новых функций,
- если запущено несколько параллельно работающих копий монолита, то при росте пользователя, надо запускать новую дорогую копию.


🟡 SOA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса. Но могут быть сложности с отключением нескольких сервисов, когда выполняются обновления общих БД.
Можно масштабировать каждую БД и сервис по мере необходимости - т.е. если растет нагрузка на каталог товаров, то запустим больше копий только этого сервиса, а не всей системы.


💚 MSA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса, за счет собственной БД сложностей нет.
Можно масштабировать каждую БД и сервис по мере необходимости, как в SOA.



------------------

👉 Взаимодействие

◽️ Монолит:
+ внутреннее, через вызов процедур и функций в одном коде.


🟡💚 SOA и MSA:
+ напрямую по API (REST, gRPC и другие),
+ через шину данных ESB,
+ через API-сервисы, в том числе можно использовать API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.



------------------

Когда лучше монолит, когда SOA, а когда MSA?

Когда монолит?
✅ Если у вас стартап и ограниченный бюджет.
✅ Нет опытных специалистов и архитекторов, кто работал с MSA.
✅ Нужно сделать быстро и протестировать гипотезу.
✅ Нет высокой нагрузки – мало пользователей.

Когда SOA?
✅ Большая корпоративная система с интеграциями.
✅ Если в компании уже используется ESB.
✅ Не требуется высокая скорость изменений – SOA сложнее менять, так как сервисы могут зависеть от общей БД или централизованных решений.

Когда MSA?
✅ Нужна высокая скорость изменений и независимость команд.
✅ Нагрузка на отдельные функции распределена неравномерно – например, поиск товаров требует больше вычислительных мощностей, чем расчёт скидок.
✅ Отказоустойчивость критически важна.
✅ Частые релизы.


#АрхитектураGA