Вставка данных в очередь и извлечение данных работниками

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

Работа, которую отправляет клиент, может быть полностью описана uuid. Я надеюсь использовать сервис-ориентированную архитектуру (SOA) (т.е. несколько микросервисов).

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

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

Вот схемы двух рассматриваемых архитектур:

На основе push-уведомлений (т. е. сбор данных вверх по течению): На основе push-уведомлений (т. е. сбор данных вверх по течению)

На основе извлечения (т. е. работник собирает данные): На основе извлечения (т. е. работник собирает данные). данные)

Некоторые вещи, о которых я подумал:

  1. В случае с push-уведомлением я, скорее всего, буду блокироваться, пока собираю необходимые данные, поэтому на HTTP-запрос клиента не будет дан ответ до тех пор, пока данные не будут собраны, а затем поставлены в очередь. С точки зрения пользовательского интерфейса запрос будет отложен до тех пор, пока не вернется ответ.
  2. В сценарии на основе извлечения только рабочий должен знать, какие данные требуются для работы. Это означает, что у меня может быть несколько типов клиентов, взаимодействующих с разными бэкендами. Если данные нуждаются в изменении, я обновляю только рабочие процессы, а не каждую из вышестоящих служб.

Что-нибудь еще, что мне здесь не хватает?


microservices message-queue soa
person Alex Rothberg    schedule 07.02.2015    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

person Udi Dahan    schedule 08.02.2015

arrow_upward
1
arrow_downward

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

  1. Если запрос пользователя в любом случае должен обрабатываться асинхронно, зачем ждать, пока данные будут собраны, а затем возвращать ответ. Вам нужно просто поставить рабочий элемент в очередь и вернуть HTTP-ответ.
  2. Передача данных через очередь не является хорошим вариантом. Если вы получаете данные вверх по течению, вам придется передать их как-то иначе, чем через очередь, рабочему процессу (обычно хранилище BLOB). Это дополнительная работа, которая на самом деле не нужна в вашем случае.
person Vadim K.    schedule 07.02.2015
comment
Я предполагаю, что мой вопрос заключается в том, есть ли какие-либо преимущества в подходе, основанном на толчке? - person Alex Rothberg; 08.02.2015
comment
Основываясь на высокоуровневом описании вашего случая, я не уверен, что действительно вижу какие-либо преимущества подхода, основанного на толчке. - person Vadim K.; 08.02.2015

arrow_upward
0
arrow_downward

Я бы рекомендовал Cadence Workflow вместо очередей, поскольку он поддерживает длительные операции и управление состоянием из коробки.

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

  • Встроены экспоненциальные повторные попытки с неограниченным интервалом истечения срока действия.
  • Обработка отказа. Например, он позволяет выполнить задачу, которая уведомляет другую службу, если оба обновления не могут быть выполнены в течение настроенного интервала.
  • Поддержка длительных операций сердцебиения
  • Возможность реализации сложных зависимостей задач. Например, для реализации цепочки вызовов или логики компенсации в случае неустранимых сбоев (SAGA).
  • Дает полную видимость текущего состояния обновления. Например, при использовании очередей все, что вы знаете, есть ли какие-то сообщения в очереди, и вам нужна дополнительная БД для отслеживания общего прогресса. С Cadence каждое событие записывается.
  • Возможность отменить обновление в полете.

См. презентацию, посвященную модели программирования Cadence.

person Maxim Fateev    schedule 16.06.2019