Подходит ли AMQP как для внутренней, так и для межмашинной программной шины?

Question

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

Стоит ли вытаскивать существующую высокопроизводительную инфраструктуру передачи сообщений, чтобы заменить ее AMQP, или это попадает в ту же ловушку, что и RPC , стирая различие между локальной и нелокальной связью?

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

Военные истории будут оценены.

Answer 1

AMQP не является платформой RPC. Он предоставляет строительные блоки для моделирования таких вещей, как общие очереди, RPC, pubsub и т. Д., Но не требует какого-либо конкретного способа его использования.

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

Answer 2

AMQP - это спецификация, поэтому вы действительно сравниваете яблоки с апельсинами. На самом деле не так много поставщиков AMQP, готовых к производству; Ни один из крупных провайдеров или поставщиков сообщений не поддерживает AMQP на момент написания (например, IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq от Sun), поэтому все доступные провайдеры AMQP довольно новы. 1001 *

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

Answer 3

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

Если у вас есть проблемы, такие как:

• Совместимость не работает
• Не может легко масштабироваться
• Производительность не достаточно хорошая
• Текущее решение для обмена сообщениями дорого (в обслуживании)

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

Answer 4

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

В настоящее время я оцениваю ее для небольшой, но относительно сложной системы, работающей в режиме реального времени, где нас не волнует, как далеко отправляются сообщения или кто / что (в пределах разумного;) их потребляет. Если потребитель сидит на одной машине, пусть будет так. Я бы попробовал и посмотрел, что ты с этим делаешь. Если вы хотите собрать прототип системы, используйте python и библиотеку Pika .

Answer 5

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

Удаляя задержку, создаваемую сетью, вы, вероятно, будете намного более чувствительны к необработанным характеристикам различных реализаций. Поэтому я бы посмотрел на продукты, реализованные на C ++, такие как Qpid или Zeromq.

Qpid может легко достигать 400 000 сообщений в секунду (с сообщениями в 1024 байта) на некотором приличном оборудовании (четырехъядерное ядро). Zeromq, вероятно, будет работать намного лучше, потому что у вас могут быть одноранговые каналы, тогда как Qpid использует архитектуру брокера (с шагом).

Answer 6

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