Microservizi REST o AMQP, in questo caso

Ho letto molti articoli sull'architettura dei microservizi e mi chiedevo quando usare AMQP o REST.

Ho letto che l'accoppiamento lento tra i servizi è una buona cosa e in questo caso AMQP sembra essere una buona scelta. Ma se utilizziamo AMQP, ciò significa che non abbiamo più bisogno degli endpoint REST (ma significa che perdiamo il concetto HATEOAS).

Ma REST è davvero un buon modo per costruire i miei servizi? Perché non userò alcun endpoint ... Nel qual caso uno è migliore dell'altro?

Quando dovrei usare l'uno o l'altro?

Eliminando REST, perdi molto di più di un semplice HATEOAS. Se i tuoi microservizi sono pubblici (ed è una buona idea che siano pubblici o almeno tendano ad essere pubblici un giorno¹), l'utilizzo di qualsiasi cosa diversa da REST e SOAP sarebbe problematico:

• Alcuni sviluppatori non hanno mai usato AMQP,

• Alcuni hanno usato AMQP, ma spesso hanno molta più familiarità con REST e SOAP,

• Le librerie AMQP per alcune lingue non sono particolarmente semplici,

• La sperimentazione manuale del servizio è molto limitata: posso usare CURL per fare qualsiasi richiesta ad Amazon S3; cosa devo installare sul mio computer se voglio giocare con una variante AMQP di S3?

• Il debug di REST e SOAP è semplice. Traccio solo gli scambi HTTP e li analizzo. Non sono sicuro di quali strumenti dovrei usare per eseguire il debug degli scambi AMQP.

AMQP è eccezionale, ma è fatto per uno scopo molto specifico di scambi basato su eventi. Mentre è tecnicamente possibile fare RPC con AMQP, non è il suo scopo principale.

Anche l'aspetto asincrono è importante. A volte è un vantaggio: non voglio bloccare l'interfaccia utente di un'app mentre faccio richieste ai server. A volte, rende le cose più difficili del necessario: se devo ripristinare un backup di file da Amazon S3 perché quello locale è stato danneggiato e quindi ripristinare il backup, il mio file batch ha necessariamente bisogno di CURL per terminare il suo lavoro prima di continuare, e un'operazione sincrona (con un timeout specifico) ha perfettamente senso.

Mantieni REST per le operazioni primarie:

• Ottenere un prodotto,

• Archiviazione di una fattura,

e utilizzare AMQP per le attività in cui la messaggistica ha effettivamente senso:

• Elaborazione di tutte le fatture da settembre e notifica all'app quando il report è pronto per essere mostrato (dato che l'operazione richiede in genere da due a dieci minuti),

  ^{Il vantaggio di AMQP qui è il suo aspetto asincrono. Una richiesta HTTP in sospeso per dieci minuti ha buone probabilità di causare un timeout e altri problemi.}

• Invio delle informazioni che i backup sono stati danneggiati a tutti coloro che potrebbero essere interessati, come le persone di supporto, gli amministratori del database, il team di monitoraggio, gli sviluppatori dell'applicazione che utilizza questo database, ecc.

  ^{Il vantaggio di AMQP qui è, tra l'altro, la possibilità di aggiungere gli abbonati senza modificare l'applicazione che tiene traccia dei backup e attiva l'avviso quando ne trova uno danneggiato.}

^{¹ Un servizio Web pubblico non è necessariamente utilizzato da utenti esterni a un'azienda. Nelle aziende di grandi o medie dimensioni, il tuo servizio è spesso utilizzato da altre divisioni della stessa azienda e ha gli stessi requisiti di quello che verrebbe utilizzato da terze parti: dovrebbe diffidare di qualsiasi chiamata (il fatto che un ragazzo che non hai mai sentito parlare di chi chiama il tuo servizio funziona nella stessa azienda che fai non significa che non sfrutterà i suoi problemi di sicurezza), dovrebbe essere documentato correttamente (perché lo stesso ragazzo indiano non conosce necessariamente il tuo numero di telefono e non necessariamente conoscere l'inglese), ecc.}

Usali entrambi.

I servizi Web JSON in stile REST sono ottimi per l'interoperabilità con javascript, ios ecc

AMQP è ideale per processi, eventi e orchestrazioni di microservizi di lunga durata.

Ma entrambi sono solo wrapper di comunicazione per il servizio effettivo, è possibile esporre lo stesso servizio in più modi e probabilmente dovrebbe.

AMPQ può funzionare ben esposto su Websocket, che può sembrare un endpoint REST se lo osservi.

REST è una tecnologia standard particolarmente adatta all'interoperabilità tra i componenti: questa è la parte fondamentale, ottima per creare un servizio Web che qualcun altro può utilizzare. Tuttavia, soffre dei soliti problemi di tale interoperabilità in quanto è meno efficiente di un protocollo personalizzato.

Se stai scrivendo un'architettura back-end in cui i servizi vengono consumati solo da te stesso, puoi utilizzare qualsiasi protocollo ti piaccia - non sei più vincolato usando uno così interoperabile. Puoi usare un MQ o qualcosa di più strettamente accoppiato e performante. Quale utilizzi dipende dal tuo caso d'uso, un bus di messaggi è ottimo per un set distribuito di servizi che elabora dati in cui al cliente non importa chi riceve i messaggi che invia.

AMQP supporta anche la comunicazione punto-punto (ad esempio, vedere il python-qpid-protontutorial). È possibile implementare un'interfaccia RESTful utilizzando quella, dal REST !=HTTP.

AMQP ha anche prestazioni molto migliori di HTTP.