Modello di routing gateway

Instradare le richieste a più servizi o a più istanze del servizio usando un singolo endpoint. Il modello è utile quando si vuole:

• Esporre più servizi in un singolo endpoint e indirizzare al servizio appropriato in base alla richiesta
• Esporre più istanze dello stesso servizio in un singolo endpoint per scopi di bilanciamento del carico o disponibilità
• Esporre versioni diverse dello stesso servizio in un singolo endpoint e instradare il traffico tra le diverse versioni

Contesto e problema

Quando un client deve utilizzare più servizi, più istanze del servizio o una combinazione di entrambe, il client deve essere aggiornato quando i servizi vengono aggiunti o rimossi. Esaminare gli scenari seguenti:

• Più servizi diversi: un'applicazione di e-commerce potrebbe fornire servizi come ricerca, recensioni, carrello, checkout e cronologia degli ordini. Ogni servizio ha un'API diversa con cui il client deve interagire e il client deve conoscere ogni endpoint per connettersi ai servizi. Se un'API viene modificata, è necessario aggiornare anche il client. Se si effettua il refactoring di un servizio in due o più servizi separati, è necessario modificare il codice sia nel servizio che nel client.
• Più istanze dello stesso servizio : il sistema può richiedere l'esecuzione di più istanze dello stesso servizio nella stessa area o in aree diverse. L'esecuzione di più istanze può essere eseguita a scopo di bilanciamento del carico o per soddisfare i requisiti di disponibilità. Ogni volta che un'istanza viene attivata o disattivata per soddisfare la domanda, il client deve essere aggiornato.
• Più versioni dello stesso servizio : come parte della strategia di distribuzione, è possibile distribuire nuove versioni di un servizio insieme alle versioni esistenti. Questa operazione è nota come distribuzioni blu verde. In questi scenari, il client deve essere aggiornato ogni volta che vengono apportate modifiche alla percentuale di traffico instradato alla nuova versione e all'endpoint esistente.

Soluzione

Inserire un gateway davanti a un set di applicazioni, servizi o distribuzioni. Usare il routing delle applicazioni di livello 7 per instradare la richiesta alle istanze appropriate.

Con questo modello, l'applicazione client deve conoscere solo un singolo endpoint e comunicare con un singolo endpoint. Di seguito viene illustrato come il modello di routing del gateway affronti i tre scenari descritti nella sezione contesto e problema.

Più servizi diversi

Il modello di routing del gateway è utile in questo scenario in cui un client utilizza più servizi. Se un servizio viene consolidato, scomposto o sostituito, il client non richiede necessariamente l'aggiornamento. Può continuare a inviare le richieste al gateway e solo il routing cambia.

Un gateway consente anche di astrarre i servizi back-end dai client, permettendo di mantenere semplici le chiamate client e consentendo nel contempo le modifiche ai servizi back-end dietro il gateway. Le chiamate client possono essere instradate al servizio, o ai servizi, che devono gestire il comportamento previsto del client, in modo che sia possibile aggiungere, dividere e riorganizzare i servizi dietro il gateway senza modificare il client.

Più istanze dello stesso servizio

L'elasticità è fondamentale nel cloud computing. I servizi possono essere attivati per soddisfare la domanda crescente o riattivarsi quando la domanda è bassa per risparmiare denaro. La complessità della registrazione e dell'annullamento della registrazione delle istanze del servizio viene incapsulata nel gateway. Il client non è a conoscenza di un aumento o di una diminuzione del numero di servizi.

Le istanze del servizio possono essere distribuite in una o più aree. Il modello Geode illustra in dettaglio come una distribuzione attiva e multiarea può migliorare la latenza e aumentare la disponibilità di un servizio.

Più versioni dello stesso servizio

Questo modello può essere usato per le distribuzioni, consentendo di gestire la modalità di implementazione degli aggiornamenti agli utenti. Quando viene distribuita una nuova versione del servizio, la distribuzione può avvenire in parallelo con la versione esistente. Il routing consente di controllare la versione del servizio presentata ai client, offrendo la flessibilità di scegliere tra diverse strategie di rilascio, ovvero implementazioni incrementali, parallele o complete degli aggiornamenti. È possibile correggere rapidamente eventuali problemi rilevati dopo la distribuzione del nuovo servizio modificando la configurazione nel gateway, senza influire sui client.

Considerazioni e problemi

• Il servizio gateway può introdurre un singolo punto di errore. Assicurarsi che sia progettato correttamente per soddisfare i requisiti di disponibilità. Prendere in considerazione le funzionalità di resilienza e tolleranza di errore nell'implementazione.
• Il servizio gateway può introdurre un collo di bottiglia. Verificare che il gateway offra prestazioni adeguate per gestire il carico e consenta facile scalabilità in base alle proprie aspettative di crescita.
• Eseguire test di carico sul gateway per assicurarsi di non generare errori a catena nei servizi.
• Il routing gateway è di livello 7. Può essere basato su IP, porta, intestazione o URL.
• I servizi gateway possono essere globali o regionali. Frontdoor di Azure è un gateway globale, mentre app Azure lication Gateway è a livello di area. Usare un gateway globale se la soluzione richiede distribuzioni di servizi in più aree. È consigliabile usare gateway applicazione se si dispone di un carico di lavoro a livello di area che richiede un controllo granulare della modalità di bilanciamento del traffico. Ad esempio, si vuole bilanciare il traffico tra le macchine virtuali.
• Il servizio gateway è l'endpoint pubblico per i servizi che si trova di fronte. Valutare la possibilità di limitare l'accesso alla rete pubblica ai servizi back-end, rendendo i servizi accessibili solo tramite il gateway o tramite una rete virtuale privata.

Quando usare questo modello

Usare questo modello quando:

• Un client deve utilizzare più servizi accessibili dietro un gateway.
• Si vuole semplificare le applicazioni client usando un singolo endpoint.
• È necessario eseguire il routing delle richieste da endpoint indirizzabili esternamente a endpoint virtuali interni, ad esempio esponendo le porte in una macchina virtuale agli indirizzi IP virtuali del cluster.
• Un client deve utilizzare i servizi in esecuzione in più aree per i vantaggi della latenza o della disponibilità.
• Un client deve utilizzare un numero variabile di istanze del servizio.
• Si vuole implementare una strategia di distribuzione in cui i client accedono contemporaneamente a più versioni del servizio.

Questo modello potrebbe non essere appropriato quando si ha un'applicazione semplice che usa solo uno o due servizi.

Progettazione del carico di lavoro

Un architetto deve valutare come usare il modello di routing del gateway nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:

Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.

Esempio

Usando Nginx come router, di seguito viene fornito un semplice file di configurazione di esempio per un server che esegue il routing delle richieste per le applicazioni che si trovano in directory virtuali diverse nei vari computer nel back-end.

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

Per implementare il modello di routing del gateway, è possibile usare i servizi di Azure seguenti:

• Istanza di gateway applicazione, che fornisce il routing di livello 7 a livello di area.
• Istanza di Frontdoor di Azure, che fornisce il routing globale di livello 7.

Risorse correlate

• Modello back-end per front-end
• Modello di aggregazione gateway
• Modello di offload gateway