Интеграция шины сообщений и повторная синхронизация ограниченных контекстов после простоя - Service Bus 1.0

Question

Я только что скачал Joliver EventsStore и ищу подключить служебную шину с Windows Service Bus 1.0 для приложения, разделенного между несколькими процессами ограниченного контекста.

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

1. Для примера ContextA, ContextB и ContextC, все из которых подключены с использованием Service Bus 1.0 и каждый контекст со своим собственным хранилищем событий, они все используют одну и ту же объединительную панель обмена сообщениями шины.
2. ContextC отключается.
3. Когда ContextC возвращается, другие ограниченные контексты должны быть уведомлены о событиях, которые должны быть повторно отправлены в контекст, который только что вернулся в онлайн. Эти события воспроизводятся из каждого хранилища событий.

Мои вопросы:

1. Вышеприведенный сценарий будет применяться к любым библиотекам источников событий, поэтому есть ли какой-нибудь инфраструктурный код, который я могу использовать, или мне нужно свернуть свой собственный?
2. В Windows Service Bus 1.0 как объединить порядковые номера в моем хранилище событий с порядковыми номерами в служебной шине?
3. Какова наилучшая практика для обнаружения и обработки событий, которые уже были получены безопасным способом (защита от сбоя обработчиков сообщений)?

Answer 1

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

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

В результате я не знаю о коммодитизированном объекте такого рода.

Хранилище GetEventStore имеет встроенную функцию проекции, которая выглядит чрезвычайно мощной и избавляет от необходимости строить все это со стола. До его существования я бы поспорил, что не стоит даже смотреть сквозь SRPness JOES.

Вы ничего не сказали о вашем текущем стеке, кроме упоминания Azure.

С помощью служебной шины Windows как объединить порядковые номера в моем хранилище событий с порядковыми номерами на служебной шине?

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

Какова наилучшая практика для обнаружения и обработки событий, которые уже были получены безопасным способом (защита от сбоя обработчиков сообщений)?

Если вы используете Azure и рассматриваете возможность использования Service Bus, то разделы можно использовать для обеспечения хотя бы одной доставки (и вы будете использовать средство сеанса). Посмотрите двухчасовое глубокое погружение ClemensV Subscribe video и еще несколько эпизодов, или вы потратите столько же времени на ошибки)

Чтобы сдерживать широковещательный трафик, если ContextC запрашивает повторы от ContextA и ContextB, есть ли способ, чтобы эти сообщения воспроизведения были отправлены только в ContextC? Или я не должен беспокоиться об этом?

Mu. Вы начали спрашивать, была ли эта штука хорошей идеей, но теперь, кажется, испеклись в предположении, что это путь.

Во-первых, эта инфраструктура представляет собой огромное колесо для изобретения. Рассматривали ли вы просто настройку темы для каждого BC и иметь кого-то, кто должен слушать, слушать?

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

---

РЕДАКТИРОВАТЬ: Ответы на ваши отредактированные версии вопросов 2+

В Windows Service Bus 1.0 как объединить порядковые номера в моем хранилище событий с порядковыми номерами в служебной шине?

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

Как только события на тему, у них есть MessageSequenceNumber и подписка (когда сеанс) доставляет (фактически подписчик получает их) их в последовательности.

Какова наилучшая практика для обнаружения и обработки событий, которые уже были получены безопасным способом (защита от сбоя обработчиков сообщений)?

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

Тематически естественным образом занимается абонент, который делает перерыв, отключается или выполняет резервное копирование.