Modello di aggregazione del gateway

Usare un gateway per aggregare più richieste singole in un'unica richiesta. Questo modello è utile quando un client deve effettuare più chiamate a diversi sistemi back-end per eseguire un'operazione.

Contesto e problema

Per eseguire una singola attività, un client potrebbe dover effettuare più chiamate a vari servizi back-end. Un'applicazione che si basa su molti servizi per eseguire un'attività deve impiegare le risorse per ogni richiesta. Quando vengono aggiunte nuove funzionalità o servizi all'applicazione, sono necessarie richieste aggiuntive, aumentando ulteriormente i requisiti delle risorse e le chiamate di rete. Questo eccessivo scambio di richieste e risposte tra un client e un back-end può influire negativamente sulle prestazioni e sulla scalabilità dell'applicazione. Le architetture di microservizi hanno reso questo problema più comune perché le applicazioni basate su molti servizi più piccoli hanno un numero più elevato di chiamate tra servizi.

Nel diagramma seguente il client invia richieste a ogni servizio (numerato 1, 2 e 3). Ogni servizio elabora la richiesta e restituisce una risposta all'applicazione (numerata 4, 5 e 6). L'invio di singole richieste in questo modo su una rete cellulare con una latenza elevata è inefficiente e può causare perdita di connettività o risposte incomplete. Ogni richiesta può essere eseguita in parallelo. Tuttavia, l'applicazione deve comunque inviare, attendere ed elaborare i dati per ogni richiesta in connessioni separate, aumentando così la probabilità di errore.

Diagramma dei problemi per il modello di aggregazione del gateway.

Soluzione

Usa un gateway per ridurre l'eccessivo scambio di richieste tra il client e i servizi. Il gateway riceve richieste client, invia richieste ai vari sistemi back-end e aggrega i risultati prima di inviarli al client.

Questo modello può ridurre il numero di richieste che l'applicazione effettua ai servizi back-end e migliorare le prestazioni dell'applicazione su reti a latenza elevata.

Nel diagramma seguente l'applicazione invia una richiesta al gateway (1) La richiesta contiene un pacchetto di richieste aggiuntive. Il gateway scompone queste richieste ed elabora ogni richiesta inviandola al servizio pertinente (2). Ogni servizio restituisce una risposta al gateway (3). Il gateway combina le risposte da ogni servizio e invia la risposta all'applicazione (4). L'applicazione esegue una richiesta singola e riceve solo una risposta singola dal gateway.

Diagramma della soluzione per il modello di aggregazione del gateway.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

  • Il gateway non deve introdurre l'accoppiamento del servizio tra i servizi back-end.

  • Il gateway deve trovarsi vicino ai servizi back-end per ridurre la latenza il più possibile.

  • Il servizio gateway potrebbe introdurre un singolo punto di errore (SPoF). Assicurarsi che il gateway sia progettato correttamente per soddisfare i requisiti di disponibilità dell'applicazione.

  • Il gateway potrebbe introdurre un collo di bottiglia. Assicurarsi che il gateway abbia prestazioni adeguate per gestire il carico corrente e che possa essere ridimensionato per soddisfare la crescita prevista.

  • Eseguire test di carico sul gateway per assicurarsi di non introdurre errori a catena per i servizi.

  • Implementa un'architettura resiliente mediante tecniche come bulkhead, circuit breaker, nuovi tentativi e timeout.

  • Se una o più chiamate al servizio richiedono troppo tempo, potrebbe essere accettabile andare in timeout e restituire un insieme parziale di dati. Prendere in considerazione la modalità con cui l'applicazione gestirà questo scenario.

  • Utilizzare operazioni di input/output (I/O) asincrone per garantire che un ritardo nel backend non provochi problemi di prestazioni nell'applicazione.

  • Implementare la traccia distribuita usando ID di correlazione per tenere traccia di ogni singola chiamata.

  • Monitorare le metriche delle richieste e le dimensioni delle risposte.

  • Valutare la restituzione di dati memorizzati nella cache come strategia di failover per gestire gli errori.

  • Invece di integrare l'aggregazione nel gateway, valuta di collocare un servizio di aggregazione dietro il gateway. È probabile che l'aggregazione delle richieste abbia requisiti di risorse diversi rispetto ad altri servizi nel gateway e potrebbe influire sulle funzionalità di routing e offload del gateway.

Quando usare questo modello

Usare questo modello quando:

  • Un client deve comunicare con più servizi back-end per eseguire un'operazione.

  • Il client potrebbe usare reti con una latenza significativa, ad esempio reti cellulari.

Questo modello potrebbe non essere adatto quando:

  • Si desidera ridurre il numero di chiamate tra un client e un servizio singolo tra più operazioni. In questo scenario, l'aggiunta di un'operazione batch al servizio potrebbe essere più adatta.

  • Il client o l'applicazione si trova vicino ai servizi back-end e la latenza non è un fattore significativo.

Progettazione del carico di lavoro

Valutare come usare il modello di aggregazione del gateway nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro Come questo modello supporta gli obiettivi di pilastro
decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto. Con questa topologia, è possibile spostare la gestione degli errori temporanei da un'implementazione distribuita tra i client a un'implementazione centralizzata.

