Panoramica della gestione avanzata del traffico

Questo documento è destinato agli amministratori di mesh o di piattaforme e agli sviluppatori di servizi che hanno un livello di familiarità intermedio o avanzato con i concetti di Traffic Director e mesh di servizi e che determinano e configurano la modalità di gestione del traffico in un deployment di Traffic Director. Questo documento riguarda solo le API di routing dei servizi. Se il deployment di Traffic Director utilizza le API di bilanciamento del carico legacy, consulta Panoramica della gestione avanzata del traffico per le API di bilanciamento del carico. Tieni presente che le funzionalità di bilanciamento del carico globale di Traffic Director sono disponibili indipendentemente dall'API utilizzata.

Traffic Director offre funzionalità avanzate di gestione del traffico che offrono un controllo granulare sulla modalità di gestione del traffico. Traffic Director supporta i seguenti casi d'uso:

  • Routing granulare del traffico delle richieste a uno o più servizi.
  • Suddivisione del traffico in base alla ponderazione per distribuire il traffico tra più servizi.
  • Criteri di mirroring del traffico che inviano richieste a un servizio di debug e copiano in un altro. Il mirroring del traffico non è supportato con la risorsa TCPRoute o TLSRoute.
  • Distribuzione ottimizzata del traffico nei backend di un servizio per un migliore bilanciamento del carico.

Queste funzionalità avanzate di gestione del traffico ti consentono di raggiungere i tuoi obiettivi di disponibilità e prestazioni. Uno dei vantaggi dell'utilizzo di Traffic Director per questi casi d'uso è che puoi aggiornare la modalità di gestione del traffico senza dover modificare il codice dell'applicazione.

La gestione del traffico in un mesh di servizi Traffic Director si basa sulle seguenti risorse:

  • Mesh, che identifica il mesh di servizi e rappresenta il componente responsabile dell'inoltro del traffico e dell'applicazione dei criteri. La risorsa Mesh identifica anche la porta di intercettazione del traffico.
  • Gateway, che identifica i proxy centrali e rappresenta il componente che rimane in ascolto su un elenco di coppie indirizzo:porta IP, inoltra il traffico e applica i criteri.
  • Risorsa Route, che può essere di vari tipi e che contiene informazioni di routing del traffico per il mesh. Le risorse Route identificano i nomi host e le porte che i client possono utilizzare per instradare il traffico ai servizi di backend.
  • Servizio di backend, a cui sono associate Route risorse.

Di seguito sono riportati i diversi tipi di risorse Route:

  • HTTPRoute, disponibile solo nei mesh che utilizzano i proxy Envoy. Quando utilizzi la risorsa HTTPRoute per configurare i proxy Envoy per l'invio di richieste HTTP, sono disponibili tutte le funzionalità descritte in questo documento.
  • TCPRoute, disponibile solo nei mesh che utilizzano i proxy Envoy.
  • TLSRoute, disponibile solo nei mesh che utilizzano i proxy Envoy.
  • GRPCRoute, disponibile in mesh che utilizzano proxy sidecar Envoy e gRPC senza proxy. Quando utilizzi applicazioni o servizi gRPC senza proxy con Traffic Director, alcune delle funzionalità descritte in questo documento non sono disponibili.

Configurazione

Per configurare la gestione avanzata del traffico, utilizza le stesse risorse dei servizi Route e di backend che utilizzi durante la configurazione di Traffic Director. Traffic Director, a sua volta, configura i proxy Envoy e le applicazioni gRPC senza proxy per applicare i criteri avanzati di gestione del traffico che hai impostato.

A livello generale, esegui le seguenti operazioni:

  1. Configura una risorsa Mesh per identificare il mesh di servizi.

  2. Configura le risorse Route per eseguire le seguenti operazioni, in base alle caratteristiche della richiesta in uscita:

    1. Seleziona il servizio di backend a cui vengono instradate le richieste.

    2. Se vuoi, esegui azioni aggiuntive.

  3. Configura il servizio di backend per controllare in che modo il traffico viene distribuito a backend ed endpoint dopo aver selezionato un servizio di destinazione.

Routing e azioni del traffico

In Traffic Director, il traffico viene instradato in base ai valori nelle risorse Mesh, Route e nel servizio di backend. Tutte le funzionalità di gestione avanzata del traffico relative al routing e alle azioni vengono configurate utilizzando gli oggetti Route.

