Microservices REST o AMQP, quale caso

Scartando REST, perdi molto più che HATEOAS. Se i tuoi microservizi sono pubblici (ed è una buona idea che siano pubblici o almeno tendano ad essere pubblici un giorno¹), utilizzare 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 con il servizio è molto limitata: posso usare CURL per fare qualsiasi richiesta ad Amazon S3; cosa dovrei installare sulla mia macchina se voglio giocare con una variante AMQP di S3?

• Il debug di REST e SOAP è facile. Seguo semplicemente gli scambi HTTP e li analizzo. Non sono sicuro quali strumenti dovrei usare per vedere per eseguire il debug degli scambi AMQP.

AMQP è ottimo, ma è fatto per uno scopo molto specifico di scambi basati su eventi. Mentre è tecnicamente possibile eseguire 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 solo le cose più difficili di quanto debbano essere: se devo recuperare un backup di file da Amazon S3 perché quello locale è 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,

• Memorizzazione di una fattura,

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

• Elaborazione di tutte le fatture da settembre e notifica all'app quando il rapporto è pronto per essere visualizzato (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 relative al danneggiamento dei backup a tutti coloro che potrebbero essere interessati, ad esempio il personale 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 gli altri, la possibilità di aggiungere gli utenti senza modificare l'applicazione che tiene traccia dei backup e attiva l'avviso quando trova uno danneggiato.}

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

Usa entrambi.

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

AMQP è ottimo per processi, eventi e orchestrazione di microservizi a lungo termine.

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

AMPQ può funzionare bene esposto su Websockets, che può sembrare praticamente un endpoint REST se si strizza l'occhio a esso.

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

Se stai scrivendo un'architettura di back-end in cui i servizi vengono utilizzati solo da te stesso, puoi utilizzare qualsiasi protocollo tu voglia: non sei più vincolato dall'uso di uno che è così interoperabile. Puoi usare un MQ o qualcosa di più strettamente accoppiato e performante. Quale si utilizza dipende dal caso d'uso, un bus di messaggi è molto buono per un insieme distribuito di servizi che elaborano dati in cui il cliente non si cura di chi riceve i messaggi che invia.

AMQP supporta anche la comunicazione point-to-point (ad esempio, vedi il tutorial python-qpid-proton ). Potresti implementare un'interfaccia RESTful usando questo, poiché REST != HTTP.

AMQP funziona anche molto meglio di HTTP.