Есть 32 микросервиса.
Сейчас все работает в 1 запрос (клиент запрашивает информацию, она собирается на разных сервисах, иногда- что-то сохранятся в бд в какой-то из цепочки сервисов) и возвращаеться пользователю через адаптер (чтоб все данные были в 1-м формате).

Однако: начальству пришло в голову запедалить взаимодействия между микросервисами через rabbitMQ (стабильность, надежность, и, если что-то умрет - можно легко отследить и продолжить с того сервиса, где умерло). Идея неплоха - юзеру сразу возвращаться то, что может нагенерировать сервис, на который он обращается. А потом он сможет вытащить все остальные данные. Но: у меня ощущение, что мы столкнемся с адом очередей. Основная проблема: если наш сервис обращается к десятку других сервисов посредством RabbitMQ через NotificationServices, но, внезапно, Notification Service внезапно умирает (по каким-то причинам), надо как-то откатить изменения.

Кто-то вообще с подобным сталкивался? Как это лаконично можно сделать?

Santehnick
Дело в том, что, при чтении данных, формируется периодически документ (это для примера), который надо передать юзеру.

Выйдет очень много всякого хлама в redis тогда.

Ну, тут сорян - это и имел ввиду. Т.е. если возникла ошибка далее по сервисам, то нужно будет уведомить все сервисы, которые были уже уведомлены о предыдущем изменении), чтоб он удалили\изменили данные обратно.

Ну, про это я в курсе.

А чего так? Кроме сложности в отладке тяжело найти объективную причину, почему микросервисы - плохо. Ведь сервисы не большие. Удобно модифицировать любой сервис в отдельности

Santehnick
Во! Огромное спасибо

Про saga не слышал, но задача похоже подходит для чего то типа state machine.
На самом деле сходу видно несколько реализаций, но вся сложность в деталях.
Не уверен что rabbitMQ хорошо впишется. Точнее не понятно между чем вы его хотите вкорячить.

Если это один централизованный сервис очередей для всех сервисов, тогда там перемешаются все типы запросов от всех клиентов и ты никогда не найдёшь оптимальное количество обработчиков. Либо будут задержки, либо нагрузка. На мой взгляд.

Если rabbitMQ только для мастер-сервиса.
Мастер-сервис ставит задачу, обработчик после выполнения задачи дёргает мастер-сервис со статусом от микро-сервиса, мастер-сервис либо ставит следующую задачу, либо отменяет операцию в зависимости от статуса. Тут вроде всё красиво, но если rabbitMQ потеряет данные каким то образом, то кто дёрнит мастера что бы он закончил операцию? Нужно какое то дополнительное хранилище текущих статусов, что бы восстановить очередь.

Если rabbitMQ у всех сервисов включая мастера, то тут сходу несколько вариантов.
Мастер ставит задачи в rabbitMQ микро-сервисам, микро-сервисы ставят задачи в rabbitMQ мастеру. Тут даже думать не хочу как всё запутанно)
Или мастер ставит задачи в rabbitMQ микро-сервисам, а в свой rabbitMQ ставит задачи чекать микро-сервисы. Ну тут как минимум лишние запросы на проверку.

Я думаю тут куча таких вариаций со своими подводными камнями. С горяча не стоит приступать к реализации. Хотя как показывается практика самое лучшее решение - самое простое.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Arh

Santehnick
Благодарю. Надо будет глянуть

Zzepish

Arh
Ну, это и имел ввиду