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

Question

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

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

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

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

Заранее благодарен за помощь!

Answer 1

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

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

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

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