В микросервисной архитектуре принято считать, что каждый микросервис должен иметь свою собственную реплику от другого "основного" микросервиса, выступающего в качестве единого источника истины. Это позволяет поддерживать автономность и свободное взаимодействие микросервисов.
Когда "главный" микросервис изменяется, он издает некоторые события, чтобы заинтересованные микросервисы обновляли свои реплики и синхронизировались. Используя брокер с постоянными очередями, мы можем "вполне" гарантировать, что никакие события не потеряются и реплики будут обновляться.
Но "вполне" - это не 100%, и все еще есть другие способы рассинхронизации:
Как вы решили эти проблемы на своих реализациях? Я где-то видел концепцию "согласования", но не нашел ни одной реализации этой концепции.
Большое спасибо!
Однако необходимость воспроизводить прошедшие или пропущенные события, чтобы наверстать упущенное, является распространенной проблемой в системах, управляемых событиями.
Решение 1.
Добавьте API "Получить прошедшие события" в дополнение к push-сообщениям. Это позволит наверстать упущенное, проверить пропущенные сообщения и другие сценарии. Это не совсем антишаблон, если только вы не вынуждены использовать его настолько часто, что, по сути, признаете, что push-сообщениям нельзя доверять.
Я думаю, что довольно распространено добавление такого интерфейса и какого-то задания проверки/синхронизации, которое проверяет всю систему по расписанию. Например, у вас есть задания, которые не перешли в ожидаемый SLA, это может быть связано с пропущенным или ошибочным сообщением, вы можете захотеть опросить пропущенные сообщения на этих отложенных заданиях.
Решение 2.
Перейдите от системы, основанной на очередях, к потоковой базе данных, например kafka. Потоковая база данных поддерживает воспроизведение событий с определенного момента времени, что дает вам возможность догнать и заметить пропущенные сообщения.
Решение 3.
Добавьте отдельный процесс репликации существующих данных, который можно применять "вручную". Это может быть полезно, если у вас есть конкретный одноразовый процесс, требующий полной информации, например, развертывание нового арендатора. Вам может понадобиться большое количество базовых данных перед подпиской на push-сообщения, слишком много для API, но можно обойтись плоским файлом экспорта/импорта на карте памяти.