Questa pagina offre una panoramica delle funzionalità di gestione del traffico disponibili per l'Application Load Balancer classico. Questa pagina riguarda solo l'Application Load Balancer classico. Se utilizzi un bilanciatore del carico in una modalità diversa che supporti il set espanso di funzionalità di gestione del traffico, consulta una delle seguenti pagine:
Panoramica della gestione del traffico per gli Application Load Balancer esterni regionali
Panoramica della gestione del traffico per gli Application Load Balancer esterni globali
Il bilanciatore del carico delle applicazioni classico supporta la funzionalità di gestione del traffico che consente di utilizzare le seguenti funzionalità:
- Indirizzamento del traffico. Instrada il traffico in modo intelligente in base ai parametri HTTP(S):
- Azioni relative al traffico. Esegui azioni basate su richiesta:
- Criteri relativi al traffico. Ottimizza il comportamento di bilanciamento del carico:
Puoi configurare queste funzionalità utilizzando la mappa URL del bilanciatore del carico. Per informazioni di base, consulta i seguenti argomenti:
Componenti della gestione del traffico
A livello generale, gli Application Load Balancer esterni forniscono la gestione del traffico utilizzando mappe URL globali.
Il bilanciatore del carico fornisce le seguenti azioni principali che si escludono a vicenda:
- Instrada le richieste a un servizio di backend
- Esecuzione di un reindirizzamento
Quando configuri un bilanciatore del carico, puoi configurare un'azione di riscrittura dell'URL prima che il bilanciatore del carico invii richieste al servizio di backend o al bucket di backend.
Le riscritture o i reindirizzamenti possono essere applicati a tre livelli nella mappa URL:
- In
pathRule
, dove l'azione viene applicata quando viene trovata una corrispondenza con un percorso - Nel punto di
pathMatcher
, dove l'azione viene applicata quando non esistono percorsi corrispondenti per questopathMatcher
- Al
urlMap
, dove l'azione ha effetto quando non viene soddisfatta nessuno degli host specificati in una delle regole host
L'utilizzo di routeRules
in pathMatcher
è un'alternativa all'uso di pathRules
.
pathRules
e routeRules
non possono essere entrambi visualizzati nello stesso pathMatcher
.
A differenza di pathRules
, dove l'ordine non è importante, i routeRules
vengono esaminati
in ordine. Un routeRule
può testare il percorso dell'URL, le intestazioni HTTP e i parametri di query dell'URL.
Esempi di casi d'uso
La gestione del traffico è adatta a molti casi d'uso. Questa sezione fornisce alcuni esempi di alto livello.
Riscrivi
Le riformulazioni degli URL ti consentono di presentare agli utenti esterni URL diversi da quelli utilizzati dai tuoi servizi.
Una riscrittura URL separa un URL da una risorsa. Puoi tradurre da URL ottimizzati per i motori di ricerca, più facili da ricordare e da utilizzare per gli utenti, trasformandoli in URL ottimizzati per i motori di ricerca, più facili da trovare per i motori di ricerca, o in URL interni specifici per l'implementazione.
La funzionalità di riscrittura dell'URL:
- Legge l'URL in arrivo nella richiesta.
- Sostituisce l'host, il percorso oppure sia l'host che il percorso, trasformando l'URL prima di indirizzare il traffico al servizio di backend o al bucket di backend.
Nel seguente diagramma:
- Un utente in Giappone invia una richiesta per l'URL
www.mydomain.com/static/images/someimage.jpg
. - Quando la richiesta raggiunge l'Application Load Balancer esterno, il bilanciatore del carico utilizza le informazioni nella mappa URL per riscrivere l'URL in
www.myorigin.com/august_snapshot/images/someimage.jpg
. - (Facoltativo) In questo esempio, la mappa URL invia la richiesta a un backend esterno.
Per un esempio di configurazione, vedi Riscritture.
Reindirizzamenti
Con i reindirizzamenti URL, puoi reindirizzare le richieste dei client da un URL a un altro.
Ciò include la possibilità di:
- Reindirizza tutte le richieste HTTP a richieste HTTPS.
- Reindirizza a un URL diverso creato modificando l'host, il percorso o entrambe le parti relative all'host e al percorso dell'URL e rimuovendo o mantenendo eventuali parametri di ricerca.
- Scegli i codici di risposta di reindirizzamento da emettere.
Utilizza i reindirizzamenti URL per le seguenti funzionalità:
- Fornisci abbreviazioni per gli URL. Gli URL rivolti ai client possono essere molto più brevi. Questo servizio invia un reindirizzamento alla pagina web con l'URL lungo.
- Previeni i link non funzionanti quando le pagine web vengono spostate o diventano obsolete.
- Consentire a più nomi di dominio appartenenti allo stesso proprietario di fare riferimento a un singolo sito web.
- Evita la fatica e le inefficienze di configurare soluzioni alternative sul server di backend per supportare il reindirizzamento necessario.
- Ridurre la latenza. I reindirizzamenti creati a livello perimetrale possono comportare una latenza inferiore rispetto ai reindirizzamenti creati negli endpoint di backend.
I reindirizzamenti da HTTP a HTTPS ti aiutano in particolare a:
- Soddisfare i requisiti di conformità (ad esempio HIPAA) per il traffico criptato.
- Reindirizza le richieste che utilizzano HTTPS anziché rifiutare le richieste inviate con il protocollo HTTP.
- Migliora il profilo di sicurezza della tua applicazione reindirizzando il traffico al bilanciatore del carico di livello 7 stesso, anziché implementare il reindirizzamento sul server di backend.
Nel seguente diagramma:
- Un utente in Giappone invia una richiesta
GET http://example.com/img1
. - In base al reindirizzamento definito nella mappa URL, il bilanciatore del carico invia un reindirizzamento
HTTP/1.1 302 Found Location: https://example.com/img1
, reindirizzando la richiesta HTTP a una richiesta HTTPS. - Il browser dell'utente invia una richiesta
GET https://example.com/img1
.
Per un esempio di configurazione, consulta la sezione Reindirizzamenti.
Codici di risposta supportati
I codici di risposta di reindirizzamento supportati sono elencati nella tabella.
Codice risposta | Numero | Note |
---|---|---|
MOVED_PERMANENTLY_DEFAULT | 301 | |
FOUND | 302 | |
PERMANENT_REDIRECT | 308 | In questo caso, il metodo di richiesta viene mantenuto. |
TEMPORARY_REDIRECT | 307 | In questo caso, il metodo di richiesta viene mantenuto. |
SEE_OTHER | 303 |
Routing basato su intestazioni e parametri
Il routing basato su intestazioni e parametri consente a un bilanciatore del carico di prendere decisioni di routing basate sulle intestazioni HTTP e parametri di ricerca dell'URL.
Con questa funzionalità puoi semplificare l'architettura cloud, senza eseguire il deployment di livelli aggiuntivi di proxy (ad esempio NGINX) per il routing.
Puoi utilizzare il bilanciatore del carico delle applicazioni esterno per:
- test A/B
- Assegnazione di clienti a diversi insiemi di servizi in esecuzione sui backend
- Offrire pagine ed esperienze diverse in base a categorie di dispositivi da cui provengono le richieste
Dopo aver selezionato un pathMatcher
in base alla stringa host, routeRules
in pathMatcher
seleziona un percorso dell'URL. Per ulteriori informazioni, consulta la panoramica sulle mappe URL.
Esempio: configurare i test A/B con il routing basato sui parametri di query
L'esempio seguente mostra come eseguire test A/B individuando una corrispondenza in base alla stringa di query per specificare l'esperimento e l'input.
Supponiamo che tu voglia assicurarti che le richieste vengano gestite nel seguente modo:
- Tutte le richieste con il valore parametro di query
A
vanno al servizio di backend chiamatoBackendServiceForProcessingOptionA
. - Tutte le richieste con il valore parametro di query
B
vanno al servizio di backend chiamatoBackendServiceForProcessingOptionB
.
Questi requisiti sono riassunti nella tabella seguente.
Richiesta | Servizio di backend |
---|---|
http://test.mydomain.com?ABTest=A |
BackendServiceForProcessingOptionA |
http://test.mydomain.com?ABTest=B |
BackendServiceForProcessingOptionB |
Per configurarla nella mappa URL globale, puoi creare le seguenti impostazioni.
Corrispondenza | Azione |
---|---|
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA |
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B |
pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB |
Per un esempio di configurazione, vedi Routing basato su intestazioni e parametri.
Routing delle richieste ai backend
Il backend per il traffico viene determinato utilizzando un approccio in due fasi:
Il bilanciatore del carico seleziona un servizio di backend con backend. I backend possono essere i seguenti:
- Istanze di macchine virtuali (VM) Compute Engine in un gruppo di istanze non gestite
- VM di Compute Engine in un gruppo di istanze gestite
- Container mediante un nodo Google Kubernetes Engine (GKE) in un gruppo di endpoint di rete (NEG) a livello di zona
- Backend esterni esterni a Google Cloud in un NEG internet
- Cloud Storage nei bucket di backend
- Servizi App Engine, Cloud Functions o Cloud Run in un NEG serverless
Il bilanciatore del carico sceglie un servizio di backend in base alle regole definite in una mappa URL globale.
Il servizio di backend seleziona un'istanza di backend in base ai criteri definiti in un servizio di backend globale.
Quando configuri il routing, puoi scegliere tra le seguenti modalità:
- Test semplici di host e percorsi mediante
pathRules
- Test delle richieste avanzate, utilizzando
routeRules
Per ogni mappa URL, puoi scegliere di utilizzare regole host e percorso semplici o regole host, percorso e route avanzate. Le due modalità si escludono a vicenda. Ogni mappa URL può contenere solo una modalità o l'altra.
Regola semplice per host e percorso
In una semplice regola host e percorso, 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 valutata inizialmente utilizzando le regole dell'host. Un host è il dominio
specificato dalla richiesta. Se la richiesta host
corrisponde a una delle voci nel campo hosts
, viene utilizzato il matcher percorso associato.
Viene quindi valutato il matcher del percorso. Le regole del percorso vengono valutate in base al percorso più lungo per corrispondenze e puoi specificare le regole per il percorso in qualsiasi ordine. Una volta trovata la corrispondenza più specifica, la richiesta viene instradata al servizio di backend corrispondente. Se la richiesta non corrisponde, viene utilizzato il servizio di backend predefinito.
Una regola semplice tipica dell'host e del percorso potrebbe avere il seguente aspetto, 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 ext-https-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
name: pathmap
pathRules:
- paths:
- /video
- /video/*
service: global/backendServices/video-backend-service
Per un esempio di configurazione, consulta Host e percorso.
Regola avanzata per host, percorso e route
Le regole avanzate per host, percorso e route offrono opzioni di configurazione aggiuntive rispetto alle semplici regole relative a host e percorso. Queste opzioni consentono modelli di gestione del traffico più avanzati e modificano anche parte della semantica. Ad esempio, le regole di route vengono eseguite in ordine, anziché utilizzare la semantica più lunga che corrisponde al percorso.
Come nel precedente esempio di semplice regola per host e percorso, puoi configurare la gestione avanzata del traffico utilizzando una mappa URL globale, ma invece di utilizzare pathMatchers[].pathRules[]
, puoi utilizzare pathMatchers[].routeRules[]
.
Le seguenti sezioni illustrano i componenti avanzati delle regole host, percorso e route.
Regole host
Quando una richiesta raggiunge il bilanciatore del carico, il relativo campo host
viene valutato in base al valore hostRules
definito nella mappa URL. Ogni regola host
è composta da un elenco di uno o più host e da un matcher percorso singolo
(pathMatcher
). Se non viene definito alcun elemento hostRules
, la richiesta viene instradata a
defaultService
.
Per ulteriori informazioni, consulta hostRules[]
e defaultService
nella
documentazione relativa all'API mappa URL globale.
Matcher percorso
Dopo che una richiesta corrisponde a una regola host, il bilanciatore del carico valuta il matcher percorso corrispondente all'host.
Un matcher percorso è costituito dai seguenti componenti:
- Una o più regole del percorso (
pathRules
) o regole di route (routeRules
). Una regola predefinita che viene eseguita quando non esistono altri servizi di backend corrispondenti. La regola prevede le seguenti opzioni che si escludono a vicenda:
- Un servizio predefinito specifica il servizio di backend predefinito a cui eseguire l'instradamento quando non esistono altri servizi di backend corrispondenti.
- Un reindirizzamento predefinito specifica l'URL a cui reindirizzare l'utente quando non esistono altri servizi di backend.
Quando il bilanciatore del carico è configurato per un servizio predefinito, può anche essere configurato in modo da riscrivere l'URL prima di inviare la richiesta al servizio predefinito.
Per ulteriori informazioni, consulta pathMatchers[]
, pathMatchers[].pathRules[]
e
pathMatchers[].routeRules[]
nella documentazione relativa all'API
globale URL Map.
Regole percorso
Le regole per i percorsi (pathRules
) specificano uno o più percorsi dell'URL, come /
o /video
.
Le regole per i percorsi sono in genere concepite per il tipo di routing semplice basato su host e percorso descritto in precedenza.
Per ulteriori informazioni, consulta pathRules[]
nella documentazione dell'API mappa URL globale.
Regole di route
Una regola di route (routeRules
) abbina le informazioni in una richiesta in entrata e prende una decisione di routing in base alla corrispondenza.
Le regole di route possono contenere una serie di regole di corrispondenza (matchRules
) e
diverse azioni di route (routeAction
).
Una regola di corrispondenza valuta la richiesta in entrata in base al percorso, alle intestazioni e parametri di ricerca della richiesta HTTP(S). Le regole di corrispondenza supportano vari tipi di corrispondenze (ad esempio, corrispondenza con prefisso) e modificatori (ad esempio, insensibilità alle maiuscole). Ciò consente, ad esempio, di inviare richieste HTTP(S) a un insieme di backend in base alla presenza di un'intestazione HTTP personalizzata.
Per un elenco dettagliato delle opzioni supportate da matchRules
, consulta matchRules[]
nella documentazione dell'API mappa URL globale.
Se hai più regole di route, il bilanciatore del carico le esegue in ordine, il che ti consente di specificare una logica personalizzata per la corrispondenza, il routing e altre azioni.
All'interno di una determinata regola di route, quando viene effettuata la prima corrispondenza, il bilanciatore del carico smette di valutare le regole di corrispondenza ed eventuali regole di corrispondenza rimanenti vengono ignorate.
Google Cloud esegue le seguenti azioni:
- Cerca la prima regola di corrispondenza che corrisponde alla richiesta.
- Smette di esaminare eventuali altre regole di corrispondenza.
- Applica le azioni nelle azioni di route corrispondenti.
Le regole di route hanno diversi componenti, come descritto nella tabella seguente.
Componente regola di route (API field name ) |
Descrizione |
---|---|
Priorità (priority ) |
Un numero da 0 a 2.147.483.647 (ovvero (2^31) -1) assegnato a una regola di route all'interno di un determinato matcher percorso per determinare l'ordine di valutazione della regola di route. La priorità più alta è 0 . La priorità più bassa è
2147483647 .
Ad esempio, una regola con priorità 4 viene valutata prima di una regola con priorità 25 . Viene applicata la prima regola che corrisponde alla richiesta.
I numeri di priorità possono avere lacune; non è necessario che siano contigui. Non puoi creare più regole 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 in caso di corrispondenza di questa regola. |
Regole di corrispondenza (matchRules ) |
Una o più regole che vengono valutate in base alla richiesta. Questi
matchRules possono corrispondere a tutti o a un sottoinsieme di attributi HTTP della richiesta,
come percorso, intestazioni HTTP e parametri di
query (GET).In un matchRule , tutti i criteri di corrispondenza devono essere soddisfatti affinché routeActions di routeRule abbia effetto. Se un routeRule ha più
matchRules , il routeActions di
routeRule ha effetto quando una richiesta corrisponde a uno qualsiasi degli
matchRules di routeRule .
|
Azione di routing (routeAction ) |
Consente di specificare un'azione di riscrittura dell'URL da eseguire quando vengono soddisfatti i criteri della regola di corrispondenza. |
Azione di reindirizzamento (urlRedirect ) |
Puoi configurare un'azione in modo che risponda con un reindirizzamento HTTP quando vengono soddisfatti i criteri della regola di corrispondenza. Questo campo non può essere utilizzato in combinazione con un'azione di route. |
Per ulteriori informazioni, consulta i seguenti campi nella documentazione dell'API mappa URL globale:
routeRules[]
routeRules[].priority
routeRules[].description
routeRules[].service
routeRules[].matchRules[]
routeRules[].routeAction
routeRules[].urlRedirect
Regole delle corrispondenze
Le regole di corrispondenza (matchRules
) corrispondono a uno o più attributi di una richiesta e eseguono le azioni specificate nella regola di route. Il seguente elenco fornisce alcuni esempi di attributi della richiesta 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 esempio del comando curl, dove10.1.2.9
è l'indirizzo IP con bilanciamento 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 relativa parte iniziale.Altri parametri di richiesta HTTP, come le intestazioni HTTP, che consentono la corrispondenza dei cookie, nonché la corrispondenza basata su parametri di ricerca (variabili GET). Tieni presente che la corrispondenza delle espressioni regolari per i valori di intestazione non è supportata.
Per un elenco completo delle regole di corrispondenza supportate, consulta
pathMatchers[].routeRules[].matchRules[]
nella documentazione dell'API
globale URL Map.
Configurazione della gestione del traffico
Puoi utilizzare la console Google Cloud, gcloud
o l'API Cloud Load Balancing per
configurare la gestione del traffico. All'interno dell'ambiente di configurazione prescelto, puoi impostare la gestione del traffico usando le configurazioni YAML.
Per assistenza nella scrittura di questi file YAML, puoi usare le seguenti risorse:
La documentazione relativa all'API mappa URL globale
Fornisce un elenco completo di campi, inclusa la semantica relativa a relazioni, restrizioni e cardinalità.
Esempi nella pagina di configurazione della gestione del traffico: