CQRS и Event Sourcing - Читайте свои собственные события - PullRequest
Новая
       77

CQRS и Event Sourcing - Читайте свои собственные события

0 голосов
/ 25 октября 2019

В настоящее время я внедряю Event Driven Architecture и имею службу для команды (часть записи) и другую службу для запроса (часть чтения).

Что я сейчас делаю.

  1. Принять команду на CommandService
  2. Сохранить событие и опубликовать событие на шине событий
  3. ReadService прослушивает эти события и обновляет модели чтения

Thisзвучит хорошо, если вы слушаете свои собственные события. Допустим, я слушаю внешнее событие из CommandService

  1. Прослушивание события
  2. Обработка команды для этого события
  3. Сохранение события, созданного вашим доменом, в вашем хранилище событийи опубликовать это событие в шине событий
  4. ReadService прослушивает эти события и обновляет модели чтения

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

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

Что вы думаете?

Ответы [ 2 ]

1 голос
/ 31 октября 2019

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

Да, вы уменьшитезадержка, но вы введете связь между двумя службами, это не обязательно плохо, но если две службы разъединены (с использованием шины), вы можете масштабировать каждую из них независимо.

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

1 голос
/ 31 октября 2019

Мы сделали нечто подобное некоторое время назад. По сути, у нас был

  1. Сервис, реализующий шаблон менеджер процессов и выполняющий некоторую логику оркестровки между несколькими сервисами с использованием EventSourcing и Saga. Каждое событие, хранящееся в базе данных, содержит EventPayload, сериализованный в формате Avro, с состоянием процесса в момент времени, когда произошло событие. Эта полезная нагрузка содержит все состояние, а не только различия, поэтому мы обновляли эту полезную нагрузку во время обработки.
  2. Мы использовали Kafka Connect JDBC Source Connector для чтения из EventStore и в основном, как только новыйсобытие было опубликовано в EventStore, Соединитель прочитал событие и опубликует его в Kafka (Kafka использовался как EventBus).
  3. Модель чтения, которая была помещена в другой сервис, была обновлена ​​через Kafka (вот два подхода: используя Kafka Connect JBC Sink Connector или используя Kafka Consumer и выполняйте транзакционные обновления от Consumer).

Надеюсь, это поможет вам!

...