Le seguenti sezioni descrivono le funzionalità di gestione avanzata del traffico che puoi configurare negli oggetti Route.

Gestione delle richieste

Quando un client invia una richiesta, questa viene gestita come descritto nei seguenti passaggi:

  1. La richiesta viene associata a una risorsa Route specifica, come segue:

    • Se utilizzi Envoy:
      • L'intestazione dell'host nella richiesta HTTP viene confrontata con il campo hostnames in ogni HTTPRoute o GRPCRouterisorsa per selezionare la risorsa Route corretta per la richiesta. Solo le risorse HTTPRoute e GRPCRoute hanno il campo hostnames.
      • L'indirizzo IP corrisponde per il routing del traffico TCP utilizzando TCPPRoute.
      • Per il passthrough TLS vengono utilizzati SNI e ALPN tramite TLSRoute.
      • Le risorse HTTPRoute e GRPCRoute associate a un Mesh o Gateway devono avere nomi host univoci. Se provi a collegare più route che hanno nomi host in conflitto, la configurazione viene rifiutata.
      • Allo stesso modo, il campo IP:Port di TCPRoute deve essere univoco, altrimenti la configurazione viene rifiutata.
      • Allo stesso modo, SNI e ALPN devono essere univoci per TLSRoute.
      • Se sono presenti nomi host che si sovrappongono, come a.example.com e *.example.com, la richiesta corrisponde alla route più specifica.
    • Se utilizzi gRPC senza proxy:
      • I client gRPC senza proxy utilizzano lo schema di risoluzione dei nomi xds. Risolve hostname[:port] nell'URI di destinazione inviando una richiesta a Traffic Director.
      • Solo la porta di una risorsa GRPCRoute viene confrontata con la porta nell'URI di destinazione (ad esempio, xds:///example.hostname:8080). L'URI di destinazione deve corrispondere esattamente alla stringa nel campo hostnames di GRPCRoute.

  2. La risorsa Route può contenere ulteriori informazioni e regole di routing.

  3. Dopo aver selezionato il servizio di backend di destinazione, il traffico viene distribuito tra i backend o gli endpoint per quel servizio, in base alla configurazione nella risorsa del servizio di backend.

Il secondo passaggio è descritto nella sezione seguente, Routing semplice basato su host e percorso. Il terzo passaggio è discusso in Routing e azioni avanzate.

Routing semplice basato su host e percorso

Traffic Director supporta uno schema di routing semplificato e uno più avanzato. Nello schema semplice, specifichi un host e, facoltativamente, un percorso. L'host e il percorso della richiesta vengono valutati per determinare il servizio di backend a cui viene instradata.

  • L'host della richiesta è la parte del nome di dominio di un URL, ad esempio la parte host dell'URL http://example.com/video/ è example.com.
  • Il percorso della richiesta è la parte dell'URL che segue il nome host, ad esempio la parte del percorso dell'URL http://example.com/video/ è /video.

Puoi configurare un routing semplice in base all'host e al percorso nella mappa delle regole di routing, composta da quanto segue:

  • Un Mesh globale
  • Un HTTPRoute o un GRPCRoute

La maggior parte della configurazione viene eseguita in HTTPRoute. Dopo aver creato la mappa di regole di routing iniziale, devi modificare solo la risorsa HTTPRoute.

La regola più semplice è una regola predefinita, in cui specifichi solo una regola host con caratteri jolly (*) e un matcher percorso con un servizio predefinito. Dopo aver creato la regola predefinita, puoi aggiungere altre regole che specificano host e percorsi diversi. Le richieste in uscita vengono valutate in base a queste regole nel seguente modo:

  • Se l'host di una richiesta (ad esempio example.com) corrisponde al nome host di HTTPRoute:

    1. Viene valutata la metrica RouteRule. Il parametro RouteRule specifica come abbinare il traffico e come instradarlo in caso di corrispondenza del traffico.
    2. Ogni RouteRule contiene una o più corrispondenze di route valutate in base al percorso della richiesta.
    3. Se viene trovata una corrispondenza, la richiesta viene instradata al servizio specificato in RouteAction.

Per ulteriori informazioni sui campi delle risorse di HTTPRoute e sul loro funzionamento, consulta la documentazione relativa all'API del servizio di rete.

Routing e azioni avanzati

