Questa pagina fornisce una panoramica delle funzionalità di gestione avanzata del traffico disponibili per i bilanciatori del carico delle applicazioni esterni regionali. Questa pagina è valida solo per il bilanciatore del carico delle applicazioni esterno regionale. Questi bilanciatori del carico sono sempre regionali e sempre nel livello Standard. Se utilizzi un bilanciatore del carico in una modalità diversa, consulta una delle seguenti pagine:
I bilanciatori del carico delle applicazioni esterni regionali supportano le seguenti funzionalità di gestione avanzata del traffico:- Steering del traffico. Instrada in modo intelligente il traffico in base ai parametri HTTP(S) (ad esempio, host, percorso, intestazioni e altri parametri della richiesta).
- Azioni relative al traffico. Esegui azioni basate su richieste e risposte (ad esempio reindirizzamenti e trasformazioni delle intestazioni).
- Norme sul traffico. Ottimizza il comportamento del bilanciamento del carico (ad esempio, algoritmi di bilanciamento del carico avanzati).
Puoi configurare queste funzionalità utilizzando le mappe URL e i servizi di backend. Per maggiori informazioni, consulta i seguenti argomenti:
Esempi di casi d'uso
La gestione del traffico copre molti casi d'uso. Questa sezione fornisce alcuni esempi di alto livello.
Indirizzamento del traffico: routing basato su intestazione
L'indirizzamento del traffico consente di indirizzare il traffico alle istanze di servizio in base a parametri HTTP come le intestazioni delle richieste. Ad esempio, se il dispositivo di un utente è
un dispositivo mobile con user-agent:Mobile nell'intestazione della richiesta, il routing del traffico può inviare il traffico alle istanze di servizio designate per gestire il traffico mobile e inviare il traffico senza user-agent:Mobile alle istanze designate per gestire il traffico proveniente da altri dispositivi.
Azioni sul traffico: suddivisione del traffico basata sulla ponderazione
Il deployment di una nuova versione di un servizio di produzione esistente comporta in genere alcuni rischi. Anche se i test vengono superati in staging, probabilmente non vuoi sottoporre immediatamente il 100% dei tuoi utenti alla nuova versione. Con la gestione del traffico, puoi definire suddivisioni del traffico basate su percentuali tra più servizi di backend.
Ad esempio, puoi inviare il 95% del traffico alla versione precedente del tuo servizio e il 5% alla nuova versione. Dopo aver verificato che la nuova versione di produzione funziona come previsto, puoi spostare gradualmente le percentuali fino a quando il 100% del traffico raggiunge la nuova versione del servizio. La suddivisione del traffico viene in genere utilizzata per il deployment di nuove versioni, i test A/B, la migrazione dei servizi e processi simili.
Policy di traffico: mirroring delle richieste
La tua organizzazione potrebbe avere requisiti di conformità specifici che impongono il mirroring di tutto il traffico su un servizio aggiuntivo che può, ad esempio, registrare i dettagli della richiesta in un database per la riproduzione successiva.
Estensibilità con Service Extensions
L'integrazione con Service Extensions ti consente di inserire una logica personalizzata nel percorso dei dati di bilanciamento del carico dei bilanciatori del carico delle applicazioni supportati utilizzando callout e plug-in.
Puoi configurare queste estensioni in vari punti del percorso di elaborazione: autorizzazione, edge, route, e traffico.
Puoi anche utilizzare Service Extensions per configurare funzionalità avanzate, come l'inoltro dinamico.
Per saperne di più, consulta la panoramica delle estensioni di servizio.
Componenti di gestione del traffico
A livello generale, i bilanciatori del carico forniscono la gestione del traffico sfruttando le risorse mappe URL regionali e servizi di backend regionali.Per i bilanciatori del carico delle applicazioni interni tra regioni, la gestione del traffico utilizza le risorse mappe URL globali e servizi di backend globali.
Puoi configurare la gestione e le azioni del traffico utilizzando le mappe URL. Le risorseGoogle Cloud associate alle mappe URL includono quanto segue:
- Regola di route
- Corrispondenza regola
- Azione della regola
Puoi configurare le policy di gestione del traffico utilizzando i servizi di backend. Le risorseGoogle Cloud associate ai servizi di backend includono:
- Interruttori di sicurezza
- Policy del bilanciatore del carico per le località
- Impostazioni del bilanciatore del carico con hash coerente
- Rilevamento outlier
Il seguente diagramma mostra le risorse utilizzate per implementare ogni funzionalità.
Routing delle richieste ai backend
Nei bilanciatori del carico delle applicazioni esterni regionali, il backend per il traffico viene determinato utilizzando un approccio in due fasi:- Il bilanciatore del carico seleziona un servizio di backend in base alle regole definite in una mappa URL regionale.
- Il servizio di backend seleziona un'istanza di backend in base alle norme definite in un servizio di backend regionale.
Quando configuri il routing, puoi scegliere tra le seguenti modalità:
# disableFinding("simple") #
Regola host e percorso semplice- Regola avanzata per host, percorso e route
Le due modalità si escludono a vicenda. Ogni mappa di URL può contenere una sola modalità.
Regola semplice per host e percorso
In una regola host e percorso semplice, le mappe URL funzionano come descritto nella panoramica delle mappe URL.
Il seguente diagramma mostra il flusso logico di una semplice regola host e percorso.
Una richiesta viene inizialmente valutata utilizzando le regole host. Un host è il dominio
specificato dalla richiesta. Se la richiesta host corrisponde a una delle voci nel campo hosts, viene utilizzato il matcher di percorso associato.
Successivamente, viene valutato il matcher di percorso. Le regole percorso vengono valutate in base alla corrispondenza del percorso più lungo e puoi specificare le regole percorso in qualsiasi ordine. Una volta trovata la corrispondenza più specifica, la richiesta viene indirizzata al servizio di backend corrispondente. Se la richiesta non corrisponde, viene utilizzato il servizio di backend predefinito.
Una tipica regola semplice per host e percorso potrebbe essere simile alla seguente, in cui
il traffico video va a video-backend-service e tutto il resto del traffico va a
web-backend-service.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1
Regola avanzata per host, percorso e route
Le regole avanzate per host, percorso e route forniscono opzioni di configurazione aggiuntive rispetto alle regole semplici per host e percorso. Queste opzioni consentono pattern di gestione del traffico più avanzati e modificano anche alcune semantiche. Ad esempio, le regole di route hanno un valore di priorità associato e vengono interpretate in ordine di priorità (anziché utilizzando la semantica della corrispondenza del percorso più lungo per prima).
Come nell'esempio precedente di regola host e percorso semplice, puoi configurare la gestione avanzata del traffico utilizzando una mappa URL. Ad esempio, la seguente mappa URL configura il routing in cui il 95% del traffico viene indirizzato a un servizio di backend e il 5% del traffico viene indirizzato a un altro servizio di backend.
gcloud compute url-maps describe lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
name: matcher1
routeRules:
- matchRules:
- prefixMatch: ''
routeAction:
weightedBackendServices:
- backendService: regions/us-west1/backendServices/service-a
weight: 95
- backendService: regions/us-west1/backendServices/service-b
weight: 5
region: regions/us-west1
Regole host
Quando una richiesta raggiunge il bilanciatore del carico, il campo host della richiesta viene valutato in base al hostRules definito nella mappa URL. Ogni regola host
è costituita da un elenco di uno o più host e da un singolo matcher percorso
(pathMatcher). Se non sono definiti hostRules, la richiesta viene indirizzata a
defaultService.
hostRules[] e defaultService nella
documentazione dell'API di mappatura degli URL regionali.
Matcher percorso
Dopo che una richiesta corrisponde a una regola host, il bilanciatore del carico valuta il matcher di percorso corrispondente all'host.
Un matcher di percorso è costituito da quanto segue:
- Una o più regole percorso (
pathRules) o regole di route (routeRules). - Un servizio predefinito (
defaultService), ovvero il servizio di backend predefinito utilizzato quando non corrispondono altri servizi di backend.
pathMatchers[], pathMatchers[].pathRules[] e
pathMatchers[].routeRules[] nella documentazione dell'API
della mappa URL a livello di regione.
Regole percorso
Le regole di percorso (pathRules) specificano uno o più percorsi URL, ad esempio / o /video.
Le regole di percorso sono generalmente destinate al tipo di routing semplice basato su host e percorso
descritto in precedenza.
pathRules[] nella documentazione dell'API per la mappa degli URL regionali.
Regole di route
Una regola di routing (routeRules) corrisponde alle informazioni in una richiesta in entrata e prende una decisione di routing in base alla corrispondenza.
Le regole di routing possono contenere una serie di regole di corrispondenza diverse (matchRules) e una serie di azioni di routing diverse (routeAction).
Una regola di corrispondenza valuta la richiesta in entrata in base al percorso, alle intestazioni e ai parametri di query della richiesta HTTP(S). Le regole di corrispondenza supportano vari tipi di corrispondenze (ad esempio, la corrispondenza con prefisso) e modificatori (ad esempio, l'insensibilità alle maiuscole). In questo modo, ad esempio, puoi inviare richieste HTTP(S) a un insieme di backend in base alla presenza di un'intestazione HTTP definita personalizzata.
Nota: le opzioni di corrispondenza e la semantica variano a seconda della parte della richiesta che corrisponde. Per ulteriori informazioni, consultamatchRules[] nella documentazione dell'API per la mappa degli URL regionali.
Se hai più regole di route, il bilanciatore del carico le esegue in ordine di priorità (in base al campo priority), il che ti consente di specificare una logica personalizzata per la corrispondenza, il routing e altre azioni.
All'interno di una determinata regola di routing, quando viene trovata la prima corrispondenza, il bilanciatore del carico interrompe la valutazione delle regole di corrispondenza e le eventuali regole di corrispondenza rimanenti vengono ignorate.
Google Cloud esegue le seguenti azioni:
- Cerca la prima regola di corrispondenza che corrisponde alla richiesta.
- Interrompe la ricerca di altre regole di corrispondenza.
- Applica le azioni nelle azioni route corrispondenti.
Le regole di routing hanno diversi componenti, come descritto nella tabella seguente.
Componente della regola di routing (API field name) |
Descrizione |
|---|---|
Priorità (priority) |
Un numero compreso tra 0 e 2.147.483.647 (ovvero (2^31)-1) assegnato a una
regola di route all'interno di un determinato matcher percorso. La priorità determina l'ordine di valutazione delle regole di route. La priorità di una regola diminuisce all'aumentare del numero, in modo che una regola con priorità 4 venga valutata prima di una regola con priorità 25. Viene applicata la prima regola che corrisponde alla richiesta.
Puoi lasciare intervalli vuoti tra i numeri di priorità. Non puoi creare più di una regola con la stessa priorità. |
Descrizione (description) |
Una descrizione facoltativa di massimo 1024 caratteri. |
Servizio (service) |
L'URL completo o parziale della risorsa del servizio di backend a cui viene indirizzato il traffico se questa regola corrisponde. |
Regole di corrispondenza (matchRules) |
Una o più regole valutate in base alla richiesta. Questi
matchRules possono corrispondere a tutti o a un sottoinsieme degli attributi HTTP della richiesta, come il percorso, le intestazioni HTTP e i parametri di query (GET).All'interno di un matchRule, tutti i criteri corrispondenti
devono essere soddisfatti affinché l'routeRule's routeActions
abbia effetto. Se un routeRule ha più matchRules, il routeActions del routeRule ha effetto quando una richiesta corrisponde a uno qualsiasi dei matchRules del routeRule.
|
Azione route (routeAction) |
Consente di specificare le azioni da intraprendere quando i criteri della regola di corrispondenza sono soddisfatti. Queste azioni includono la suddivisione del traffico, la riscrittura degli URL, i tentativi e il mirroring, l'inserimento di errori e i criteri CORS. |
Azione di reindirizzamento (urlRedirect) |
Puoi configurare un'azione per rispondere con un reindirizzamento HTTP quando vengono soddisfatti i criteri della regola di corrispondenza. Questo campo non può essere utilizzato insieme a un'azione di percorso. |
Azione intestazione (headerAction) |
Puoi configurare le regole di trasformazione delle intestazioni di richieste e risposte quando vengono soddisfatti i criteri all'interno di matchRules.
|
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].headerAction
Regole delle corrispondenze
Le regole di corrispondenza (matchRules) corrispondono a uno o più attributi di una richiesta ed eseguono le azioni specificate nella regola di route. Il seguente elenco fornisce alcuni esempi
di attributi delle richieste che possono essere abbinati utilizzando le regole di corrispondenza:
Host: un nome host è la parte del nome di dominio di un URL. Ad esempio, la parte del nome host dell'URL
http://example.net/video/hdèexample.net. Nella richiesta, il nome host proviene dall'intestazioneHost, come mostrato in questo comando curl di esempio, dove10.1.2.9è l'indirizzo IP bilanciato del carico:curl -v http://10.1.2.9/video/hd --header 'Host: example.com'I percorsi seguono il nome host, ad esempio
/images. La regola può specificare se deve corrispondere l'intero percorso o solo la parte iniziale.Altri parametri della richiesta HTTP, come le intestazioni HTTP, che consentono la corrispondenza dei cookie, nonché la corrispondenza in base ai parametri di query (variabili GET).
pathMatchers[].routeRules[].matchRules[] nella documentazione dell'API
della mappa degli URL regionali.
Azioni di route
Le azioni di routing sono azioni specifiche da intraprendere quando una regola di routing corrisponde agli attributi di una richiesta.
Azione route (API field name) |
Descrizione |
|---|---|
Reindirizzamenti (urlRedirect) |
Restituisce un codice di risposta 3xx
configurabile. Imposta anche l'intestazione della risposta Location
con l'URI appropriato, sostituendo l'host e il percorso come specificato
nell'azione di reindirizzamento.
|
Riscrittura degli URL (urlRewrite) |
Riscrive la parte del nome host dell'URL, la parte del percorso dell'URL o entrambe prima di inviare una richiesta al servizio di backend selezionato. |
Trasformazioni dell'intestazione (headerAction) |
Aggiunge o rimuove le intestazioni delle richieste prima di inviare una richiesta al servizio di backend. Puoi anche aggiungere o rimuovere le intestazioni di risposta dopo aver ricevuto una
risposta dal servizio di backend. Se tenti di aggiungere e rimuovere la stessa
intestazione, questa viene rimossa, a meno che non venga utilizzato il
flag replace: True con l'operazione
requestHeadersToAdd.
|
Mirroring del traffico (requestMirrorPolicy) |
Oltre a inoltrare la richiesta al servizio di backend selezionato, invia una richiesta identica al servizio di backend mirror configurato in modalità fire and forget. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta di mirroring. Tieni presenti le seguenti limitazioni quando utilizzi il mirroring del traffico:
|
Suddivisione del traffico ponderata (weightedBackendServices) |
Consente di distribuire il traffico per una regola corrispondente a più servizi di backend, in proporzione a un peso definito dall'utente assegnato al singolo servizio di backend. Questa funzionalità è utile per configurare implementazioni in più fasi o test A/B. Ad esempio, l'azione di route potrebbe 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 venga inviato a un servizio separato che esegue una versione più recente di quell'applicazione. |
Nuovi tentativi (retryPolicy) |
Configura le condizioni in base alle quali il bilanciatore del carico riprova le richieste non riuscite, per quanto tempo attende prima di riprovare e il numero massimo di 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 tentativi. |
Fault injection (faultInjectionPolicy) |
Introduce errori durante l'elaborazione delle richieste per simulare errori, tra cui latenza elevata, sovraccarico del servizio, errori del servizio e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio a errori simulati. |
Inserimento ritardato (faultInjectionPolicy) |
Introduce ritardi per una parte delle richieste definita dall'utente prima di inviare la richiesta al servizio di backend selezionato. |
Interrompi inserimento (faultInjectionPolicy) |
Risponde direttamente a una frazione di richieste con codici di stato HTTP definiti dall'utente anziché inoltrarle al servizio di backend. |
Norme di sicurezza (corsPolicy) |
I criteri di condivisione delle risorse tra origini (CORS) gestiscono le impostazioni per l'applicazione delle richieste CORS. |
Puoi specificare una delle seguenti azioni per il percorso:
- Instrada il traffico a un singolo servizio (
service). - Suddividi il traffico tra più servizi (
weightedBackendServices weight:x, dove x deve essere compreso tra 0 e 1000). - URL di reindirizzamento (
urlRedirect).
Inoltre, puoi combinare una qualsiasi delle azioni di route menzionate in precedenza con una o più delle seguenti azioni di route:
- Esegui il mirroring del traffico (
requestMirrorPolicy). - Riscrivi host e percorso dell'URL (
urlRewrite). - Ritenta le richieste non riuscite (
retryPolicy). - Imposta timeout (
timeout). - Introduci errori in una percentuale del traffico (
faultInjectionPolicy). - Aggiungi policy CORS (
corsPolicy). - Manipola le intestazioni della richiesta o della risposta (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Reindirizzamenti da HTTP a HTTPS
Se devi reindirizzare il traffico HTTP a HTTPS, puoi creare due regole di forwarding con un indirizzo IP comune.
Per un esempio completo, consulta Configurazione del reindirizzamento da HTTP a HTTPS per i bilanciatori del carico delle applicazioni esterni regionali.Policy di traffico
Utilizzando le risorse del servizio di backend, puoi configurare le policy di gestione del traffico per ottimizzare il bilanciamento del carico all'interno di un gruppo di istanze o di un gruppo di endpoint di rete (NEG). Queste norme diventano effettive solo dopo che un servizio di backend è stato selezionato utilizzando la mappa URL (come descritto in precedenza).
I criteri di traffico ti consentono di:
- Controlla l'algoritmo di bilanciamento del carico tra le istanze all'interno del servizio di backend.
- Controlla il volume di connessioni a un servizio upstream.
- Controlla l'eliminazione degli host in stato non integro da un servizio di backend.
Criterio di traffico (API field name) |
Descrizione |
|---|---|
Policy di bilanciamento del carico per le località (LocalityLbPolicy) |
Per un servizio di backend, la distribuzione del traffico si basa su una modalità di bilanciamento del carico e su un criterio di località di bilanciamento del carico. La modalità di bilanciamento determina la ponderazione o la frazione di traffico che
deve essere inviata a ogni backend (gruppo di istanze o
Per le modalità di bilanciamento supportate, vedi Modalità di bilanciamento. Per gli algoritmi delle policy di bilanciamento del carico supportati, consulta
|
Affinità sessione (consistentHash) |
Include l'affinità basata sui cookie HTTP, l'affinità basata sulle intestazioni HTTP, l'affinità basata sull'indirizzo IP client, l'affinità sessione basata sui cookie stateful e l'affinità basata sui cookie generati. L'affinità sessione fornisce un tentativo di inviare le richieste di un determinato client allo stesso backend finché il backend è integro e ha capacità. Per saperne di più sull'affinità di sessione, consulta
|
Rilevamento outlier (outlierDetection) |
Un insieme di policy che specificano i criteri per l'espulsione di VM o endpoint di backend non integri nei NEG, insieme ai criteri che definiscono quando un backend o un endpoint è considerato sufficientemente integro da ricevere nuovamente traffico. Per ulteriori informazioni sul rilevamento degli outlier, consulta
|
Interruzione del circuito (circuitBreakers) |
Imposta limiti superiori sul volume di connessioni e richieste per connessione a un servizio di backend. Per saperne di più
sull'interruzione del circuito, consulta |
Passaggi successivi
- Per configurare la gestione del traffico per il bilanciatore del carico delle applicazioni esterno regionale, consulta Configurazione della gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali.