Источник событий - разъяснение потоков событий - PullRequest
Новая
       20

Источник событий - разъяснение потоков событий

0 голосов
/ 27 декабря 2018

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

  • Ресторанный сервис (который управляет информацией о ресторане, такой как имя, владелец, таблицы).
  • Сервис бронирования (который управляет подтверждением бронированияworkflow).

Поток событий для сущности «Ресторан» был довольно прост: streamId - это restaurantId, и каждое событие, например «tableAdded» или «tableRemoved», имеет инкрементный идентификатор события.Воспроизведение каждого события и получение совокупности тривиально.

А как насчет бронирования?Мой текущий дизайн потока событий использует restaurantId в качестве streamId, и к этому потоку добавляется каждое событие, например «bookingAccepted» или «servationRefused ».

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

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

Подводя итог: если я прошурезервирование на завтра, система воспроизведет резервирования от 6 месяцев назад, которые обычно не связаны с входящим запросом, поскольку они относятся к моменту в прошлом.

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

Есть идеи?

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

1 Ответ

0 голосов
/ 28 декабря 2018

Я предлагаю узнать о CQRS https://martinfowler.com/bliki/CQRS.html, который является важной частью головоломки при использовании управляемых событиями.

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

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

Это иногда также называют проекцией: https://dzone.com/articles/the-good-of-event-sourcing-projections

Проекции могут быть

  1. вычислены, когда происходит проверка (может быть неэффективным, например,Вы указали)

  2. пересчитано или обновлено, когда происходит новое событие, связанное с этой проекцией.

  3. Все, что имеет смысл между этими параметрамиВам.

...