🔆 Пример схемы архитектуры с микросервисами 🔆

Когда мы делим монолит на микросервисы, то процесс обмена данными в проекте усложняется. Другими словами: алгоритмы усложняются и простые Use Case становятся интеграционными.


1️⃣ В монолите взаимодействие разных логических частей в одном месте и API нужны только для UI, чтобы получать данные с сервера и отображать на экранах пользователей.

В микросервисах дополнительно нужны API для внутренних взаимодействий между ними. У каждого микросервиса свой API.

Для внутренних взаимодействий часто выбирают gRPC / GraphQL, оставляя для UI и других взаимодействий за пределами сервера популярный REST API.


2️⃣ Нужно выбрать подход к взаимодействию сервисов и микросервисов в проекте. Основные:

✔️ API-Gateway: единая точка входа для всех запросов от клиентов, направляет их к соответствующим микросервисам

✔️ Хореография: сервисы обмениваются событиями напрямую, принимая решения на основе полученных событий

✔️ Оркестрация: один сервис (оркестратор) управляет вызовами к другим сервисам, контролируя весь процесс выполнения задачи

✔️ Шина данных (Enterprise Service Bus, обычно для SOA): направляет сообщения между сервисами, преобразует данные и выполняет оркестрацию процессов

✔️ Очереди сообщений, как Kafka и RabbitMQ: для асинхронного взаимодействия и гарантии доставки и их обработки сервисами

Без подхода - будет паутина связей. Да и с ним тоже, честно говоря



👉 На картинке к посту:

🔸 Выбран подход с API-Gateway
Просто предствьте что будет, если убрать эти три API-Gateway в левой части. Когда приложения с UI будут сами выбирать какой микросервис вызывать и вызывать их API напрямую 🥲

🔸 Некоторые сервисы взаимодействуют напрямую
На схему можно добавить оркестратор, чтобы избежать этого


❗️Эта реализация - общий вид, черновик. Далее нужно добавлять БД, выбирать API, делать вычитку требований и описание процессов, чтобы проверить взаимодействия. Делать C4.

Cхема показывает:
- МСА это не сложно, но трудоемко
- Чем меньше МС, тем лучше и проще 😃

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