🦄 Микросервисная архитектура(MSA): погружение в детали 🦄

Микросервисная архитектура (MSA) – это эволюция сервис-ориентированной архитектуры (SOA), но более гибкая, независимая и масштабируемая.

Если монолит – это один большой блок,
а SOA – это несколько крупных сервисов,
то MSA – это сеть небольших сервисов, работающих как единая система.


Что такое микросервис (МС)?

▫️ Это небольшая, автономная служба, которая:
+ управляет данными одной сущности,
+ обслуживает строго один бизнес-процесс,
+ выполняет только одну простую функцию.
По сравнению с SOA, в MSA сервисы более узкоспециализированные и мЕньшие по размеру.

▫️ У каждого МС своя БД, API, кодовая база.

▫️ Каждый МС развернут на своём сервере, работает и релизится независимо от других.

▫️ МС не используют общую БД – каждая часть системы управляет своими данными.



👉 В МСА сервисы взаимодействуют между собой:
+ напрямую по API (REST, gRPC и другие),
+ через API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.


Набор МС для классического примера с Интернет-магазином:
🔹 Каталог товаров
🔹 Корзина
🔹 Заказы – получает данные из корзины и формирует заказ
🔹 Платежи
🔹 Управление скидками
🔹 Доставка
🔹 Уведомления (sms, email, push)
🔹 ЛК пользователей


👉 Плюсы MSA во многом совпадают с SOA:
✅ Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы
✅ Масштабируемость – можно увеличить нагрузку на конкретный сервис, не затрагивая всю систему
✅ Можно обновлять сервисы без даунтайма всей системы. А собственная БД гарантирует, что другие сервисы не будут затронуты
✅ Ошибки в одном сервисе не влияют на работу других
✅ Гибкость технологий


👉 Недостатки MSA:
❌ Сложность управления большим количеством сервисов. Мониторинг и логирование должны быть на высоком уровне, чтобы не терять сбои в отдельных частях системы
❌ Возможны задержки в работе из-за количества звеньев в цепочке обмена данными
❌ Нужна опытная команда


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