Configura la gestione avanzata del traffico con i servizi gRPC senza proxy
Questa configurazione è supportata per i clienti del servizio Anteprima, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per ulteriori informazioni, consulta Panoramica del routing del servizio Cloud Service Mesh.
Questo documento fornisce le istruzioni per configurare Cloud Service Mesh con le seguenti funzionalità di gestione del traffico:
- Corrispondenza di routing
- Suddivisione del traffico
- Interruttore di circuito
- Fault injection
- Durata massima stream
- Riprova
- Affinità sessione
- Rilevamento outlier
- Bilanciamento del carico per località
Questo documento è incentrato sulla configurazione di una gestione avanzata del traffico con gRPC senza proxy su Compute Engine, anche la gestione avanzata del traffico è supportata quando utilizzi gRPC proxyless su Google Kubernetes Engine (GKE).
Prima di iniziare
Prima di configurare la gestione avanzata del traffico, esamina i requisiti in Preparati a configurare Cloud Service Mesh con servizi gRPC senza proxy. Puoi configurare la gestione avanzata del traffico solo se sono soddisfatti tutti i requisiti sono soddisfatti.
Per informazioni concettuali su queste caratteristiche, vedi Gestione avanzata del traffico.
Informazioni sull'esempio di gRPC Wallet
Per illustrare queste funzionalità, esegui il deployment di un esempio di gRPC Wallet. In questo esempio
esistono tre servizi gRPC: grpc.examples.wallet.Wallet
,
grpc.examples.wallet.stats.Stats
e grpc.examples.wallet.account.Account
,
il cui deployment viene eseguito come tre applicazioni separate.
Come illustrato di seguito
in questo diagramma, creerai un client gRPC che chiama il servizio Wallet
per ottenere
saldo di un account e chiama il servizio Stats
per ottenere il prezzo di una moneta.
Il servizio Wallet
chiama i servizi Stats
e Account
a
calcolare il saldo. Il servizio Stats
chiama anche Account
per ottenere informazioni sugli utenti.
Nell'esempio, esegui il deployment di due versioni delle implementazioni Wallet
e Stats
per illustrare il routing delle richieste
in base alle regole che hai configurato. Per simulare
per la creazione e il deployment di diverse versioni di un servizio,
per modificare il comportamento dei file binari che crei una sola volta.
- Il flag
--port
specifica la porta su cui viene utilizzato il servizio su un'istanza VM ascolta. - Il flag
--hostname_suffix
specifica un valore aggiunto al nome host dell'istanza VM che risponde a una richiesta. Viene aggiunto il valore risultante come metadatihostname
nella risposta. Questo ti aiuta a identificare di un'istanza in un gruppo di istanze ha risposto alla richiesta del client. - Il flag
--premium_only
con il valoretrue
specifica che il servizio è una versione premium del serviziostats
. - Il flag
--v1_behavior
con il valoretrue
specifica che il portafoglio il file binario si comporta come versione v1.
La tabella seguente mostra i valori di questi flag per ogni istanza VM che stia eseguendo uno dei servizi gRPC, il numero di istanze gruppo di istanze gestite e ai servizi di backend a cui appartengono questi gruppi di istanze.
Servizio di backend | Gruppo di istanze | Istanze | Flag del server |
---|---|---|---|
account |
account |
2 | --port=50053 --hostname_suffix="account"
|
stats |
stats |
2 | --port=50052 --hostname_suffix="stats" --account_server="xds:///account.grpcwallet.io"
|
stats-premium |
stats-premium |
2 | --port=50052 --hostname_suffix="stats_premium" --account_server="xds:///account.grpcwallet.io" --premium_only=true
|
wallet-v1 wallet-v1-affinity
|
wallet-v1 |
2 | --port=50051 --hostname_suffix="wallet_v1" --v1_behavior=true --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"
|
wallet-v2 |
wallet-v2 |
1 | --port=50051 --hostname_suffix "wallet_v2" --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"
|
Dopo aver eseguito il deployment di questi servizi, configura Cloud Service Mesh per il routing richieste a questi servizi di backend da un client di test, in base al routing nella tabella seguente. Il client si connette al nome host virtuale di un come indicato nella colonna Host.
Host | Regole delle corrispondenze | Azione route |
---|---|---|
wallet.grpcwallet.io |
Prefisso percorso: "/" Intestazione presente: "session_id"
|
Percorso per wallet-v1-affinity |
Prefisso percorso: "/" Titolo: {"route": "timeout"}
|
Imposta un timeout di 5 secondi e percorso per wallet-v2
|
|
Prefisso percorso: "/" Titolo: {"route": "fault"}
|
Non supera il 50% delle richieste e indirizza il resto a wallet-v2
|
|
Prefisso percorso: "/" Titolo: {"membership": "premium"}
|
Percorso verso wallet-v1 e riprova fino a 3 volte in caso di errore |
|
Percorso completo: /grpc.examples.wallet.Wallet/FetchBalance |
Percorso verso:wallet-v1 : 70%wallet-v2 : 30%
|
|
Predefinito | Percorso per wallet-v1 |
|
stats.grpcwallet.io |
Prefisso percorso: "/" Titolo: {"membership": "premium"}
|
Percorso per stats-premium |
Predefinito | Percorso per stats |
|
account.grpcwallet.io |
Prefisso percorso: "/" Titolo: {"route": "account-fault"}
|
Non supera il 30% delle richieste e indirizza il resto a account
|
Predefinito | account |
In questo esempio viene utilizzata una suddivisione del traffico 70/30 tra due servizi esistenti. Se
stanno dividendo il traffico verso un nuovo servizio a cui non è stato fatto riferimento
la mappa URL prima, aggiungi prima il nuovo servizio a weightedBackendServices
e
assegnagli un peso di 0
. Poi aumenta gradualmente la ponderazione
completamente gestito di Google Cloud.
Il client di test ha le seguenti opzioni che ti consentono di generare le richieste appropriate per dimostrare le funzionalità di gestione del traffico.
Opzione | Descrizione |
---|---|
--watch=true |
Metodi di streaming delle chiamate per controllare saldo/prezzo |
--unary_watch=true |
Chiama ripetutamente metodi unari per controllare saldo/prezzo |
--user=Alice |
Inserisci intestazione {"membership": "premium"} |
--user=Bob |
Inserisci intestazione {"membership": "normal"} |
--route=value |
Inserisci intestazione {"route": "value"} |
--affinity=true |
Inserisci intestazione {"session_id": "value"} |
Prepara l'ambiente locale
Per configurare l'ambiente locale per questi esempi, esegui questo comando :
Aggiorna il programma binario
gcloud
per assicurarti di avere l'ultima versione:gcloud components update
Scarica il repository di esempi:
sudo apt-get install git -y
Clona il repository corretto per l'esempio:
export EXAMPLES_VERSION=v1.1.x git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \ https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
crea e configura istanze del router Cloud
In questa sezione, creerai istanze di router Cloud in ogni regione e configurarle per Cloud NAT. Le VM create in questo esempio non hanno indirizzi IP esterni, ma che abbiano accesso a internet. Configurazione in corso... Il router Cloud con Cloud NAT fornisce l'accesso richiesto.
gcloud
Crea le istanze del router Cloud:
gcloud compute routers create nat-router-us-central1 \ --network=default \ --region=us-central1
Configura i router per Cloud NAT:
gcloud compute routers nats create nat-config \ --router-region=us-central1 \ --router=nat-router-us-central1 \ --nat-all-subnet-ip-ranges \ --auto-allocate-nat-external-ips
Crea il controllo di integrità e la regola firewall gRPC
In questa sezione creerai un controllo di integrità gRPC e una regola firewall per consentire Richieste di controllo di integrità gRPC per raggiungere la rete. In seguito, il controllo di integrità gRPC è associato ai servizi di backend in modo da poter controllare l'integrità le istanze di backend dei servizi di backend.
gcloud
Crea il controllo di integrità:
gcloud compute health-checks create grpc grpcwallet-health-check \ --use-serving-port
Crea la regola firewall per il controllo di integrità:
gcloud compute firewall-rules create grpcwallet-allow-health-checks \ --network default --action allow --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags allow-health-checks \ --rules tcp:50051-50053
Crea il modello di istanza
In questa sezione creerai un modello di istanza per eseguire il deployment di gRPC account
servizio esposto sulla porta 50053
.
gcloud
Crea il modello di istanza:
gcloud compute instance-templates create grpcwallet-account-template \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --tags=allow-health-checks \ --network-interface=no-address \ --image-family=debian-10 \ --image-project=debian-cloud \ --metadata-from-file=startup-script=<(echo "#! /bin/bash set -ex cd /root export HOME=/root sudo apt-get update -y pushd \$(mktemp -d) sudo apt-get install -y wget git wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz sudo cp /usr/local/go/bin/go /usr/bin/go popd git clone -b $EXAMPLES_VERSION --single-branch --depth=1 https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git cd traffic-director-grpc-examples/go/account_server/ go build . sudo systemd-run ./account_server --port 50053 --hostname_suffix account")
Crea il gruppo di istanze gestite
I gruppi di istanze gestite utilizzano la scalabilità automatica per creare nuove istanze VM necessaria. In questa sezione creerai un gruppo di istanze gestite utilizzando il modello di istanza creato nella sezione precedente.
gcloud
Crea il gruppo di istanze:
gcloud compute instance-groups managed create grpcwallet-account-mig-us-central1 \ --zone=us-central1-a \ --size=2 \ --template=grpcwallet-account-template
Configura la porta denominata
In questa sezione configurerai la porta denominata per il servizio gRPC. Il nome
è la porta su cui il servizio gRPC rimane in ascolto delle richieste. In questo
Ad esempio, la porta denominata è la porta 50053
.
gcloud
Crea la porta denominata:
gcloud compute instance-groups set-named-ports grpcwallet-account-mig-us-central1 \ --named-ports=grpcwallet-account-port:50053 \ --zone=us-central1-a
Crea il servizio di backend
In questa sezione, creerai una descrizione
servizio di backend
con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED
e il protocollo GRPC
.
Successivamente, assocerai il controllo di integrità e il gruppo di istanze al servizio di backend.
In questo esempio, utilizzerai il gruppo di istanze gestite creato in
Crea il gruppo di istanze gestite. Questo gruppo di istanze gestite esegue account
servizio gRPC. La porta nel flag --port-name
è la porta denominata che
creato in
Configura la porta denominata.
gcloud
Crea il servizio di backend, quindi associa il controllo di integrità al nuovo servizio di backend:
gcloud compute backend-services create grpcwallet-account-service \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --protocol=GRPC \ --port-name=grpcwallet-account-port \ --health-checks=grpcwallet-health-check
Aggiungi il gruppo di istanze gestite come backend:
gcloud compute backend-services add-backend grpcwallet-account-service \ --instance-group=grpcwallet-account-mig-us-central1 \ --instance-group-zone=us-central1-a \ --global
I passaggi per creare i servizi di backend rimanenti utilizzati nel portafoglio gRPC sono simili ai passaggi precedenti. Puoi creare i servizi rimanenti eseguendo uno script shell. Lo script esegue il deployment dei seguenti servizi di backend:
stats
stats-premium
wallet-v1
wallet-v1-affinity
wallet-v2
Esegui lo script shell che crea i servizi di backend aggiuntivi:
traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats '--account_server="xds:///account.grpcwallet.io"' traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats-premium '--account_server="xds:///account.grpcwallet.io" --premium_only=true' # This command creates wallet-v1 and wallet-v1-affinity backend services. traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v1 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io" --v1_behavior=true' traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v2 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"'
Crea le regole di routing
In questa sezione, creerai una mappa URL utilizzata per illustrare vari funzionalità di gestione del traffico. La mappa URL specifica i nomi host virtuali i servizi in questo esempio e le regole di routing associate. Per ulteriori informazioni per informazioni, consulta Mappe di regole di routing.
Nella mappa URL, il campo hostRules
specifica i nomi host virtuali
servizi nell'esempio. Questi sono i nomi utilizzati dal cliente nel canale
URI per la connessione a un servizio specifico. Ad esempio, per inviare una richiesta
Servizio account
, un client utilizza xds:///account.grpcwallet.io
nel canale
URI. In hostRules
, configura una voce hosts
con il valore
account.grpcwallet.io
.
Il parametro pathMatcher
associato a una voce hosts
specifica il nome di un
pathMatcher
che contiene tutte le regole di routing per quell'host virtuale. R
La configurazione di pathMatcher
è composta da regole di corrispondenza e azione corrispondente
come descritto in Informazioni sull'esempio di Wallet gRPC.
gcloud
Crea la mappa URL:
export PROJECT_ID=$(gcloud config list --format 'value(core.project)') export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet gcloud compute url-maps import grpcwallet-url-map << EOF name: grpcwallet-url-map defaultService: $BS_PREFIX-account-service hostRules: - hosts: - account.grpcwallet.io pathMatcher: grpcwallet-account-path-matcher - hosts: - stats.grpcwallet.io pathMatcher: grpcwallet-stats-path-matcher - hosts: - wallet.grpcwallet.io pathMatcher: grpcwallet-wallet-path-matcher pathMatchers: - name: grpcwallet-account-path-matcher defaultService: $BS_PREFIX-account-service routeRules: - matchRules: - prefixMatch: / headerMatches: - headerName: route exactMatch: account-fault priority: 0 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-account-service weight: 100 faultInjectionPolicy: abort: httpStatus: 503 percentage: 30 - name: grpcwallet-stats-path-matcher defaultService: $BS_PREFIX-stats-service routeRules: - matchRules: - prefixMatch: / headerMatches: - headerName: membership exactMatch: premium priority: 0 service: $BS_PREFIX-stats-premium-service - name: grpcwallet-wallet-path-matcher defaultService: $BS_PREFIX-wallet-v1-service routeRules: - matchRules: - prefixMatch: / headerMatches: - headerName: session_id presentMatch: true priority: 0 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v1-affinity-service weight: 100 - matchRules: - prefixMatch: / headerMatches: - headerName: route exactMatch: timeout priority: 1 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v2-service weight: 100 maxStreamDuration: seconds: 5 - matchRules: - prefixMatch: / headerMatches: - headerName: route exactMatch: fault priority: 2 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v2-service weight: 100 faultInjectionPolicy: abort: httpStatus: 503 percentage: 50 - matchRules: - prefixMatch: / headerMatches: - headerName: membership exactMatch: premium priority: 3 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v1-service weight: 100 retryPolicy: retryConditions: - unavailable numRetries: 3 - matchRules: - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance priority: 4 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v1-service weight: 70 - backendService: $BS_PREFIX-wallet-v2-service weight: 30 - matchRules: - prefixMatch: /grpc.examples.wallet.Wallet/ priority: 5 routeAction: weightedBackendServices: - backendService: $BS_PREFIX-wallet-v2-service weight: 100 EOF
Crea il proxy di destinazione e la regola di forwarding
In questa sezione creerai il proxy gRPC di destinazione e una regola di forwarding.
Il proxy gRPC di destinazione fa riferimento alla mappa URL che hai creato nel passaggio precedente.
Il flag --validate-for-proxyless
abilita i controlli della configurazione
abilitare accidentalmente una funzionalità non compatibile con gRPC senza proxy
deployment di machine learning.
gcloud
Crea il proxy gRPC di destinazione:
gcloud compute target-grpc-proxies create grpcwallet-proxy \ --url-map=grpcwallet-url-map \ --validate-for-proxyless
La regola di forwarding fa riferimento al proxy gRPC di destinazione che hai creato. La
lo schema di bilanciamento del carico è impostato su INTERNAL_SELF_MANAGED
per indicare che
di regola di forwarding che viene utilizzata da Cloud Service Mesh. Deve essere globale
di una regola di forwarding. L'indirizzo IP è impostato su 0.0.0.0
perché una gRPC senza proxy
risolve il valore hostname:port
nell'URI di destinazione inviando un
Richiesta LDS a Cloud Service Mesh invece di eseguire una ricerca DNS. Per ulteriori informazioni
informazioni, vedi Schema di risoluzione dei nomi.
Se nell'URI di destinazione non è specificata una porta, il valore predefinito è 80
. Per
Ad esempio, un URI di destinazione xds:///foo.myservice:8080
corrisponde a una regola di forwarding che
è configurata con la porta 8080
. In questo esempio, la regola di forwarding è
configurata con la porta 80
.
gcloud
Crea la regola di forwarding:
gcloud compute forwarding-rules create grpcwallet-forwarding-rule \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --address=0.0.0.0 \ --address-region=us-central1 \ --target-grpc-proxy=grpcwallet-proxy \ --ports=80 \ --network=default
Verificare la configurazione
Al termine del processo di configurazione, verifica che i servizi di backend che hai configurato siano disponibili controllando Pagina Cloud Service Mesh nella console Google Cloud. Conferma che i servizi di backend e i backend associati siano segnalati come integro. L'operazione potrebbe richiedere alcuni minuti.
Verificare la configurazione del routing
In questa sezione verificherai che la configurazione del routing funzioni correttamente.
Utilizzi lo strumento grpcurl
per testare la configurazione.
gcloud
Crea una VM client su cui esegui i client per testare completamente gestito di Google Cloud. Se vuoi, puoi includere
--network-interface=no-address
flag.gcloud compute instances create grpc-wallet-client \ --zone=us-central1-a \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --image-family=debian-10 \ --image-project=debian-cloud \ --metadata-from-file=startup-script=<(echo '#! /bin/bash set -e export GRPC_XDS_BOOTSTRAP=/run/td-grpc-bootstrap.json # Expose bootstrap variable to SSH connections echo export GRPC_XDS_BOOTSTRAP=$GRPC_XDS_BOOTSTRAP | sudo tee /etc/profile.d/grpc-xds-bootstrap.sh # Create the bootstrap file curl -L https://storage.googleapis.com/traffic-director/td-grpc-bootstrap-0.11.0.tar.gz | tar -xz ./td-grpc-bootstrap-0.11.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')
Accedi alla VM mediante SSH ed esegui i comandi seguenti per preparare la VM:
export EXAMPLES_VERSION=v1.1.x sudo apt-get update sudo apt-get install git -y
Esegui questi comandi:
git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \ https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git curl -L https://github.com/fullstorydev/grpcurl/releases/download/v1.6.1/grpcurl_1.6.1_linux_x86_64.tar.gz | tar -xz chmod +x grpcurl
Per accedere ai servizi senza un proxy sidecar, il client gRPC deve utilizzare la classe
Schema di risoluzione dei nomi xds
. Questo schema indica alla libreria gRPC utilizzata nel client
di utilizzare un server xDS per risolvere il nome host. A tale scopo, viene usato un bootstrap
configurazione obbligatoria.
Lo script di avvio nella sezione precedente imposta
GRPC_XDS_BOOTSTRAP
e utilizza uno script di supporto per generare
il file di bootstrap. I valori per TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
,
TRAFFICDIRECTOR_NETWORK_NAME
e la zona nel file di bootstrap generato sono
ottenute dal server dei metadati che conoscono i dettagli dei tuoi
di istanze VM di Compute Engine. Puoi fornire questi valori allo script di supporto
manualmente usando le opzioni -gcp-project-number
e -vpc-network-name
.
Verifica la configurazione utilizzando lo strumento grpcurl
Esegui questi comandi nella shell SSH per verificare che wallet-service
,
stats-service
e account-service
sono in esecuzione:
./grpcurl -plaintext xds:///account.grpcwallet.io list ./grpcurl -plaintext -d '{"token": "2bd806c9"}' xds:///account.grpcwallet.io grpc.examples.wallet.account.Account/GetUserInfo ./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' xds:///stats.grpcwallet.io grpc.examples.wallet.stats.Stats/FetchPrice ./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' -d '{"include_balance_per_address": true}' xds:///wallet.grpcwallet.io grpc.examples.wallet.Wallet/FetchBalance
Vengono visualizzati i seguenti risultati:
grpc.examples.wallet.account.Account grpc.health.v1.Health grpc.reflection.v1alpha.ServerReflection { "name": "Alice", "membership": "PREMIUM" } { "price": "10295" } { "balance": "5089953" }
Verifica con grpc-wallet
clienti
Segui le seguenti istruzioni specifiche per la lingua per verificare la configurazione. I comandi inviano più RPC, alcune con metadati aggiuntivi, per mostrare che le richieste vengono indirizzate ai servizi di backend in base alle regole di corrispondenza indicate nella mappa URL. Il comando stampa anche il nome host dell'istanza VM per ogni risposta a per visualizzare l'istanza VM a cui è stata instradata la richiesta.
Java
Per verificare il servizio con un client Java gRPC, esegui questo comando:
sudo apt-get install -y openjdk-11-jdk-headless
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./gradlew installDist # This command calls 'FetchBalance' from 'wallet-service' in a loop, # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%) # and 'wallet-v2' (30%). ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'. # The RPC path matches the service prefix, so all requests are # sent to 'wallet-v2'. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob # This command calls 'WatchPrice' from 'stats-service'. It sends the # user's membership (premium or not) in metadata. Premium requests are # all sent to 'stats-premium' and get faster responses. Alice's requests # always go to premium and Bob's go to regular. ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
Vai
Per verificare il servizio con un client gRPC Go, installa golang o segui le istruzioni ufficiali:
sudo apt-get install -y wget wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz sudo ln -s /usr/local/go/bin/go /usr/bin/go
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client go build # This command calls 'FetchBalance' from 'wallet-service' in a loop, # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%) # and 'wallet-v2' (30%). ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'. # The RPC path matches the service prefix, so all requests # are sent to 'wallet-v2'. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob # This command calls 'WatchPrice' from 'stats-service'. It sends the # user's membership (premium or not) in metadata. Premium requests are # all sent to 'stats-premium' and get faster responses. Alice's requests # always go to premium and Bob's go to regular. ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Bob ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Alice
C++
Per verificare il servizio con un client gRPC C++, esegui questo comando:
sudo apt-get install -y build-essential
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../tools/bazel build :client # This command calls 'FetchBalance' from 'wallet-service' in a loop, # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%) # and 'wallet-v2' (30%). ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'. # The RPC path matches the service prefix, so all requests are sent to 'wallet-v2'. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob # This command calls 'WatchPrice' from 'stats-service'. It sends the # user's membership (premium or not) in metadata. Premium requests are # all sent to 'stats-premium' and get faster responses. Alice's requests # always go to premium, and Bob's go to regular. ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
Configura opzioni più avanzate
Puoi configurare altre opzioni avanzate di routing del traffico utilizzando il metodo istruzioni nelle sezioni seguenti.
Interruttore di circuito
L'interruzione di circuiti consente di impostare soglie di errore per impedire le richieste del client di sovraccaricare i tuoi servizi di backend. Dopo il numero di richieste in sospeso raggiunge il limite impostato, il client smette di inviare richieste aggiuntive concedendo ai servizi di backend il tempo di recuperare.
L'interruzione del circuito impedisce gli errori a cascata restituendo un errore al anziché sovraccaricare un servizio di backend. Ciò permette al traffico di il tempo necessario per gestire la situazione di sovraccarico, ad esempio gestire un picco di traffico aumentando la capacità tramite la scalabilità automatica.
Quando crei il servizio di backend per stats-service
,
Lo script create_service.sh
include le seguenti righe nella sua configurazione:
circuitBreakers: maxRequests: 1
Questa impostazione limita i client a una richiesta in attesa a stats-service
a un
nel tempo. Poiché è presente un solo servizio wallet-v2
, vengono in esecuzione due simultanei
Le operazioni del client Wallet WatchBalance
mostrano errori dal secondo
in esecuzione in un'istanza Compute Engine.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null & sleep 10 # Wait a few seconds to allow the watch to begin. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
L'output è simile al seguente:
io.grpc.examples.wallet.Client run INFO: Will try to run balance io.grpc.examples.wallet.Client run WARNING: RPC failed: Status{code=INTERNAL, description=RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded, cause=null}
Esegui il comando
kill
:kill %%
Vai
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob 2> /dev/null 1> /dev/null & sleep 10 # Wait a few seconds to allow the watch to begin. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
L'output è simile al seguente:
server host: error: no hostname failed to fetch balance: rpc error: code = Internal desc = RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded
Esegui il comando
kill
:kill %%
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null & sleep 10 # Wait a few seconds to allow the watch to begin. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
L'output è simile al seguente:
Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server: localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: 13: RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded
Esegui il comando
kill
:kill %%
Fault injection
Fault injection introduce errori durante la gestione delle richieste per simulare gli errori, tra cui alta latenza, sovraccarico del servizio, errori del servizio e rete il partizionamento orizzontale. Questa funzionalità è utile per testare la resilienza di un servizio di errori simulati.
Quando hai creato la mappa URL in precedenza, hai impostato il criterio di fault injection su
ha esito negativo per il 50% delle RPC inviate a wallet.grpcwallet.io
con route=fault
intestazione.
Per dimostrare la fault injection, utilizza il codice nei seguenti linguaggi.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
L'output è simile al seguente:
server host: grpcwallet-wallet-v2-mig-us-central1-zznc total balance: 10340491 - address: 148de9c5, balance: 2549839 - address: 2e7d2c03, balance: 7790652 io.grpc.examples.wallet.Client run WARNING: RPC failed: Status{code=UNAVAILABLE, description=RPC terminated due to fault injection: HTTP status code 503, cause=null}
Vai
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob --route=fault
L'output è simile al seguente:
server host: grpcwallet-wallet-v1-mig-us-central1-bm1t_wallet-v1 user: Bob, total grpc-coin balance: 10452589. - address: 2e7d2c03, balance: 7875108. - address: 148de9c5, balance: 2577481. failed to fetch balance: rpc error: code = Unavailable desc = RPC terminated due to fault injection
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
L'output è simile al seguente:
Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server: localhost:18882, user: Bob, watch: 0 ,unary_watch: 1, observability_project: , route: fault server host: grpcwallet-wallet-v2-mig-us-central1-1lm6 user: Bob total grpc-coin balance: 10211908 - address: 148de9c5, balance: 2518132 - address: 2e7d2c03, balance: 7693776 14: Fault injected
Durata massima stream
La durata massima del flusso consente di applicare un timeout massimo a tutte le RPC. Questo previene i client che dimenticano di impostare una scadenza o che impostano una scadenza per lo spreco di risorse del server.
Quando hai creato la mappa URL in precedenza, hai impostato una durata massima dello stream di 5
secondi per le RPC inviate a wallet.grpcwallet.io
con l'intestazione route=timeout
.
Per dimostrare i timeout, prima interrompiamo il servizio wallet-v2
.
gcloud
gcloud compute instance-groups managed resize \ --size=0 grpcwallet-wallet-v2-mig-us-central1 \ --zone=us-central1-a
Il seguente comando sarebbe bloccato definitivamente perché non è presente alcun backend per gestirlo e l'applicazione non fissa una scadenza.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Il comando smette di rispondere. Premi ^C per interrompere il comando.
Vai
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
Il comando smette di rispondere. Premi ^C per interrompere il comando.
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Il comando smette di rispondere. Premi ^C per interrompere il comando.
Tuttavia, il seguente comando che utilizza la route timeout
non riesce dopo 5 secondi
grazie all'impostazione maxStreamDuration
.
Java
Esegui questo comando:
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
L'output è simile al seguente:
io.grpc.examples.wallet.Client run WARNING: RPC failed: Status{code=DEADLINE_EXCEEDED, description=deadline exceeded after 4.999594070s. [wait_for_ready, buffered_nanos=5000553401, waiting_for_connection], cause=null}
Vai
Esegui questo comando:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob --route=timeout
L'output è simile al seguente:
failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.
C++
Esegui questo comando:
cd ~/traffic-director-grpc-examples/cpp ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
L'output è simile al seguente:
Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server: localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: timeout 4: Deadline Exceeded
Riavvia il servizio wallet-v2
.
gcloud
gcloud compute instance-groups managed resize \ --size=1 grpcwallet-wallet-v2-mig-us-central1 \ --zone=us-central1-a
Riprova
I nuovi tentativi consentono di migliorare la disponibilità del servizio abilitando gRPC applicazioni per ritentare le richieste in uscita in base a un criterio per i nuovi tentativi. Nuovo tentativo puoi configurare le condizioni in base alle quali una richiesta non riuscita dovrebbe essere nuovi tentativi e il numero massimo di nuovi tentativi, ad esempio quando una richiesta con un determinato codice di risposta.
Quando hai creato in precedenza la mappa URL, hai impostato un criterio per i nuovi tentativi per le RPC nel
FetchBalance
con il metodo
Intestazione membership=premium
. Questo criterio esegue un nuovo tentativo delle RPC con stato Non riuscito
il codice unavailable
per un massimo di 3 volte. Imposti anche una fault injection
per le RPC verso account.grpcwallet.io
con route=account-fault
che non supera il 30% delle RPC dal servizio Wallet
al Account
completamente gestito di Google Cloud. Di conseguenza, il 30% delle RPC del client di test con
L'intestazione membership=normal
ha esito negativo, mentre la percentuale di errori per le RPC con
L'intestazione membership=premium
è inferiore all'1%.
Per dimostrare i nuovi tentativi, utilizza il codice nei seguenti linguaggi.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java # 30% of the requests fail because Bob is a normal user. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault # Less than 1% of the requests fail because Alice is a premium user. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault
Vai
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client # 30% of the requests fail because Bob is a normal user. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault # Less than 1% of the requests fail because Alice is a premium user. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp # 30% of the requests fail because Bob is a normal user. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault # Less than 1% of the requests fail because Alice is a premium user. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault
Affinità sessione
L'affinità sessione consente di inviare richieste con il criterio del "best effort" particolari caratteristiche (intestazioni HTTP) alla stessa istanza per tutto il tempo l'istanza è in stato integro e ha capacità. È utile per gli oggetti che traggono vantaggio da prestazioni ed efficienza migliorate quando di un client specifico vengono inviate alla stessa istanza, invece di ad esempio la distribuzione Round Robin a diverse istanze.
Quando hai creato il servizio di backend grpcwallet-wallet-v1-affinity-service
,
nello script create_service.sh
, localityLbPolicy
è stato impostato su
ROUND_ROBIN
. In questo esempio, applicherai la configurazione seguente a
cambia localityLbPolicy
in RING_HASH
.
sessionAffinity: HEADER_FIELD localityLbPolicy: RING_HASH consistentHash: httpHeaderName: "session_id"
gcloud
Salva la configurazione del servizio di backend
grpcwallet-wallet-v1-affinity-service
:gcloud compute backend-services export grpcwallet-wallet-v1-affinity-service \ --destination=bs_config.yaml \ --global
Aggiorna il servizio di backend
grpcwallet-wallet-v1-affinity-service
:project_id="$(gcloud config list --format 'value(core.project)')" backend_config=" backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: projects/${project_id}/zones/us-central1-a/instanceGroups/grpcwallet-wallet-v1-mig-us-central1 connectionDraining: drainingTimeoutSec: 0 healthChecks: - projects/${project_id}/global/healthChecks/grpcwallet-health-check loadBalancingScheme: INTERNAL_SELF_MANAGED name: grpcwallet-wallet-v1-affinity-service portName: grpcwallet-wallet-port protocol: GRPC sessionAffinity: HEADER_FIELD localityLbPolicy: RING_HASH consistentHash: httpHeaderName: session_id" gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service --global <<< "${backend_config}"
Per dimostrare l'affinità sessione, utilizza il codice nei seguenti linguaggi. Con
il flag --affinity=true
, il client inserisce un'intestazione session-id
con un
un valore univoco
per ciascun utente. Un hash di questo valore viene utilizzato per inviare la richiesta
a una determinata istanza nel gruppo di istanze del servizio di backend
grpcwallet-wallet-v1-affinity-service
.
Java
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/java # Without affinity, requests are sent to both instances. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice # With affinity, requests are sent to only one instance. ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true
Vai
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/go/wallet_client # Without affinity, requests are sent to both instances. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice # With affinity, requests are sent to only one instance. ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true
C++
Esegui questi comandi:
cd ~/traffic-director-grpc-examples/cpp # Without affinity, requests are sent to both instances. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice # With affinity, requests are sent to only one instance. ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true
Ripristina la configurazione del servizio di backend grpcwallet-wallet-v1-affinity-service
.
gcloud
gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service \ --source=bs_config.yaml \ --global
Rilevamento outlier
Per migliorare la disponibilità del servizio, configura il rilevamento outlier. Questa funzionalità ti consente di Identifichi ed espelli temporaneamente gli host in stato non integro dal bilanciamento del carico piscina. Questi host in stato non integro sono chiamati outlier.
gRPC valuta gli host in base alla percentuale di successo, ovvero la frequenza con cui un host gestisce correttamente le richieste. La tariffa è influenzata da ad esempio errori gRPC, errori HTTP, timeout e altri problemi.
Quando configuri il rilevamento outlier tramite Cloud Service Mesh, puoi ottimizzare il modo in cui gRPC valuta gli host e gestisce gli outlier. Ad esempio, possono specificare criteri quali:
Il numero di richieste che un host deve ricevere prima di gRPC la analizza per individuare eventuali stati outlier.
La misura in cui un host può discostarsi dal tasso di successo medio prima considerato un outlier.
La percentuale massima di host che può essere espulsa in qualsiasi momento da del pool di bilanciamento del carico.
Il periodo di tempo per cui un outlier viene escluso dal bilanciamento del carico piscina.
Per ulteriori informazioni sui parametri disponibili, consulta
REST Resource: backendServices
riferimento. Tuttavia, esistono alcune limitazioni per gRPC, come descritto
sezione successiva.
Limitazioni
I seguenti campi non sono supportati per i client gRPC:
outlierDetection.consecutiveErrors
outlierDetection.enforcingConsecutiveErrors
outlierDetection.consecutiveGatewayFailure
outlierDetection.enforcingConsecutiveGatewayFailure
Configura il rilevamento outlier
La procedura seguente mostra come configurare il rilevamento outlier per un servizio che utilizza un gruppo di istanze come backend. Questa procedura stabilisce con la seguente configurazione:
- L'analisi del rilevamento outlier viene eseguita ogni secondo. Configuralo
un comportamento corretto usando il campo
interval
. - I valori anomali vengono espulsi dal pool di bilanciamento del carico per incrementi di 30
secondi, come segue:
- Se un host non è mai stato escluso in precedenza, viene espulso solo per 30 secondi.
- Se un host è stato escluso in precedenza, il tempo aumenta di 30 secondi per
a ogni espulsione precedente. Ad esempio, quando un host viene escluso per un terzo
volta, viene espulso per 90 secondi.
Per configurare questo comportamento, utilizza il campo
baseEjectionTime
.
- Un host è considerato in stato non integro se il suo tasso di successo è una deviazione standard
sotto la media durante l'intervallo di tempo selezionato (in questo caso, 1 secondo). Tu
configurare la deviazione standard massima utilizzando
campo
successRateStdevFactor
.
Per configurare il rilevamento outlier in questo modo, segui questi passaggi.
gcloud
Esporta il servizio di backend
grpcwallet-wallet-v2-service
di configurazione del deployment Comandogcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Nel file
bs_config.yaml
, aggiornagrpcwallet-wallet-v2-service
configurazione per includere i campi di rilevamento outlier:outlierDetection: interval: seconds: 1 nanos: 0 baseEjectionTime: seconds: 30 nanos: 0 successRateStdevFactor: 1000
Importa il file aggiornato utilizzando il metodo Comando
gcloud compute backend-services import
:gcloud compute backend-services import grpcwallet-wallet-v2-service \ --source=bs_config.yaml \ --global
Bilanciamento del carico per località
Per utilizzare al meglio le tue risorse, configura il carico per le località e del bilanciamento del carico. Questa funzione consente di risparmiare risorse distribuendo in modo uniforme richieste del client dai tuoi backend.
Quando configuri il bilanciamento del carico per località, puoi utilizzare le opzioni descritte
nella tabella seguente. Tutte le opzioni richiedono la configurazione
backendServices
.
Opzione | Disponibile per | Campo di configurazione pertinente |
---|---|---|
Utilizzare un criterio integrato | Tutti i client gRPC | localityLbPolicy |
Utilizzare una norma personalizzata | Client Java che utilizzano gRPC versione 1.47 o successiva, in un mesh include solo client gRPC | localityLbPolicies
|
Definire un elenco di criteri preferiti | Client Java che utilizzano gRPC versione 1.47 o successiva, in un mesh include solo client gRPC | localityLbPolicies |
Puoi utilizzare qualsiasi combinazione delle opzioni precedenti. Tuttavia, se
configura localityLbPolicy
e localityLbPolicies
, primi tentativi gRPC
per utilizzare la tua configurazione localityLbPolicies
.
Se non configuri il bilanciamento del carico per le località, Cloud Service Mesh utilizza la classe
ROUND_ROBIN
criterio.
Per informazioni su ROUND_ROBIN
e altri criteri integrati, consulta
descrizione di localityLbPolicy
in
backendServices
.
Utilizza un criterio integrato
Se vuoi che tutti i tuoi client utilizzino un unico criterio integrato, puoi selezionare
configurando il campo localityLbPolicy
.
Quando configuri questo campo, puoi scegliere tra i seguenti criteri:
LEAST_REQUEST
(solo client Java)RING_HASH
ROUND_ROBIN
Se non tutti i tuoi clienti possono utilizzare la stessa norma, consulta Definisci un elenco di criteri preferiti.
gcloud
Esporta la configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando l'APIgcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Aggiorna il file
bs_config.yaml
esportato per includere il seguenti righe:localityLbPolicy: -- policy name: RING_HASH
Importa il file aggiornato utilizzando gcloud compute backend-services import :
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
Utilizza una norma personalizzata
Se appropriato, puoi utilizzare un criterio di bilanciamento del carico personalizzato che hai creato distribuito con gRPC. Questa funzionalità è disponibile per i client Java che utilizzano gRPC versione 1.47 o successive. Utilizzalo solo in una mesh che include tutti i client gRPC.
Quando crei una norma personalizzata, la seguente documentazione potrebbe essere utile:
Per rendere le norme personalizzate più sofisticate, puoi utilizzare il pulsante API di aggregazione dei costi (ORCA). Queste API ti consentono di acquisire e metriche sul costo delle query e sull'utilizzo del server. L'utilizzo di queste API richiede gRPC 1.48.1 o versioni successive. Per ulteriori informazioni, vedi Esempio di gRPC ORCA.
Per informazioni su come vengono configurate le configurazioni di bilanciamento del carico personalizzato consegnati a gRPC da xDS, Configurazione del bilanciatore del carico personalizzato gRPC xDS.
Per configurare Cloud Service Mesh per l'utilizzo del criterio personalizzato, identifica il criterio
utilizzando il campo localityLbPolicies
.
I passaggi seguenti illustrano questa procedura. In questa procedura,
aggiorni la configurazione del backend grpcwallet-wallet-v2-service
in modo che i client che vi si connettono utilizzino un criterio personalizzato denominato
example.ExampleLoadBalancer
.
gcloud
Esporta la configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando l'APIgcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Aggiorna il file
bs_config.yaml
esportato per fare riferimento allaexample.ExampleLoadBalancer
. Includi le seguenti righe:localityLbPolicies: - customPolicy: name: example.ExampleLoadBalancer data: '{ "message": "Hello load-balancing world!" }'
Importa il file aggiornato utilizzando gcloud compute backend-services import :
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
(Facoltativo) Testa la configurazione di bilanciamento del carico:
Java
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Se hai configurato correttamente il criterio di bilanciamento del carico personalizzato, vedrai il messaggio che hai incluso nella configurazione ("Un mondo di bilanciamento del carico!").
Definisci un elenco di criteri preferiti
Se hai più client che non supportano tutti un singolo bilanciamento del carico crea un elenco di norme utilizzabili dai clienti. Con questa opzione, se il tuo primo criterio preferito non può essere usato da un determinato client, gRPC torna al criterio successivo nell'elenco.
Quando crei un elenco di criteri preferiti, le opzioni valide includono:
criteri personalizzati, ROUND_ROBIN
e, per i client Java, LEAST_REQUEST
. Tu
possono elencare fino a 10 criteri.
Questa funzionalità è disponibile solo per i client Java che utilizzano gRPC versione 1.47 o in un secondo momento. Utilizzalo solo in una mesh che include tutti i client gRPC.
gcloud
- Esporta la configurazione del servizio di backend
grpcwallet-wallet-v2-service
utilizzando l'APIgcloud compute backend-services export
:
gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Aggiorna il file
bs_config.yaml
esportato per includere illocalityLbPolicies
. Compilalo con voci che rappresentano i seguenti criteri:- Un criterio personalizzato non valido (
example.InvalidLoadBalancer
) - Un criterio personalizzato valido (
example.ExampleLoadBalancer
) - Un criterio integrato supportato (
LEAST_REQUEST
)
localityLbPolicies: - customPolicy: name: example.InvalidLoadBalancer data: '{ "message": "This load-balancing policy doesn't work!" }' - customPolicy: name: example.ExampleLoadBalancer data: '{ "message": "Hello load-balancing world!" }' - policy: name: LEAST_REQUEST
- Un criterio personalizzato non valido (
Importa il file aggiornato utilizzando gcloud compute backend-services import :
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
(Facoltativo) Testa la configurazione di bilanciamento del carico:
Java
cd ~/traffic-director-grpc-examples/java ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
Nella risposta, gRPC prova ma non riesce a trovare
example.InvalidLoadBalancer
. In seguito, torna a utilizzareexample.ExampleLoadBalancer
e hai visto il messaggio che hai incluso nella configurazione ("Hello Load Balancing World!"). Il logging gRPC sul client include un messaggio che indica che Impossibile trovareexample.InvalidLoadBalancer
.
Esegui la pulizia delle risorse
Per eseguire la pulizia delle risorse, esegui questo comando dal sistema locale:
traffic-director-grpc-examples/scripts/cleanup.sh
Blocca il traffico tra i servizi
Se vuoi bloccare il traffico tra il servizio A e il servizio B, e il tuo deployment è su GKE, configurare la sicurezza del servizio e utilizzare per bloccare il traffico tra i servizi. Per istruzioni complete, vedi Sicurezza del servizio Cloud Service Mesh e le istruzioni di configurazione con Envoy e gRPC senza proxy.
Passaggi successivi
- Per risolvere i problemi di configurazione di Cloud Service Mesh, consulta Risoluzione dei problemi dei deployment che utilizzano gRPC senza proxy.