Architettura orientata ai servizi: AMQP o HTTP

Question

Un po 'di background.

Applicazione Django monolitica molto grande. Tutti i componenti utilizzano lo stesso database. Abbiamo bisogno di separare i servizi in modo da poter aggiornare in modo indipendente alcune parti del sistema senza influenzare il resto.

Usiamo RabbitMQ come broker per Celery.

In questo momento abbiamo due opzioni:

1. servizi HTTP utilizzando un'interfaccia REST.
2. JSONRPC su AMQP a un servizio di ciclo di eventi

La mia squadra sta appoggiandosi a verso HTTP perché è quello che hanno familiarità con, ma credo che i vantaggi di utilizzare RPC su AMQP superano di gran lunga esso.

AMQP ci fornisce le funzionalità per aggiungere facilmente bilanciamento del carico e alta disponibilità, con consegne di messaggi garantite.

Considerando che con HTTP dobbiamo creare wrapper client HTTP per lavorare con le interfacce REST, dobbiamo mettere in un bilanciatore di carico e impostare che l'infrastruttura in modo da avere HA ecc

Con AMQP posso solo genera un'altra istanza del servizio, si collegherà alla stessa coda delle altre istanze e bam, HA e bilanciamento del carico.

Mi manca qualcosa con i miei pensieri su AMQP?

Answer 1

Dapprima,

• REST, RPC - architettura modelli, AMQP - wire-livello e HTTP - protocollo applicativo che corrono su TCP/IP
• AMQP è un protocollo specifico quando HTTP - generale protocollo -purpose, quindi, HTTP ha accidenti overhead elevato confronto con AMQP
• natura AMQP è asincrona dove la natura HTTP è sincrona
• sia per il riposo e l'uso RPC serializzazione dei dati, che è formato da te e dipende delle infrastrutture. Se stai usando python ovunque, penso che tu possa usare la serializzazione nativa di python - pickle che dovrebbe essere più veloce di JSON o di qualsiasi altro formato.
• sia HTTP + REST e AMQP + RPC può essere eseguito in ambiente eterogeneo e/o distribuiti

Quindi, se si sceglie cosa usare: HTTP + REST o AMQP + RPC, la risposta è in realtà oggetto di infrastrutture complessità e utilizzo delle risorse. Senza requisiti specifici entrambe le soluzioni funzioneranno bene, ma preferirei fare qualche astrazione per poter passare da una all'altra in modo trasparente.

Hai detto che il tuo team ha familiarità con HTTP ma non con AMQP. Se il tempo di sviluppo è un momento importante hai una risposta.

Se si desidera creare un'infrastruttura HA con una complessità minima, suppongo che il protocollo AMQP sia ciò che si desidera.

Ho avuto un'esperienza con ciascuno di essi e vantaggi dei servizi RESTful sono:

• hanno ben mappati-on interfaccia web
• persone hanno familiarità con loro
• facile per eseguire il debug (a causa di genere scopo di HTTP)
• facile fornire API a servizi di terze parti.

Vantaggi della soluzione di AMQP basata su:

• dannatamente veloce
• flessibile
• facile da mantenere
• facile da scalare
• costo-efficacia (in termini di risorse utilizzo significato)

Nota che puoi fornire API RESTful a servizi di terze parti sulla tua API basata su AMQP mentre REST non è un protocollo ma piuttosto un paradigma, ma dovresti pensarci a costruire l'api RPC AQMP. L'ho fatto in questo modo per fornire API a servizi esterni di terze parti e fornire l'accesso all'API su quelle parti dell'infrastruttura che funzionano su codebase vecchio o dove non è possibile aggiungere il supporto AMQP.

Se ho ragione, la tua domanda riguarda come organizzare meglio la comunicazione tra le diverse parti del tuo software, non come fornire un'API agli utenti finali.

Se si dispone di un progetto a carico elevato, RabbitMQ è una buona parte del software e si può facilmente aggiungere un numero qualsiasi di lavoratori che funzionano su macchine diverse. Inoltre ha mirroring e clustering fuori dalla scatola. E ancora una volta, RabbitMQ è costruito su Erlang OTP, che è una piattaforma affidabile e stabile ... (bla-bla-bla), non solo per il marketing ma anche per gli ingegneri. Ho riscontrato un problema con RabbitMQ una sola volta quando i registri di nginx occupavano tutto lo spazio su disco nella stessa partizione in cui è in esecuzione RabbitMQ.

Answer 2

L'ironia della soluzione OP ha dovuto accettare è, AMQP o altre soluzioni MQ vengono spesso utilizzate per isolare i chiamanti dalla inaffidabilità intrinseca dei servizi solo HTTP - per fornire un certo livello di timeout & riprovare la logica e la persistenza dei messaggi in modo il chiamante non deve implementare il proprio codice di isolamento HTTP. Un sottile gateway o adattatore HTTP su un core AMQP affidabile, con l'opzione di passare direttamente ad AMQP usando un protocollo client più affidabile come JSONRPC, sarebbe spesso la soluzione migliore per questo scenario.