На этой неделе опубликовала подробный гайд по API Gateway.
Теперь показываю первую версию схемы архитектуры для проекта доставки еды #FoodDeliveryGA.
На ней вы можете увидеть, что все Frontend-приложения ходят к Backend через API Gateway, а уже за ним целый зоопарк микросервисов.
И вот тут начинают всплывать интересные вопросы...
Как реализовывать сложные процессы, в которых нужно несколько микросервисов?
🔎 Представим типичный сценарий - успешная оплата заказа
После того как платёж прошёл на сервисе платежей, система должна:
1. На Сервисе Заказов поменять статус заказа на «оплачен»
2. Отправить уведомление ресторану о новом заказе - сервис Уведомлений
3. Отправить уведомление пользователю, что заказ оплачен и ушёл в работу - сервис Уведомлений
4. На сервис курьеров отправить запрос на поиск курьера и завершить процесс обработки платежа, не дожидаясь нахождения курьера
5. После всех этих действий показываем пользователю экран "оплачено" на frontend
Если у нас есть только API Gateway:
👉 Либо все микросервисы начинают общаться между собой через него - точка отказа будет знатная
👉 Либо разрешаем микросервисам вызывать друг-друга напрямую
Звучит нормально… до первой диаграммы с прямыми интеграциями, когда появится паутина стрелок в дополнение к существующим 🕸️
Такую схему сложно не только читать, но и поддерживать в реальном проекте. Любое изменение бизнес-процесса = новая порция хаоса в связях между сервисами
👉 Либо мы можем добавить внутренний API Gateway Internal для взаимодействий между сервисами. Но в бизнес-процессах есть фоновые (асинхронные) задачи, параллельность, необходимость откатов и повторных попыток в случае ошибок. API Gateway не должен управлять логикой процессов, это не его функция
Поэтому в микросервисной архитектуре обычно сочетают подходы:
API Gateway + Хореография и/или Оркестрация
Их мы будем подробно разбирать на следующей неделе 🤝
#АрхитектураGA