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