Источник событий для синхронных задач

Question

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

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

1. Получите сетевой запрос на API-шлюзе или какой-либо службе на границе сети и отправьте событиеэто представляет этот запрос. На этом этапе шлюз API будет зависать и ждать.

2. Отправленное событие перехватывается хранилищем событий и регистрируется

3. Служба сбизнес-логика для обработки обновления фиксирует событие, когда оно подписано на хранилище событий. Он генерирует событие успеха, если ему удалось обработать обновление, или событие ошибки, если он не смог этого сделать.

4. шлюз API получает либо одно из событий успеха или ошибки,ожидал и, наконец, отправляет ответ браузеру.

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

Answer 1

Вы смешиваете несколько терминов и идей, которые важно хранить отдельно. Как только вы разделите их в своей голове, все должно стать ясным.

Источник событий и архитектура, управляемая событиями, - это две разные идеи. Event Sourcing означает, что вы сохраняете все изменения объекта в хранилище событий и для получения текущего состояния этого объекта вы складываете все события. Эта концепция относится к хранению состояния, а не к обработке запросов. Событийно-ориентированная архитектура - это то, на что, я думаю, вы ссылаетесь в этом вопросе. Необходимость отделить эти идеи в одно мгновение станет ясной.

В архитектуре, управляемой событиями, есть две идеи, которые необходимо разделить. Из пользовательского интерфейса или внешней системы поступает запрос на внесение некоторых изменений в данные;это сообщение или запрос. Обработчик сообщений (обычно называемый командой в CQRS) обрабатывает запрос и либо отклоняет его как недействительный, либо вносит соответствующие изменения в объекты в системе. Изменения в этих объектах затем сохраняются как события в хранилище событий. События в хранилище событий должны содержать только измененные данные, а не все свойства объекта. Если команда изменяет более одного объекта, в хранилище событий будет записано более одного события.

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

Имея все это в виду, мы можем поговорить о том, как архитектура, управляемая событиями, обрабатывает как синхронные, так и асинхронные события. Имейте в виду, что EDA разработан для асинхронной обработки и возможной согласованности, поэтому синхронизация - это дополнительная работа.

Используя ваши 4 шага выше, мы получим

Шаг 1: Без измененийлогика вашего описания. Шлюз получает запрос (не событие) и ожидает.

Шаг 2: Некоторым разработчикам нравится хранить входящие запросы для анализа шаблона и тому подобное, но нет необходимости успешно обрабатывать запрос.

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

Ваша система работает синхронно, поэтому API напрямую вызывает службу, отвечающую за обработку бизнес-логики, - команду.

Шаг 3: Запрособрабатывается командой, проверяя запрос и внося необходимые изменения в сущности. События создаются для всех изменений объекта (одно событие на объект).

Шаг 4. Команда возвращает значение успеха или ошибки синхронно API, который возвращает его вызывающей стороне. Обратите внимание, что это должен быть асинхронный / ожидающий вызов, а не блокирующий вызов из API. Для API и пользователя это все равно выглядит как синхронный процесс.