CQRS и Event Sourcing Guide

Question

Я хочу создать архитектуру CQRS и Event Sourcing , которая будет очень дешевой, очень гибкой и очень простой.

Я хочу убедиться, что события никогда не дойдут, по крайней мере, до издателя / хранилища событий, когда-либо, потому что это то, где бизнес.

Теперь у меня есть несколько вариантов:

Azure

С лазурью я, кажется, не знаю, что использовать.

1. Сервисный автобус Azure
2. Функция Azure
3. веб-задание Azure (я полагаю, это можно заменить функциями Azure)
4. ?? (что-то еще я забыл или не знаю?)

Насколько надежны эти серверные решения Azure ??

Custom

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

---

В общем, я хочу:

1. Возможность воспроизведения сообщений / событий в случае сбоя.
2. Возможность легко добавлять подписчиков.
3. Возможность выбора подписчиков для повторного воспроизведения сообщений.
4. Хранилище событий должно иметь возможность хранить очень большие размеры сообщений о событиях (или как еще поместить в очередь изображение или файл ??).
5. Магазин событий НИКОГДА НЕ ДОЛЖЕН быть забит или спать.
6. Скорость внедрения / прототипирования будет добавлена преимущество.

---

Что говорит ваш опыт?

А как насчет других альтернатив? (например: apache-kafka)?

Answer 1

Я пользователь java, я использую hornetq (иначе я не использую artemis) альтернативу rabbitmq для самого длинного; единственная проблема в том, что он не поддерживает репликацию, но выполняет работу, когда дело доходит до событийного поиска. Для вашего пользовательского сценария rabbitmq - хороший выбор, но попробуйте запустить его на цифровом экземпляре Ocean для низких затрат. Если вы ищете простоту и гибкость, у вас есть только 2 варианта, создайте свой собственный или воздержитесь от простоты и подберите apache kafka со всеми его сложностями, но он даст вам гибкость. Опять же, вы также можете создать хранилище событий с помощью mongodb. https://www.mongodb.com/blog/post/event-sourcing-with-mongodb

Answer 2

Почему бы не запустить Event Store? Создано самим Грегом Янгом. Хост, где вам нужно.

Answer 3

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

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