Запуск нового микросервиса, который использует события других микросервисов

#distributed-computing #event-sourcing

#распределенные вычисления #источник событий

Вопрос:

Меня беспокоила эта проблема: предположим, у вас уже существует среда микросервиса, и вы хотите запустить новый микросервис, который предлагает новые функциональные возможности. Если этому микросервису необходимо использовать старые события для обеспечения своих функциональных возможностей, как это следует обрабатывать?

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

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

Моя идея состояла в том, чтобы сохранить в конечном итоге согласованный репозиторий, где я сохраняю все события в том порядке, в котором они произошли (давайте назовем это историей событий). Запуская новую MS, она будет подписываться на интересующие темы и запрашивать историю событий до определенного момента. Такое ощущение, что я дублирую ненужные данные, и я искал лучшие решения.

Заранее спасибо за вашу помощь!

Ответ №1:

Я думаю, что запрос к хранилищу событий — это правильный путь. Любое хранилище событий должно предоставлять некоторый метод для чтения всех событий, независимо от потока. (У некоторых также может быть опция «предоставить мне все события для агрегатов типа X» … но, как минимум, должна быть опция «все».)

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

Использование отдельного репозитория «истории событий» просто немного повредило бы делу — вам все равно пришлось бы заполнять это репозиторий и снова сталкиваться с той же проблемой.

Если у вас было несколько сервисов, которым всем требовался только определенный набор событий / типов данных, тогда, возможно, имело бы смысл иметь отдельный «репозиторий фильтров», который мог бы извлекать события из хранилища и сохранять только необходимые. Тогда службы могли бы получать свои данные из предварительно отфильтрованных данных, а не непосредственно из хранилища. Однако компромисс между сложностью и производительностью следует рассматривать для каждой системы!