Se non vuoi instradare una richiesta in base all'host e al percorso della richiesta, puoi configurare regole avanzate per instradare le richieste ed eseguire azioni.

A livello generale, le azioni e il routing avanzati funzionano come segue:

  1. Come per il routing semplice, l'host della richiesta viene confrontato con le regole host configurate in HTTPRoute o GRPCRoute. Se l'host di una richiesta corrisponde al nome host, viene valutato HTTPRoute o GRPCRoute.
  2. Dopo aver selezionato una route, puoi applicare azioni.

Routing avanzato

Il routing avanzato è simile al routing semplice descritto in precedenza, con la differenza che puoi specificare condizioni di corrispondenza aggiuntive. Ad esempio, puoi specificare che una regola corrisponda all'intestazione di una richiesta se il nome dell'intestazione corrisponde esattamente o solo parzialmente, ad esempio in base al prefisso o al suffisso. La corrispondenza di una regola può basarsi sulla valutazione del nome dell'intestazione rispetto a un'espressione regolare o su altri criteri, come il controllo della presenza di un'intestazione.

Per ulteriori condizioni di corrispondenza e dettagli per headerMatches e queryParameterMatches, consulta la pagina dell'API REST network services.

Combinando host, percorso, intestazione e parametri di ricerca con condizioni di corrispondenza, puoi creare regole altamente espressive che si adattano ai tuoi requisiti esatti di gestione del traffico. Per maggiori dettagli consulta la tabella seguente.

applicazione basata su HTTP Applicazione basata su gRPC
Confronto tra host HTTP e host gRPC

L'host è la parte del nome di dominio dell'URL a cui chiama l'applicazione.

Ad esempio, la parte host dell'URL http://example.com/video/ è example.com.

L'host è il nome che un client utilizza nell'URI del canale per connettersi a un servizio specifico.

Ad esempio, la parte host dell'URI del canale xds:///example.com è example.com.
Confronto tra percorsi HTTP e percorsi gRPC

Il percorso è la parte dell'URL che segue il nome host.

Ad esempio, la parte del percorso dell'URL http://example.com/video è /video.

Il percorso è nell'intestazione :path della richiesta HTTP/2 e appare come /SERVICE_NAME/METHOD_NAME.

Ad esempio, se chiami il metodo Download nel servizio gRPC Example, i contenuti dell'intestazione :path saranno simili a /Example/Download.
Altre intestazioni gRPC (metadati) gRPC supporta l'invio di metadati tra il client gRPC e il server gRPC per fornire ulteriori informazioni su una chiamata RPC. Questi metadati sono sotto forma di coppie chiave-valore riportate come intestazioni nella richiesta HTTP/2.

Azioni

Traffic Director consente di specificare le azioni eseguite dai proxy Envoy o dalle applicazioni gRPC senza proxy durante la gestione di una richiesta. Le seguenti azioni possono essere configurate utilizzando Traffic Director.

Azione Nome campo API Descrizione
Reindirizzamenti redirect [pathredirect?] Restituisce un codice di risposta 3xx configurabile. Inoltre, imposta l'intestazione della risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificati nell'azione di reindirizzamento.
Riscritture di URL urlRewrite Riscrive la parte del nome host dell'URL, la parte del percorso dell'URL o entrambi prima di inviare una richiesta al servizio di backend selezionato.
Trasformazioni intestazione requestHeaderModifier/responseHeaderModifier? Aggiunge o rimuove le intestazioni delle richieste prima di inviare una richiesta al servizio di backend. Può anche aggiungere o rimuovere le intestazioni delle risposte dopo aver ricevuto una risposta dal servizio di backend.
Mirroring del traffico requestMirrorPolicy

Oltre a inoltrare la richiesta al servizio di backend selezionato, invia una richiesta identica al servizio di backend di mirroring configurato in base al criterio fire and delete. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta sottoposta a mirroring.

Il mirroring è utile per testare una nuova versione di un servizio di backend. Puoi utilizzarla anche per eseguire il debug degli errori di produzione in una versione di debug del servizio di backend anziché nella versione di produzione.
Suddivisione del traffico in base alla ponderazione weiDestination.serviceNameght

Consente la distribuzione del traffico per una regola corrispondente a più servizi di backend, in modo proporzionale a una ponderazione definita dall'utente assegnata al singolo servizio di backend.

