Синхронизация реплик микросервисов

Синхронизация реплик микросервисов
Синхронизация реплик микросервисов - growtika @ Unsplash

В микросервисной архитектуре принято считать, что каждый микросервис должен иметь свою собственную реплику от другого "основного" микросервиса, выступающего в качестве единого источника истины. Это позволяет поддерживать автономность и свободное взаимодействие микросервисов.

Когда "главный" микросервис изменяется, он издает некоторые события, чтобы заинтересованные микросервисы обновляли свои реплики и синхронизировались. Используя брокер с постоянными очередями, мы можем "вполне" гарантировать, что никакие события не потеряются и реплики будут обновляться.

Но "вполне" - это не 100%, и все еще есть другие способы рассинхронизации:

  • Если к системе присоединяется вновь созданный микросервис, как он строит свою реплику (ведь все события уже испущены)? Должны ли мы снова ввести некий (анти-паттерн) синхронный обмен данными для запроса всех данных из "главного" микросервиса и построения реплики?
  • Когда должен происходить этот процесс? При запуске системы (на устройстве) ? Периодически в облачной архитектуре?
  • Должны ли мы блокировать всю систему до окончания синхронизации (мы не хотим, чтобы "главный" микросервис испускал новые события, пока мы синхронизируемся, потому что мы получаем риск снова рассинхронизироваться).

Как вы решили эти проблемы на своих реализациях? Я где-то видел концепцию "согласования", но не нашел ни одной реализации этой концепции.

Большое спасибо!

Во-первых, ваша микрослужба не должна иметь копию данных другой микрослужбы

Каждый микросервис должен иметь только свои собственные данные и при необходимости обращаться к другим apis. Хотя дизайн вашей системы, позволяющий избежать большого количества таких вызовов, является ключевым.

Однако необходимость воспроизводить прошедшие или пропущенные события, чтобы наверстать упущенное, является распространенной проблемой в системах, управляемых событиями.

Решение 1.

Добавьте API "Получить прошедшие события" в дополнение к push-сообщениям. Это позволит наверстать упущенное, проверить пропущенные сообщения и другие сценарии. Это не совсем антишаблон, если только вы не вынуждены использовать его настолько часто, что, по сути, признаете, что push-сообщениям нельзя доверять.

Я думаю, что довольно распространено добавление такого интерфейса и какого-то задания проверки/синхронизации, которое проверяет всю систему по расписанию. Например, у вас есть задания, которые не перешли в ожидаемый SLA, это может быть связано с пропущенным или ошибочным сообщением, вы можете захотеть опросить пропущенные сообщения на этих отложенных заданиях.

Решение 2.

Перейдите от системы, основанной на очередях, к потоковой базе данных, например kafka. Потоковая база данных поддерживает воспроизведение событий с определенного момента времени, что дает вам возможность догнать и заметить пропущенные сообщения.

Решение 3.

Добавьте отдельный процесс репликации существующих данных, который можно применять "вручную". Это может быть полезно, если у вас есть конкретный одноразовый процесс, требующий полной информации, например, развертывание нового арендатора. Вам может понадобиться большое количество базовых данных перед подпиской на push-сообщения, слишком много для API, но можно обойтись плоским файлом экспорта/импорта на карте памяти.


LetsCodeIt, 3 января 2023 г., 13:39