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, Sun의 OpenMQ) - 사용 가능한 모든 AMQP 제공 업체는 매우 새롭습니다.

따라서 관심있는 AMQP 제공 업체를 메시지 전달 프레임 워크와 비교하는 것이 좋습니다. 소켓에 바이트를 읽고 쓴 방식으로 인해 잘 작동하는 무언가를 찢어내는 점이 없습니다 :)

Answer 3

AMQP 표준은 성숙 해지고 JMS와 같은 다른 메시징 표준을 괴롭힌 털이 많은 문제를 해결합니다. 기존 솔루션을 교체 할 가치가 있는지 여부에 대한 질문에 따라 달라집니다. 아마도 시스템이 이미 작동하고 생산 및 고도로 성과를 거두고 있기 때문에 나는 매우 회의적 일 것입니다.

다음과 같은 문제가있는 경우 :

• 상호 운용성이 작동하지 않습니다
• 쉽게 확장 할 수 없습니다
• 성능은 충분하지 않습니다
• 현재 메시징 솔루션은 비싸다 (유지 관리)

필요한 작업을 조사하고 혜택을보다 정확하게 분석해야합니다. 이미 행복하다면 메시징 프레임 워크를 대체하는 것은 투자를 반환하지 않을 것입니다.

Answer 4

신뢰할 수 있고 매우 유연한 (메시징 패턴 측면에서)의 기초로, 이는 기계 내 (즉, 프로세스 간) 및 네트워크 간 작업 시나리오에 사용할 수 있습니다. 0에서 거대한 대역폭의 멀티 네트워크 시스템으로 확장 할 수 있습니다.

나는 현재 메시지가 얼마나 멀리 여행하는지 또는 (이유 내에서) 소비하는 사람을 신경 쓰지 않는 작지만 비교적 복잡한 실시간 시스템에 대해 평가하고 있습니다. 소비자가 같은 기계에 앉아 있다면 그렇게하십시오. 나는 그것을주고 당신이 그것을 만드는 것을 볼 것입니다. 프로토 타입 시스템을 노크하려면 Python과 피카 도서관.

Answer 5

AMQP는 내부적으로 사용되는 것보다 SOA에 대한 안정적인 전송 미들웨어 제품처럼 보입니다.

Answer 6

Machine 내 시나리오의 성능에 주로 관심이 있다면, 어떤 구현을 시도 해야하는지보다 AMQP (와이어 레벨 프로토콜)에 관한 질문이 적습니다.

네트워크가 도입 한 대기 시간을 제거하면 다양한 구현의 원시 성능에 훨씬 더 민감 할 것입니다. 따라서 QPID 또는 ZEROMQ와 같은 C ++로 구현 된 제품을 살펴 봅니다.

QPID는 일부 괜찮은 하드웨어 (쿼드 코어)에서 400,000 메시지/초 (1024 바이트의 메시지 포함)에 쉽게 도달 할 수 있습니다. QPID는 피어 대 피어 채널을 가질 수있는 반면 QPID는 중개인 아키텍처 (단계가있는)를 사용하고 있기 때문에 Zeromq는 아마도 훨씬 더 잘 수행 될 것입니다.