Получение данных из системы, управляемой событиями

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

Различные части:

  • Пользовательский интерфейс, который взаимодействует со шлюзом API через соединение через веб-сокет.
  • Шлюз получает полезную нагрузку и создает сообщение с полезной нагрузкой, которое попадает в кластер Kafka.
  • Служба использует сообщения, проверяет и сохраняет сущность в базе данных. Событие отправляется в Kafka для использования шлюзом и обратно в пользовательский интерфейс.

Для создания, обновления и удаления его довольно просто.

Однако, когда дело доходит до получения данных, где я обычно использую вызов HTTP GET, все становится немного сложнее. Как я могу правильно получить эти данные? Могу ли я создать событие запроса или какие у меня есть варианты? Данные в базе данных также должны быть «доступными для поиска» и «страничными» через службу - обычно я бы использовал для этого строку запроса. Я считаю, что мои «события запроса данных» довольно огромны и содержат много логики о том, какие данные запрашиваются. На самом деле поток сейчас такой же, как и для создания, обновления и т. Д. где в Kafka отправляется событие, содержащее информацию о том, какие данные следует запросить.

Как правильно обрабатывать считывание данных в зависимости от событий?

Как сделать мои данные доступными для поиска? (например, получить все ресурсы, которые имеют внешний ключ к ресурсу x или содержат name = "xyz")


apache-kafka events event-handling event-driven event-driven-design
person frisk0k    schedule 21.05.2020    source источник
comment
Вы говорите, что требуется, чтобы система была asynchronous - какова бизнес-причина этого? Для чтения вам, скорее всего, лучше запросить БД из шлюза API (возможно, через какой-то тонкий слой, чтобы абстрагироваться от деталей сохраняемости). Если бизнес-требованием является производительность / масштабируемость, вы можете решить это с помощью других инструментов (кэширование, зеркало БД только для чтения и т. Д.), Которые проще и намного эффективнее, чем делать это с помощью событий.   -  person JME    schedule 22.05.2020

Ответы (1)


arrow_upward
0
arrow_downward

В зависимости от требований вашего бизнеса существует несколько вариантов:

Вариант А:

  • Вы можете запрашивать и распространять данные «во время записи». Это означает, что перед помещением данных в кластер Kafka вы можете сохранить карту подключенных клиентов и распределить данные этим клиентам в зависимости от их интересов.
  • Также, используя эту карту подключенных клиентов на основе их интересов, вы можете подписать этих клиентов на соответствующие темы в Kafka.
  • Вы также можете рассмотреть отправленные сервером события и отделить входящее подключение к веб-сокету от обновлений для ваших клиентов, если это необходимо.

Вариант Б:

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

Вариант C:

  • Вы также можете рассмотреть такую ​​технологию, как GCP Firestore, и записать результаты запроса либо во время записи, либо во время чтения, и позволить Firestore обрабатывать их для распространения.

Также вы можете комбинировать эти варианты и создать гибридный подход.

person ismet özöztürk    schedule 28.05.2020