CQRS + EventSourcing масштабируемость

Question

Я пытаюсь использовать CQRS и EventSorcing в моем новом проекте.Я придерживаюсь того, что Грег Янг предложил несколько лет назад (реализация Марка Нийхофа - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/). И у меня есть некоторые проблемы, связанные с масштабируемостью этого решения.

Некоторые моменты были упомянуты в этом статья Марка Нийхофа. Но проблема теперь в части Denormalizer, которая отвечает за обновление базы данных отчетов. Эту часть я хочу сделать асинхронной, поэтому после публикации событий на шине я хочу немедленно вернуть управление. Мы предложиличто Denormalizer может быть реализован как автономный веб-сервис (WCF), который будет обрабатывать входящие события и своевременно обновлять базу данных отчетов с помощью пакетов команд. Кажется, что это может быть узким местом, поэтому мы также хотим добавить некоторыеМасштабируемость на данный момент - кластерное решение. Но в случае кластера мы не можем контролировать последовательность отчетов об обновлениях базы данных (или нам следует реализовать какую-то странную и, я думаю, ошибочную логику, которая будет проверять версии объектов в отчете БД).проблема в устойчивости решения: в случае сбоя мы потеряем обновления в денормализаторе, поскольку мы их нигде не сохраним).Так что теперь я ищу решение этой проблемы (масштабируемость денормализатора), любые мысли приветствуются!

Answer 1

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

Пока вы используете какую-либо инфраструктуру обмена сообщениями, вы не потеряете сообщения о событиях при попытке денормализации.Вместо этого после определенного числа повторных попыток сбоя сообщение будет считаться «ядом» и перемещено в очередь ошибок.Просто следите за ошибкой в ​​очереди.Когда сообщение находится в очереди ошибок, вы можете проверить свои журналы, чтобы выяснить, почему оно там, исправить проблему, а затем переместить ее обратно.

Еще одно соображение заключается в том, что пример Марка Нийхофа несколько устарел.В группе Google DDD / CQRS .

имеется ряд платформ CQRS, а также множество советов.