Существует ли «лучший метод» в разработке микросервисов для управления версиями таблицы базы данных?

Question

Система внедряется с использованием микросервисов. Чтобы уменьшить взаимодействие между микросервисами, реализованными «на одном уровне» в архитектуре, некоторые микросервисы будут локально кэшировать копии таблиц, управляемых другими сервисами. Предполагается, что локально кэшированная таблица (a) часто доступна в «режиме чтения» микросервисом и (b) имеет относительно статическое содержимое (т. Е. Больше «поисковой таблицы», чем транзакционное содержимое).

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

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

Есть ли "лучшая практика" для этого подхода? Или «лучшая альтернатива», учитывая, что каждый микросервис поддерживается своей собственной базой данных (т. Е. Нет общей базы данных)?

Answer 1

Мы столкнулись с этой же проблемой и временно решили ее, используя сравнение отметок времени LastUpdated (та же концепция, что и у вашего VersionNumber).Каждую ночь (когда наше приложение работает медленно), каждый сервис публикует сообщение ServiceXLastUpdated, которое включает самую последнюю временную метку, когда принадлежащие ей данные были добавлены / отредактированы.Любая другая служба, которая подписывается на эти данные, обрабатывает сообщение и, если имеется несоответствие, запрашивает все строки, к которым был произведен переход, с момента последнего локального обновления, чтобы он мог вернуться в синхронизацию.

Для нас, на данный момент, этоЭто нормально, так как новые сервисы не имеют тенденцию выходить в интернет и использоваться в тот же день.Но наш план на будущее заключается в том, что каждый раз, когда служба запускается, она может публиковать сообщение для каждой подписанной службы, указывающее, что это самая последняя отметка времени обновления кэша.Если служба «источник» видит, что временная метка не является текущей, она может отправлять обновления для повторной синхронизации данных.Преимущество этого заключается в отправке только необходимых обновлений определенной службе (службам), которая в них нуждается, хотя (по крайней мере для нас) все подписанные службы имеют доступ к сообщениям.

Мы начали с использования постоянных очередей, поэтомуесли бы все экземпляры микросервиса были недоступны, сообщения просто создавались бы в его очереди.Есть 2 проблемы, которые привели нас к созданию чего-то лучшего:

1) Очевидно, что это не решает сценарий «первого запуска», так как нет очереди для сообщений, которые нужно создать в

2) Если НИЧЕГО не работает либо при хранении сообщений в очереди, либо при их обработке, вы не синхронизированы.Если это произойдет, вам все еще нужен упреждающий механизм, подобный тому, который есть у нас сейчас, чтобы восстановить синхронизацию.Таким образом, казалось, что стоит пойти по этому пути

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

Answer 2

По моему мнению, вы не должны загружать данные при запуске.Поддерживать версию может быть немного сложно.

Шаблон кэширования в сторону

Обычно в архитектуре микросервисов вы рассматриваете "шаблон кэширования в стороне".Вы не строите кеш заранее, а по требованию.Когда вы получаете запрос, вы проверяете кеш, если его нет, вы обновляете кеш с последним значением и возвращаете ответ, оттуда он всегда возвращается из кеша.Преимущество заключается в том, что вам не нужно загружать все на фронт.Скажем, у вас есть 200 записей, а службы часто используют только 50 из них, вы поддерживаете дополнительный кеш, который может не потребоваться.

Пусть запросы строят кеш, это одноразовый удар по БД.Вы можете установить срок действия кэша, а входящий запрос построить его снова.

Если у вас есть данные, которые полностью статичны (никогда не меняются), то этот шаблон может не стоить обсуждения, но если у вас есть справочная таблица, которая может меняться даже раз в неделю, месяц, тогда вам следуетиспользуя этот шаблон с более длительным сроком действия кэша.Поддержание версии может быть дорогостоящим.Но на самом деле до вас, как вы можете реализовать.

https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside