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 composizione delle API
Questo modello utilizza un compositore, o aggregatore di API, per implementare una query richiamando singoli microservizi proprietari dei dati. Quindi combina i risultati eseguendo un join in memoria.
Il diagramma seguente illustra come viene implementato questo modello.
Il diagramma mostra il flusso di lavoro seguente:
-
Un gateway API serve l'API «/customer», che dispone di un microservizio «Ordini» che tiene traccia degli ordini dei clienti in un database Aurora.
-
Il microservizio «Support» tiene traccia dei problemi di assistenza clienti e li archivia in un database Amazon OpenSearch Service.
-
Il microservizio CustomerDetails "" mantiene gli attributi del cliente (ad esempio, indirizzo, numero di telefono o dettagli di pagamento) in una tabella DynamoDB.
-
La funzione «GetCustomer» Lambda esegue le API per questi microservizi ed esegue un join in memoria sui dati prima di restituirli al richiedente. Ciò consente di recuperare facilmente le informazioni sui clienti in una sola chiamata di rete all'API rivolta all'utente e mantiene l'interfaccia molto semplice.
Il modello di composizione delle API offre il modo più semplice per raccogliere dati da più microservizi. Tuttavia, l'utilizzo del modello di composizione dell'API presenta i seguenti svantaggi:
-
Potrebbe non essere adatto per query complesse e set di dati di grandi dimensioni che richiedono join in memoria.
-
L'intero sistema diventa meno disponibile se si aumenta il numero di microservizi collegati all'API Composer.
-
L'aumento delle richieste di database crea più traffico di rete, con un conseguente aumento dei costi operativi.
