Наш текущий проект основан на архитектуре микросервисов. Пока все хорошо, но мы начали подходить к тому, чтобы сохранить все из них в согласованном состоянии с точки зрения данных.Сохранение данных микросервисов
В основном мы разбиваем их согласно нашим основным сущностям в решении. Эти объекты могут работать независимо достаточно хорошо, но между ними все еще есть некоторые зависимости, которые включают обновление набора микросервисов, когда объект из другого микросервиса модифицируется.
Мы попытались решить эту проблему на разных маршрутах. Сначала мы решили, что rabbitmq является хорошим решением для этой проблемы: микросервис отправляет сообщение с информацией об изменении на обмен, который передает его в очередь потребляющих микросервисов. Что-то вроде этого:
кажется хорошим решением, но мы немного беспокоится о целостности данных, если возникает ошибка в каком-либо из потребителей: нам нужно было бы реализовать стратегию возвращаясь назад эти изменения во всех потребляющих микросервисах. Также рассматривали технологию без посредников, такую как ZeroMq, которая могла бы сделать тот же трюк, не имея узкого места брокера.
Мы также думали о реализации masstransit маршрутизации проскальзывания как о возможном решении, поэтому мы могли бы скомпенсировать все эти ошибки простым способом, но мы не очень любим иметь последовательный набор действий, потребляющих эти изменения. Мы скорее придерживаемся того же подхода, который мы получили на rabbitmq, где потребители работают более параллельно.
Итак, прямо сейчас мы находимся в тупике, и нам было интересно, какие другие разработчики выбрали в качестве решения этой проблемы. Мы не отказываемся от других технологий, если они решат эту проблему.
Если многие объекты должны применять действие или вообще не иметь ничего, если один из них не работает, тогда у вас есть консенсусная проблема, и вы должны искать библиотеку/систему, которая решает это. –