Веб-служба RESTFUL v Очередь сообщений при использовании Scatter Gatherer

Question

Скажем, у меня есть настройка набора рассеяния, подобная этой:

1) Web app
2) RabbitMQ
3) Scatter gather API 1
4) Scatter gather API 2
5) Scatter gather API x

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

1) вызов RESTFUL от каждого API к веб-приложению, добавление / обновление изображения, где это необходимо 2) Использование очереди сообщений для отправки изображения

Я считаю, вариантдва лучше, потому что я использую архитектуру микросервисов.Однако это будет означать, что изображение может быть обработано веб-приложением после выполнения запросов (если используются конкурирующие потребители).Следовательно, изображение может отсутствовать на веб-странице?

Проблема, связанная с вариантом 1, заключается в том, что apis scatter gatherer тесно связаны с веб-приложением.

Каков подходящий подход к этому?

Answer 1

Краткий ответ: Нет правильного способа сделать это.

Длинный ответ: Поскольку нет правильного способа сделать это, есть опасность, что любой ответ, который я дам вам, будет мнением.Вместо того, чтобы сделать это, я собираюсь помочь прояснить последствия каждого предложенного вами варианта.

Первое, на что следует обратить внимание: Если на момент запроса HTTP уже не было изображения, ваш ответ HTTP не сможет включать изображение.Это означает, что ваш интерфейс необходимо будет обновить после завершения цикла HTTP-запроса / ответа.Есть два способа сделать это: опрос через запросы AJAX или проталкивание через сокеты.

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

Второе, что следует отметить: Сообщение об изображении изРаботники разброса / сбора могут происходить либо через конечную точку HTTP, либо через очередь сообщений, как вы предлагаете.

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

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

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

РЕДАКТИРОВАТЬ

Ограничения, которые мы учитывали при выборе очереди сообщений по HTTPвключено:

• Не желая добавлять частные конечные точки в общедоступное веб-приложение
• Не желая задерживать работника в ожидании HTTP-запроса / ответа
• Не желая делать синхронным то, что было асинхронным

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