- Raccomandazioni per la gestione degli errori temporanei
Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. Questa topologia spesso riduce il numero di punti di tocco che un client ha con un sistema, riducendo così l'area di attacco pubblica e i punti di autenticazione. I back-end aggregati possono rimanere completamente isolati dai client a livello di rete.

- Segmentazione SE:04
- SE:08 Proteggere le risorse
L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. Questo modello consente alla logica back-end di evolversi indipendentemente dai client. Questo disaccoppiamento offre la flessibilità necessaria per modificare le implementazioni concatenate dei servizi, o persino le fonti di dati, senza dover modificare i punti di contatto del client.

- Strumenti e processi di OE:04
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice. Questa progettazione può comportare una latenza inferiore rispetto a una progettazione in cui il client stabilisce più connessioni. La memorizzazione nella cache nelle implementazioni delle aggregazioni riduce al minimo le chiamate ai sistemi back-end.

- PE:03 Selezionare i servizi
- Prestazioni dei dati PE:08

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

Si consideri un'applicazione basata su microservizi che fornisce un'esperienza di riepilogo degli ordini per un cliente. Quando un utente apre una pagina di ordine, l'applicazione deve recuperare i dati da più servizi back-end, ad esempio un servizio di ordine, un servizio di spedizione e un servizio profilo cliente.

In un'architettura di microservizi, questi servizi vengono implementati e distribuiti in modo indipendente. Senza aggregazione, il client deve chiamare direttamente ogni servizio, aumentando la latenza e la complessità.

Per risolvere questo problema, l'applicazione usa Gestione API di Azure come livello di aggregazione del gateway. Il client invia una singola richiesta a un'operazione di Gestione API che funge da agente di raccolta per informazioni sugli ordini. Gestione API chiama quindi le API back-end di supporto e restituisce una risposta unificata al client.

È possibile implementare questa composizione leggera usando i criteri send-request di Gestione API per recuperare i dati da più servizi e costruire una risposta combinata. In questo esempio i servizi back-end vengono eseguiti in un ambiente App contenitore di Azure e si distribuisce ogni servizio back-end come app contenitore che rimane nascosta dall'accesso diretto al client.

Diagramma che mostra una richiesta client che passa attraverso Gestione API ai servizi di ordine, spedizione e profilo cliente in un ambiente app.

Scaricare un file di Visio di questa architettura.

Il flusso della richiesta segue questa procedura:

  1. Il client invia una richiesta a un endpoint di riepilogo degli ordini esposto tramite Gestione API.

  2. La gestione delle API applica un criterio che raccoglie i dati relativi agli ordini, alle spedizioni e ai profili dei clienti dai servizi back-end.

  3. API Management combina le risposte del back-end in un singolo payload di riepilogo dell'ordine.

  4. Gestione API restituisce la risposta aggregata al client.

Introducendo questo livello di aggregazione, la soluzione riduce i round trip da client a servizio e semplifica le interazioni client. Questo livello diventa responsabile di gestire in modo corretto i servizi back-end che non rispondono e di evitare che i guasti si propaghino a cascata nell'intera risposta aggregata. Rafforza i criteri di gestione delle API usando timeout per richiesta, gestione condizionale degli errori e circuit breaker.

Se una delle chiamate al back-end va in timeout o restituisce un errore, API Management può applicare il comportamento più adatto all'operazione. Ad esempio, potrebbe restituire una risposta parziale quando i dati mancanti sono accettabili oppure l'intera richiesta potrebbe non riuscire quando sono necessari dati di ordine completi e coerenti. Prendere questa decisione esplicita nella progettazione dei criteri in modo che i client verifichino un comportamento prevedibile.

Questo approccio funziona bene quando il gateway esegue operazioni leggere di composizione, trasformazione e assemblaggio della risposta. Se l'aggregazione richiede logica di dominio personalizzata, trasformazioni complesse o orchestrazione a esecuzione prolungata, posizionare tale funzionalità in un servizio personalizzato dedicato dietro il gateway.

Per il monitoraggio, raccogliere i dati di telemetria nel percorso di richiesta completo in modo da poter correlare il comportamento di Gestione API alla latenza back-end. Questa visibilità è importante in un modello di aggregazione del gateway perché una singola operazione client dipende da più chiamate back-end e gli errori o le risposte lente in qualsiasi dipendenza possono influire sul risultato aggregato finale. Usare Monitoraggio di Azure come piattaforma di osservabilità centrale. Raccogli log e metriche di API Management relativi al gateway e al percorso di esecuzione dei criteri e abilita il monitoraggio per Container Apps per acquisire log e metriche delle applicazioni dalle app contenitore back-end. Instradare la gestione API e la telemetria back-end a un'area di lavoro Log Analytics per operazioni unificate di query, avviso e risoluzione dei problemi. Con questi dati di telemetria è possibile rilevare i modelli di timeout, identificare la dipendenza back-end che ha causato una risposta parziale o non riuscita e creare avvisi per una latenza o una frequenza di errore elevate.

Passaggi successivi

  • Last updated on