Questa funzionalità è utile per configurare deployment graduali o test A/B. Ad esempio, l'azione di route può essere configurata in modo che il 99% del traffico venga inviato a un servizio che esegue una versione stabile di un'applicazione, mentre l'1% del traffico viene inviato a un servizio separato che esegue una versione più recente dell'applicazione.
Nuovi tentativi retryPolicy Consente di configurare le condizioni in base alle quali il bilanciatore del carico riprova a eseguire le richieste non riuscite, il tempo di attesa del bilanciatore del carico prima di riprovare e il numero massimo di nuovi tentativi consentiti.
Timeout timeout Specifica il timeout per la route selezionata. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al momento in cui la risposta viene elaborata completamente. Il timeout include tutti i nuovi tentativi.
Fault injection faultInjectionPolicy Introduce errori durante la gestione delle richieste per simulare gli errori, tra cui alta latenza, sovraccarico dei servizi, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio rispetto a errori simulati.
Criteri di sicurezza corsPolicy I criteri di condivisione delle risorse tra origini (CORS) gestiscono le impostazioni per l'applicazione delle richieste CORS.

Per ulteriori informazioni sulle azioni e sul loro funzionamento, consulta la pagina relativa all'API dei servizi di rete.

In ogni regola di route, puoi specificare una delle seguenti azioni di route:

  • Instrada il traffico a un singolo servizio (destination.serviceName)
  • Suddividi traffico tra più servizi (destination.weight)
  • URL di reindirizzamento (redirect)

Inoltre, puoi combinare qualsiasi azione di route menzionata in precedenza con una o più delle seguenti azioni di route (chiamate azioni aggiuntive nella console Google Cloud):

  • Manipolare le intestazioni di richiesta o risposta (requestHeaderModifier/responseHeaderModifier)
  • Esegui il mirroring del traffico (requestMirrorPolicy)
  • Riscrivi l'host, il percorso o entrambi l'URL (urlRewrite)
  • Riprova le richieste non riuscite (retryPolicy)
  • Imposta timeout (timeout)
  • Introduci errori a una percentuale di traffico (faultInjectionPolicy)
  • Aggiungi criterio CORS (corsPolicy)

Poiché le azioni sono associate a regole specifiche, l'applicazione proxy Envoy o l'applicazione gRPC senza proxy può applicare azioni diverse in base alla richiesta che gestisce.

Distribuzione del traffico tra i backend di un servizio

Come spiegato in Gestione delle richieste, quando un client gestisce una richiesta in uscita, seleziona prima un servizio di destinazione. Dopo aver selezionato un servizio di destinazione, deve capire quale backend o endpoint deve ricevere la richiesta.

La distribuzione del traffico tra backend.
Distribuzione del traffico tra backend (fai clic per ingrandire)

Nel diagramma precedente, la regola è stata semplificata. La Rule è in genere una regola host, un matcher percorso e una o più regole percorso o route. Il servizio di destinazione è il servizio(backend). Backend 1, ... e Backend n ricevono e gestiscono la richiesta. Questi backend possono essere, ad esempio, istanze di macchine virtuali (VM) Compute Engine che ospitano il codice dell'applicazione lato server.

Per impostazione predefinita, il client che gestisce la richiesta invia richieste al backend integro più vicino con capacità disponibile. Per evitare il sovraccarico di un backend specifico, utilizza l'algoritmo di bilanciamento del carico round robin per bilanciare il carico delle richieste successive in altri backend del servizio di destinazione. In alcuni casi, tuttavia, potresti volere un controllo più granulare su questo comportamento.

Bilanciamento del carico, affinità sessione e protezione dei backend

Puoi impostare i seguenti criteri di distribuzione del traffico su ciascun servizio.

Criterio Nome campo API Descrizione
Modalità di bilanciamento del carico balancingMode Controlla come viene selezionato un gruppo di endpoint di rete (NEG) o un gruppo di istanze gestite dopo la selezione di un servizio di destinazione. Puoi configurare la modalità di bilanciamento per distribuire il carico in base alle connessioni simultanee e al tasso di richieste.
Criterio di bilanciamento del carico localityLbPolicy Imposta l'algoritmo di bilanciamento del carico utilizzato per distribuire il traffico tra backend all'interno di un NEG o un gruppo di istanze gestite. Per ottimizzare il rendimento, puoi scegliere tra vari algoritmi (come round robin o richiesta minima).
Affinità sessione sessionAffinity

