Event-sourcing: когда (и не) следует использовать очередь сообщений?

Question

Я строю проект с нуля, используя event-sourcing с Java и Cassandra. Мои приложения, основанные на микросервисах, и в некоторых случаях информация будет обрабатываться асинхронно. Мне было интересно, какая часть очереди сообщений (например, Rabbit, Active MQ Artemis, Kafka и т. Д.) Будет играть, чтобы улучшить технологический стек в этой среде, и если я пойму сценарии, если не буду использовать его.

Answer 1

Убедитесь, что вы четко разбираетесь в различии между отправкой (командой) и публикацией (событием). Уди Дахан затрагивает эту тему в своем эссе по адресу busses and brokers.

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

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

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

Answer 2

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

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

вопрос не является «стоять в очереди или не стоять в очереди», но это больше похоже на:

• может эта вещь магазин огромный объем событий на неопределенный срок?
• У этого есть возможности публикации-подписки?
• Предоставляет ли гарантия доставки по крайней мере один раз?

Таким образом, вы должны использовать что-то вроде Kafka или EventStore иметь все то, что вне коробки. Кроме того, вы можете комбинировать хранилище событий с очередью сообщений вручную, но это будет более активно.

Answer 3

Я бы начал с разделения инфраструктуры обмена сообщениями, такой как RabbitMQ, с потоковой передачи/хранения/обработки событий, таких как Kafka. Это две разные вещи, сделанные для двух (или более) разных целей.

Что касается источника событий, у вас должно быть место, где вы должны хранить события. Это хранилище должно быть только append и поддерживать быстрое считывание неструктурированных данных на основе идентичности. Одним из примеров такого сохранения является EventStore.

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

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

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

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

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