AMQP è adatto sia come bus software interno che inter-macchina?

Question

Sto cercando di capire AMQP . Sembra perfetto per la comunicazione tra macchine (cluster, LAN, WAN) tra le applicazioni, ma non sono sicuro che sia adatto (in termini architetturali e di implementazione attuali) per l'uso come bus software all'interno di una macchina.

Varrebbe la pena estrarre un framework di passaggio di messaggi ad alte prestazioni per sostituirlo con AMQP, o sta rientrando in stessa trappola di RPC confondendo la distinzione tra comunicazione locale e non locale?

Sono anche diffidente nei confronti dell'impatto sulle prestazioni dell'utilizzo di una tecnologia WAN per le comunicazioni intra-macchina, sebbene ciò possa essere più un problema di implementazione che di architettura.

Le storie di guerra sarebbero apprezzate.

Answer 1

AMQP non è un framework RPC. Fornisce i mattoni per modellare cose come code condivise, RPC, pubsub ecc. Ma non impone alcun modo specifico per usarlo.

Se vuoi partizionare la tua applicazione (rendendola distribuibile lungo il percorso) e collegarla insieme ad AMQP penso che sia la tecnologia giusta. Potrebbero esserci alternative più veloci, ma probabilmente nessuna così generica come AMQP.

Answer 2

AMQP è una specifica, quindi dovresti davvero confrontare le mele con le arance. Non ci sono molti fornitori AMQP pronti per la produzione là fuori davvero; nessuno dei principali fornitori o fornitori di messaggistica supporta AMQP al momento della stesura (ad es. IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq da Sun) - quindi tutti i provider AMQP disponibili sono piuttosto nuovi.

Quindi consiglierei di confrontare qualsiasi provider AMQP a cui sei interessato con il tuo framework di passaggio messaggi. Non ha senso strappare qualcosa che funziona bene solo per il modo in cui legge & amp; scrive byte in un socket :)

Answer 3

Lo standard AMQP sta diventando maturo e risolve alcuni dei problemi pelosi che hanno afflitto altri standard di messaggistica come JMS. Alla tua domanda se vale la pena sostituire una soluzione esistente, direi che dipende. Sarei molto scettico, poiché presumibilmente il sistema funziona già, in produzione e altamente performante.

Se hai problemi come:

• L'interoperabilità non funziona
• Impossibile ridimensionare facilmente
• Le prestazioni non sono abbastanza buone
• L'attuale soluzione di messaggistica è costosa (da mantenere)

Dovresti indagare sul lavoro richiesto e analizzare i benefici in modo più preciso. Se sei già soddisfatto, la sostituzione di un framework di messaggistica non comporta un ritorno sull'investimento.

Answer 4

Come base per un sistema affidabile, estremamente flessibile (in termini di modelli di messaggistica), può essere utilizzato per molti scenari di messaggistica, sia all'interno della macchina (cioè tra processi) che tra reti. Può scalare da zero a sistemi multi-rete enormi, ad alta larghezza di banda.

Attualmente lo sto valutando per un piccolo, ma relativamente complesso sistema quasi in tempo reale in cui non ci importa quanto lontano viaggiano i messaggi o chi / cosa (entro limiti ragionevoli) li sta consumando. Se un consumatore è seduto sulla stessa macchina, così sia. Ci proverei e vedrei cosa ne pensi. Se vuoi mettere insieme un prototipo di sistema, usa python e la Pika .

Answer 5

AMQP sembra più un'offerta di middleware di trasporto affidabile per SOA che qualcosa da utilizzare internamente.

Answer 6

Se sei principalmente interessato alle prestazioni in uno scenario intra-macchina, la domanda è meno su AMQP (che è solo un protocollo a livello di filo) rispetto a quale implementazione dovresti provare.

Rimuovendo la latenza introdotta dalla rete, probabilmente sarai molto più sensibile alle prestazioni grezze delle varie implementazioni. Pertanto, vorrei esaminare i prodotti implementati in C ++ come Qpid o Zeromq.

Qpid può facilmente raggiungere 400000 messaggi / secondo (con messaggi di 1024 byte) su un hardware decente (quad core). Zeromq probabilmente funzionerà molto meglio perché puoi avere canali peer to peer mentre Qpid sta usando un'architettura broker (che ha avuto un passo).