Fornisce il tentativo di inviare richieste da un determinato client allo stesso backend finché il backend è integro e dispone di capacità.

Traffic Director supporta quattro opzioni di affinità sessione: indirizzo IP client, basato su cookie HTTP, basato su intestazioni HTTP e affinità cookie generato (che Traffic Director genera automaticamente).
Hash coerente consistentHash Fornisce un'affinità sessione soft basata su intestazioni HTTP, cookie o altre proprietà.
Interruttori di sicurezza circuitBreakers Imposta limiti superiori per il volume di connessioni e richieste per connessione a un servizio di backend.
Rilevamento outlier outlierDetection Specifica i criteri per (1) rimuovere i backend o gli endpoint in stato non integro dai gruppi di istanze gestite o dai NEG e (2) aggiungere di nuovo un backend o un endpoint quando questi ultimi vengono considerati abbastanza integri da ricevere di nuovo il traffico. Il controllo di integrità associato al servizio determina se un backend o un endpoint è considerato integro.

Per ulteriori informazioni sulle varie opzioni di distribuzione del traffico e sul loro funzionamento, consulta la pagina relativa all'API REST backendServices e la panoramica dei servizi di backend.

Esempi di casi d'uso

La gestione avanzata del traffico è adatta a molti casi d'uso. Questa sezione fornisce alcuni esempi generali.

Puoi trovare altri esempi, incluso un codice campione, in Configurare la gestione avanzata del traffico con Envoy e Configurare la gestione avanzata del traffico con servizi gRPC senza proxy.

Routing del traffico granulare per la personalizzazione

Puoi indirizzare il traffico a un servizio in base ai parametri della richiesta. Ad esempio, potresti utilizzare questo servizio per offrire un'esperienza più personalizzata agli utenti Android. Nel diagramma seguente, Traffic Director configura il tuo mesh di servizi in modo che invii richieste con l'intestazione user-agent:Android al tuo servizio Android anziché al servizio generico.

Routing basato sull'intestazione dello user agent impostata su Android.
Routing basato sull'intestazione user-agent impostata su Android (fai clic per ingrandire)

Suddivisione del traffico in base alla ponderazione per deployment più sicuri

Il deployment di una nuova versione di un servizio di produzione esistente può essere rischioso. Anche dopo che i test sono stati superati in un ambiente di test, potresti non voler indirizzare subito tutti gli utenti alla nuova versione.

Traffic Director consente di definire suddivisioni del traffico in base al peso per distribuire il traffico tra più servizi. Ad esempio, puoi inviare l'1% del traffico alla nuova versione del servizio, monitorare che tutto funzioni e quindi aumentare gradualmente la proporzione di traffico verso il nuovo servizio.

Suddivisione del traffico in base al peso di Traffic Director.
Suddivisione del traffico in base al peso di Traffic Director (fai clic per ingrandire)

Mirroring del traffico per il debug

Quando esegui il debug di un problema, può essere utile inviare copie del traffico di produzione a un servizio di debug. Traffic Director consente di configurare criteri di mirroring delle richieste in modo che le richieste vengano inviate a un servizio e le relative copie vengano inviate a un altro servizio.

Mirroring del traffico di Traffic Director.
Mirroring del traffico di Traffic Director (fai clic per ingrandire)

Bilanciamento del carico ottimizzato per le prestazioni

A seconda delle caratteristiche dell'applicazione, potresti scoprire che puoi migliorare le prestazioni e la disponibilità perfezionando la modalità di distribuzione del traffico nei backend di un servizio. Con Traffic Director, puoi applicare algoritmi avanzati di bilanciamento del carico in modo che il traffico venga distribuito in base alle tue esigenze.

A differenza dei diagrammi precedenti, il seguente diagramma mostra sia un servizio di backend di destinazione (Servizio di produzione) sia i backend per tale servizio di backend (Macchina virtuale 1, Macchina virtuale 2, Macchina virtuale 3). Con la gestione avanzata del traffico, puoi configurare il modo in cui viene selezionato un servizio di backend di destinazione e la distribuzione del traffico tra i backend per quel servizio di destinazione.

Bilanciamento del carico di Traffic Director.
Bilanciamento del carico di Traffic Director (fai clic per ingrandire)

Passaggi successivi