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

Question

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

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

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

Я был бы признателен за рассказы о войне.

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 довольно новы. / р>

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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