Мы реализуем шаблон ASYN C SAGA, у нас есть путь, когда все идет нормально, и у нас также есть путь, если какая-либо из «зависимых» MS публикует ошибку (диаграмма счастливого пути компенсации SAGA). В сценарии, в котором ни одна из зависимых MS никогда не отвечает (диаграмма ошибок компенсации SAGA), у нас есть несколько альтернатив, но мы не уверены в лучшем выборе.
Событие заказа подразумевает 4 действия MS (или более), и одна из MS никогда не отвечает, мы думаем о запуске компенсации на основе:
Вариант A: MS1 имеет своего рода планировщик и проверяет, чтобы найти порядок в базе данных в состоянии PENDING, который был сохранен (например) 30 минут go. Если другой MS не отвечает успешно или с ошибкой в течение 30 минут, вероятно, произошла какая-либо ошибка, и мы запускаем процесс компенсации.
Вариант B: Один независимый демон, который выглядят так же, как в варианте A для элементов в БД, которые находятся в состоянии PENDING в течение более X (например, - 30 минут) минут.
Вариант C: Любые другие варианты?
Прилагаем две диаграммы последовательности:
ДИАГРАММА счастливого пути компенсации SAGA
ДИАГРАММА ошибки компенсации SAGA
ПРИМЕЧАНИЕ: MS 2, MS3, MS4 выполняют свою работу в параллельном процессе asyn c, идея состоит в том, чтобы сначала получить бизнес-событие, которое подразумевает 4 MS, MS1 проверяет сообщение и делегирует действия, требуемые другой MS, и не выполняет не дожидаясь, пока другой закончит свою работу, MS1 публикует sh событие заказа как действительное и освобождает ресурсы MS1, пока каждый другой не ответит на свой ответ о выполнении задания. MS1 получает (или не получает) подтверждение другой MS, и если каждая другая MS отвечает ОК, MS1 меняет статус заказа на CREATED.