AMQP é adequado tanto como um intra e inter-máquina de barramento de software?

Question

Eu estou tentando obter minha cabeça em torno AMQP . Parece ótimo para inter-máquina (cluster, LAN, WAN) a comunicação entre aplicações, mas não tenho certeza se ele é adequado (em arquitetura, e os termos de implementação atuais) para uso como um barramento de software dentro de uma máquina.

valeria a pena puxar para fora uma mensagem de alto desempenho corrente que passa estrutura para substituí-lo com AMQP, ou isso é cair na mesma armadilha que RPC por borrar a distinção entre a comunicação local e não local?

Eu também sou cauteloso com os impactos da utilização de uma tecnologia WAN para comunicações intra-máquina de desempenho, embora isso possa ser mais uma preocupação implementação de arquitetura.

histórias da guerra seria apreciada.

Answer 1

AMQP não é um quadro RPC. Ele fornece os blocos de construção para as coisas modelo como filas compartilhadas, RPC, pubsub etc. mas não definiu nenhum modo específico para usá-lo.

Se você deseja particionar sua aplicação (tornando-distribuível no caminho) e fio-lo juntamente com AMQP Eu acho que é a tecnologia certa. Pode haver mais rápidas alternativas embora, mas provavelmente nenhum tão genérico como AMQP.

Answer 2

AMQP é uma especificação para que você estaria comparando maçãs com laranjas realmente. Não há que muitos de produção provedores pronto AMQP lá fora realmente; nenhum dos principais provedores de mensagens ou fornecedores de suporte AMQP no momento da escrita (por exemplo, IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq de Sun) - para que todos os prestadores de AMQP disponíveis são muito novo <. / p>

Então, eu recomendo comparando tudo o provedor AMQP você está interessado em sua passagem de mensagens quadro. Não há nenhum ponto rasgando algo que é bom trabalhar apenas por causa da forma como ele lê e escreve bytes a um soquete:)

Answer 3

O padrão AMQP está ficando amadurecer e resolve alguns dos problemas cabeludos que têm atormentado outros padrões de mensagens como JMS. À sua pergunta se vale a pena substituir uma solução existente, eu diria que ele depende. Eu ficaria muito cético, desde que, presumivelmente, o sistema já está funcionando, na produção e com alto desempenho.

Se você tiver problemas como:

• A interoperabilidade não está funcionando
• Não é possível dimensionar facilmente
• O desempenho não é bom o suficiente
• A solução de mensagens atual é caro (para manter)

Você deve investigar o trabalho necessário e analisar os benefícios de forma mais precisa. Se você já é feliz, substituindo um quadro de mensagens não vai retorno sobre o investimento.

Answer 4

Como base para um, extremamente flexível (em termos de padrões de mensagens) que pode ser usado para muitos cenários de mensagens, inter-rede, tanto intra-máquina (isto é, inter-processo) e de confiança. Ele pode escalar todo o caminho de zero a enormes de banda larga, sistemas multi-rede.

Estou avaliando atualmente para um sistema em tempo real perto pequeno, mas relativamente complexo em que não se importam quão longe as mensagens viajar ou quem / o que (dentro da razão;) é consumi-los. Se um consumidor está sentado na mesma máquina que assim seja. Eu daria um ir e ver o que você faz dela. Se você quiser bater juntos um protótipo de sistema, uso python eo Pika biblioteca.

Answer 5

AMQP parece mais com uma oferta de transporte middleware confiável para SOA do que algo para ser usado internamente.

Answer 6

Se você está interessado principalmente em performances em um cenário intra-máquina, a questão é menos sobre AMQP (que é apenas um protocolo de nível fio) do que sobre qual implementação você deve tentar.

Ao remover a latência introduzida pela rede, você provavelmente vai ser muito mais sensíveis às performances matérias dos vários implementação. Portanto, gostaria de olhar para os produtos implementados em C ++, como Qpid ou Zeromq.

Qpid pode facilmente chegar a 400 000 mensagens / segundo (com mensagens de 1024 bytes) em algum hardware decente (quad core). Zeromq provavelmente irá executar muito melhor, porque você pode ter peer to canais de pares enquanto Qpid está usando uma arquitetura broker (que tinha um passo).