Очередь сообщений против веб-служб?

В каких условиях можно говорить о том, что приложения говорят через очередь сообщений, а не через веб-службы (я имею в виду только XML, JSON или YAML или что-то вроде HTTP, а не какой-либо конкретный тип)?

Мне нужно поговорить между двумя приложениями в локальной сети. Один из них будет веб-приложением и должен запросить команды в другом приложении (работает на другом оборудовании). Запросы - это такие вещи, как создание пользователей, перемещение файлов и создание каталогов. В каких условиях я бы предпочел использовать веб-службы XML (или прямой TCP или что-то еще) для использования очереди сообщений?

Веб-приложение Ruby on Rails, но я думаю, что вопрос шире.

ОТВЕТЫ

Ответ 1

При использовании веб-службы у вас есть клиент и сервер:

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

Когда вы используете очередь сообщений, такую ​​как RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo вы ожидаете разные и более отказоустойчивые результаты:

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

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

Ответ 2

Было проведено большое количество недавних исследований, посвященных рассмотрению того, как HTTP-вызовы REST могут заменить концепцию очереди сообщений.

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

Пример:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Задача может иметь несколько шагов для инициализации, и процесс может возвращать статус при опросе или POST на URL обратного вызова по завершении.

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

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

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

GET /task/name
    - returns form with required fields

POST (URL provided form "action" attribute)

Открытие вашего сервиса - это форма HTML - универсальный и удобный для чтения формат.

Весь поток может использоваться программно или человеком, используя общепринятые инструменты. Это клиент, и, следовательно, RESTful. Каждый инструмент, созданный для Интернета, может управлять вашими бизнес-процессами. У вас по-прежнему есть альтернативные каналы сообщений, асинхронно POSTing в отдельный массив серверов журналов.

Подумав об этом некоторое время, вы откинетесь и начнете понимать, что REST может просто исключить необходимость в очереди сообщений и ESB вообще.

http://www.infoq.com/presentations/BPM-with-REST

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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