Quando è appropriato usare AMQP?

Question

Nel mio precedente lavoro ho utilizzato i vantaggi di AMQP, ma non ero coinvolto nello sviluppo del sottoprogetto rabbitMQ. Nel mio attuale lavoro, voglio occuparmi di integrare una delle implementazioni AMQP (probabilmente rabbitMQ). Il problema qui che devo convincere il mio capo a usare AMQP.

Sto leggendo "RabbitMQ in Action" e Videla ha scritto che AMQP potrebbe migliorare qualsiasi sistema, ma non vedo come posso migliorare il mio progetto. Utilizziamo solo 2 server che effettuano chiamate API intermedie, quindi al momento non abbiamo problemi di scalabilità. Abbiamo a che fare con flussi di denaro reale e questo significa che abbiamo bisogno di una conferma di successo per ogni operazione, cioè non posso mettere in fila l'incarico e "dimenticarlo". Quali vantaggi potrebbe avere AMQP in questo caso?

Potresti fornire esempi di esempi reali per sistemi relativamente piccoli quando non hai bisogno di scalare a fatica? Si prega di omettere le situazioni standard di "logging" e "broadcast message" :)

Answer 1

Sembra che tutto ciò che serve sia RPC. Coniglio non è noto per RPC but it actually does davvero un buon lavoro perché:

• È possibile effettuare molti messaggi di transazione (vale a dire tutti in un'unica operazione)
• La sua piattaforma, lingua e formato del protocollo agnostica (per esempio, si potrebbe inviare binario su
• Grazie all'idea del broker è possibile aggiungere facilmente più server per gestire le procedure.
• Si può facilmente vedere il flusso dei messaggi e la velocità con interfaccia di amministrazione di RabbitMQ
• RabbitMQ è una sorta di inversione del controllo a livello di architettura
• Nel RabbitMQ il messaggio è il contratto ... non il procedimento. Questo è il modo giusto per farlo.

Ora ti permette di confrontare questo da dire SOAP:

• SOAP non ti dà un broker o di routing in modo che tutti i tuoi recide hanno bisogno di sapere gli uni degli altri. Non posso dirvi quanto sia fastidioso dover andare a utilizzare l'indirizzo IP del plugin per dev, stadiazione, produzione.
• SOAP non fornisce transazioni. Devi farlo da solo.
• SOAP è necessario utilizzare XML
• Ci sono più client RabbitMQ affidabili rispetto ai client SOAP. La compatibilità SOAP è un PITA.
• SOAP si ha il messaggio e l'endpoint. In alcuni casi questo è un professionista.

Non è necessario utilizzare RabbitMQ per utilizzare l'idea di eventbus/messagebus. Personalmente non realizzerei alcun tipo di app, perché passare da puro RPC sincrono a un eventbus/un messagebus asincrono richiede molto lavoro. Meglio farlo fin dall'inizio.