Modello di gateway API - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Modello di gateway API

Il pattern del gateway API è consigliato se si desidera progettare e creare applicazioni basate su microservizi complesse o di grandi dimensioni con più applicazioni client. Il modello è simile a quellomodello di facciatadalla progettazione orientata agli oggetti, ma fa parte di un instradamento del gateway o proxy inverso del sistema distribuito e utilizza un modello di comunicazione sincrono.

Il modello fornisce un proxy inverso per reindirizzare o instradare le richieste agli endpoint dei microservizi interni. Un gateway API fornisce un singolo endpoint o URL per le applicazioni client e mappa internamente le richieste ai microservizi interni. Un livello di astrazione viene fornito nascondendo alcuni dettagli di implementazione (ad esempio, il nome e la versione della funzione Lambda) e possono anche essere aggiunte funzionalità aggiuntive al servizio di backend, come le trasformazioni di risposta e richiesta, l'autorizzazione all'accesso agli endpoint o il tracciamento.

È consigliabile utilizzare il pattern gateway API se:

  • Il numero di dipendenze per un microservizio è gestibile e non cresce nel tempo.

  • Il sistema di chiamata richiede una risposta sincrona dal microservizio.

  • Hai requisiti di bassa latenza.

  • È necessario esporre un'API per raccogliere dati da più microservizi.

Caso d'uso

In questo caso d'uso, un cliente effettua pagamenti mensili regolari in un sistema assicurativo costituito da quattro microservizi distribuiti come funzioni Lambda («Cliente», «Comunicazione», «Pagamenti» e «Vendite»). Il microservizio «Cliente» aggiorna il database clienti con i dettagli del pagamento mensile. Il microservizio «Vendite» aggiorna il database di vendita con informazioni pertinenti che aiutano il team di vendita a seguire con il cliente le opportunità di cross-selling. Il microservizio «Comunicazione» invia un'e-mail di conferma al cliente dopo che il pagamento è stato elaborato correttamente. Infine, il microservizio «Pagamenti» è il sistema globale utilizzato dal cliente per effettuare il pagamento mensile. Il modello utilizza servizi web per integrare i sottosistemi «Cliente», «Vendite» e «Comunicazione» con il microservizio «Pagamenti».

Ci sono tre sfide nell'utilizzare questo modello per questo caso d'uso:

  • Le chiamate sincrone vengono effettuate ai sistemi a valle, il che significa che qualsiasi latenza causata da questi sottosistemi influisce sul tempo di risposta complessivo.

  • I costi di gestione sono più elevati perché il sistema «Pagamenti» è in attesa di risposte dagli altri microservizi prima di rispondere al sistema chiamante. Il tempo di funzionamento totale è quindi relativamente più alto rispetto a un sistema asincrono.

  • La gestione degli errori e il ritentativo vengono gestiti separatamente per ciascun microservizio all'interno del sistema «Pagamenti», non dai singoli microservizi.

I due esempi seguenti illustrano come utilizzare il pattern del gateway API per integrare i microservizi utilizzando più gateway API o un gateway API.

Gateway API multipli

Nella figura seguente, ogni microservizio ha il proprio gateway API. Il microservizio «Pagamenti» richiama i singoli sistemi e implementa il pattern del gateway API.

Gateway API multipli

Gateway API singolo

Nella figura seguente, ogni microservizio viene distribuito come funzione Lambda, ma tutti i microservizi sono collegati dallo stesso gateway API.

Gateway API multipli