Очередь сообщений по сравнению с веб-сервисами? [закрытый]
При каких условиях можно было бы одобрить приложения, говорящие через очередь сообщений вместо через веб-сервисы (я просто имею в виду XML или JSON или YAML или безотносительно по HTTP здесь, не какому-либо конкретному типу)?
Я должен говорить между двумя приложениями в локальной сети. Каждый будет веб-приложением и иметь для запроса команд на другом приложении (работающий на других аппаратных средствах). Запросы являются вещами как создание пользователей, перемещение файлов и создание каталогов. При каких условиях я предпочел бы веб-сервисы XML (или прямой TCP или что-то) к использованию Очереди сообщений?
Веб-приложение является Ruby on Rails, но я думаю, что вопрос более широк, чем это.
4 ответа
Когда вы используете веб-службу, у вас есть клиент и сервер:
- Если сервер выходит из строя, клиент должен взять на себя ответственность за обработку ошибки.
- Когда сервер снова работает, клиент отвечает за его повторную отправку.
- Если сервер отвечает на вызов, а клиент терпит неудачу, операция теряется.
- У вас нет конфликта, а именно: если миллион клиентов вызывает веб-службу на одном сервере за секунду, скорее всего, ваш сервер выйдет из строя.
- Вы можете ожидать немедленного ответа от сервера, но вы также можете обрабатывать асинхронные вызовы.
Когда вы используете очередь сообщений, такую как RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, вы ожидаете других и более отказоустойчивых результатов:
- Если сервер выходит из строя, очередь сохраняет сообщение (необязательно, даже если машина неисправность).
- Когда сервер снова работает, он получает ожидающее сообщение.
- Если сервер дает ответ на вызов, а клиент терпит неудачу, если клиент не подтвердил ответ, сообщение сохраняется.
- У вас есть разногласия, вы можете решить, сколько запросов обрабатывает сервер (вместо этого назовите его worker).
- Вы не ожидаете немедленного синхронного ответа, но можете реализовать / смоделировать синхронные вызовы.
Очереди сообщений имеют намного больше функций, но это некоторое практическое правило, позволяющее решить, хотите ли вы обрабатывать ошибки самостоятельно или оставить их в очереди сообщений.
Очереди сообщений асинхронны и могут повторять попытки несколько раз, если доставка не удалась. Используйте очередь сообщений, если запрашивающей стороне не нужно ждать ответа.
Фраза «веб-службы» заставляет меня думать о синхронных вызовах распределенного компонента через HTTP. Используйте веб-службы, если запрашивающему требуется ответ.
Очереди сообщений идеально подходят для запросов, обработка которых может занять много времени. Запросы ставятся в очередь и могут обрабатываться в автономном режиме без блокировки клиента. Если клиент должен быть уведомлен о завершении, вы можете предоставить ему возможность периодически проверять статус запроса.
Очереди сообщений также позволяют лучше масштабироваться во времени. Это улучшает вашу способность справляться со всплесками большой активности, поскольку фактическая обработка может быть распределена во времени.
Обратите внимание, что очереди сообщений и веб-службы являются ортогональными концепциями, т.е. они не исключают друг друга. Например. у вас может быть веб-служба на основе XML, которая действует как интерфейс для очереди сообщений. Я думаю, что различие, которое вы ищете, - это очереди сообщений по сравнению с запросом / ответом, последний - когда запрос обрабатывается синхронно.
Я думаю, что в целом вам понадобится веб-служба для задачи блокировки ( эти задачи должны быть выполнены, прежде чем мы выполним дополнительный код), и очередь сообщений для неблокирующей задачи (может занять некоторое время, но нам не нужно ждать этого).