Configura la gestione avanzata del traffico con servizi gRPC senza proxy

Nota: questa guida supporta solo Cloud Service Mesh con le API Google Cloud e non supporta le API Istio. Per maggiori informazioni, consulta la panoramica di Cloud Service Mesh.

Questa configurazione è supportata per i clienti in anteprima, ma non è consigliata per i nuovi utenti di Cloud Service Mesh. Per maggiori informazioni, consulta la panoramica del routing del servizio Cloud Service Mesh.

Questo documento fornisce istruzioni per configurare Cloud Service Mesh con le seguenti funzionalità di gestione del traffico:

• Corrispondenza percorso
• Suddivisione del traffico
• Interruzione di circuito
• Fault injection
• Durata massima dello stream
• Riprova
• Affinità sessione
• Rilevamento outlier
• Bilanciamento del carico per le località

Sebbene questo documento sia incentrato sulla configurazione della gestione avanzata del traffico con gRPC senza proxy su Compute Engine, la gestione avanzata del traffico è supportata anche quando utilizzi gRPC senza proxy su Google Kubernetes Engine (GKE).

Prima di iniziare

Prima di configurare la gestione avanzata del traffico, rivedi i requisiti in Prepararsi a configurare Cloud Service Mesh con servizi gRPC senza proxy. Non puoi configurare la gestione avanzata del traffico se non vengono soddisfatti tutti i requisiti.

Per informazioni concettuali su queste funzionalità, consulta Gestione avanzata del traffico.

Informazioni sull'esempio di Wallet gRPC

Per illustrare queste funzionalità, esegui il deployment di un esempio di Wallet gRPC. In questo esempio sono presenti tre servizi gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats e grpc.examples.wallet.account.Account, di cui viene eseguito il deployment come tre applicazioni separate.

Come mostrato nel seguente diagramma, crei un client gRPC che chiama il servizio Wallet per ottenere il 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 per calcolare il saldo. Il servizio Stats chiama anche il servizio Account per ottenere informazioni sugli utenti.

Esempio di configurazione del routing del traffico di Wallet gRPC (fai clic per ingrandire)

Nell'esempio, esegui il deployment di due versioni delle implementazioni Wallet e Stats per illustrare il routing delle richieste in base alle regole configurate. Per simulare la creazione e il deployment di versioni diverse di un servizio, utilizza i flag server per modificare il comportamento dei programmi binari che crei una sola volta.

• Il flag --port specifica la porta su cui viene eseguito l'ascolto del servizio su un'istanza VM.
• Il flag --hostname_suffix specifica un valore che viene aggiunto al nome host dell'istanza VM che risponde a una richiesta. Il valore risultante viene aggiunto come metadati hostname nella risposta. Ciò ti aiuta a identificare l'istanza in un gruppo di istanze che ha risposto alla richiesta del client.
• Il flag --premium_only con il valore true specifica che il servizio è una versione premium del servizio stats.
• Il flag --v1_behavior con il valore true specifica che il file binario del wallet si comporta come una versione v1.

La tabella seguente mostra i valori di questi flag per ogni istanza VM che esegue uno dei servizi gRPC, il numero di istanze in un gruppo di istanze e i servizi di backend a cui appartengono questi gruppi di istanze.

Nota: per brevità, il prefisso e il suffisso comuni nei nomi dei servizi di backend e dei gruppi di istanze non vengono mostrati. Ad esempio, il servizio di backend grpcwallet-wallet-v1-service è mostrato come wallet-v1.

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, configurerai Cloud Service Mesh per instradare le richieste a questi servizi di backend da un client di test, in base alle regole di routing nella tabella seguente. Il client si connette al nome host virtuale di un servizio, come mostrato nella colonna Host.

Nota: la pseudo-intestazione :path HTTP/2 in una richiesta gRPC è nel formato /ServiceName/MethodName, dove ServiceName è il nome del servizio gRPC chiamato nella richiesta gRPC e MethodName è il metodo in quel servizio.

Host	Regole delle corrispondenze	Azione route
wallet.grpcwallet.io	Prefisso percorso: "/" Intestazione presente: "session_id"	Percorso per wallet-v1-affinity
	Prefisso percorso: "/" Intestazione: {"route": "timeout"}	Imposta timeout di 5 secondi e instrada a wallet-v2
	Prefisso percorso: "/" Intestazione: {"route": "fault"}	Non supera il 50% delle richieste e instrada le altre a wallet-v2
	Prefisso percorso: "/" Intestazione: {"membership": "premium"}	Instrada a wallet-v1 e riprova fino a 3 volte in caso di errore
	Percorso completo: /grpc.examples.wallet.Wallet/FetchBalance	Instrada a: wallet-v1: 70% wallet-v2: 30%
	Predefinito	Percorso per wallet-v1
stats.grpcwallet.io	Prefisso percorso: "/" Intestazione: {"membership": "premium"}	Percorso per stats-premium
	Predefinito	Percorso per stats
account.grpcwallet.io	Prefisso percorso: "/" Intestazione: {"route": "account-fault"}	Non supera il 30% delle richieste e instrada le altre a account
	Predefinito	account

In questo esempio viene utilizzata una suddivisione del traffico a 70/30 tra due servizi esistenti. Se suddividi il traffico in un nuovo servizio a cui la mappa URL non fa riferimento in precedenza, aggiungi innanzitutto il nuovo servizio a weightedBackendServices e assegnagli una ponderazione pari a 0. Quindi, aumenta gradualmente il peso assegnato al servizio.

Il client di test ha a disposizione le seguenti opzioni che consentono di generare richieste appropriate per dimostrare le funzionalità di gestione del traffico.

Opzione	Descrizione
--watch=true	Chiamare i metodi di streaming per il saldo/prezzo
--unary_watch=true	Richiamare ripetutamente metodi unari per bilanciare/prezzo dell'orologio
--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 questi comandi:

1. Aggiorna il programma binario gcloud per assicurarti di avere l'ultima versione:

   gcloud components update
   

2. Scarica il repository di esempi:

   sudo apt-get install git -y
   

3. 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 del router Cloud in ogni regione e le configurerai per Cloud NAT. Le VM create in questo esempio non hanno indirizzi IP esterni, ma devono avere accesso a internet. La configurazione del router Cloud con Cloud NAT fornisce l'accesso richiesto.

gcloud

1. Crea le istanze del router Cloud:

   gcloud compute routers create nat-router-us-central1 \
       --network=default \
       --region=us-central1
   

2. 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 alle richieste di controllo di integrità gRPC di raggiungere la tua rete. In seguito, il controllo di integrità gRPC viene associato ai servizi di backend, in modo da poter controllare l'integrità delle istanze di backend di questi servizi di backend.

gcloud

1. Crea il controllo di integrità:

   gcloud compute health-checks create grpc grpcwallet-health-check \
       --use-serving-port
   

2. 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 il deployment del servizio gRPC account 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 in base alle esigenze. 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. La porta denominata è la porta su cui il servizio gRPC rimane in ascolto delle richieste. In questo 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 un servizio di backend globale con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED e protocollo GRPC. Successivamente, associ 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 il servizio gRPC account. La porta nel flag --port-name è quella che hai creato in Configurare la porta denominata.

gcloud

1. 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
   

2. 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 restanti servizi di backend utilizzati nell'esempio di Wallet gRPC sono simili a quelli precedenti. I servizi rimanenti vengono creati 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 da utilizzare per dimostrare varie funzionalità di gestione del traffico. La mappa URL specifica i nomi host virtuali dei servizi in questo esempio e le regole di routing associate. Per ulteriori informazioni, consulta Mappe di regole di routing.

Nella mappa URL, hostRules specifica i nomi host virtuali dei servizi nell'esempio. Questi sono i nomi che un client utilizza nell'URI del canale per connettersi a un servizio specifico. Ad esempio, per inviare una richiesta al servizio account, un client utilizza xds:///account.grpcwallet.io nell'URI del canale. In hostRules, configura una voce hosts con il valore account.grpcwallet.io.

L'elemento pathMatcher associato a una voce hosts specifica il nome di un pathMatcher che contiene tutte le regole di routing per l'host virtuale. Una configurazione di pathMatcher è composta da regole di corrispondenza e regole di azione corrispondenti, 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 creata nel passaggio precedente. Il flag --validate-for-proxyless consente i controlli della configurazione in modo da non abilitare accidentalmente una funzionalità non compatibile con i deployment gRPC senza proxy.

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. Lo schema di bilanciamento del carico è impostato su INTERNAL_SELF_MANAGED per indicare che questa regola di forwarding è utilizzata da Cloud Service Mesh. Deve essere una regola di forwarding globale. L'indirizzo IP è impostato su 0.0.0.0 perché un client gRPC senza proxy risolve hostname:port nell'URI di destinazione inviando una richiesta LDS a Cloud Service Mesh anziché eseguire una ricerca DNS. Per ulteriori informazioni, consulta Schema di risoluzione dei nomi.

Se non è specificata una porta nell'URI di destinazione, il valore predefinito è 80. Ad esempio, un URI di destinazione xds:///foo.myservice:8080 corrisponde a una regola di forwarding 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 la pagina Cloud Service Mesh nella console Google Cloud. Verifica che i servizi di backend e i backend associati siano segnalati come integri. L'operazione potrebbe richiedere alcuni minuti.

Verifica la configurazione del routing

In questa sezione verificherai che la configurazione del routing funziona correttamente. Per testare la configurazione, puoi usare lo strumento grpcurl.

gcloud

1. Creare una VM client su cui eseguire i client per testare il servizio. Se vuoi, puoi includere il flag --network-interface=no-address.

   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')
   

2. Accedi alla VM tramite SSH ed esegui questi comandi per prepararla:

   export EXAMPLES_VERSION=v1.1.x
   sudo apt-get update
   sudo apt-get install git -y
   

3. 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 lo 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 questo scopo, è necessaria una configurazione di bootstrap.

Lo script di avvio nella sezione precedente imposta la variabile di ambiente GRPC_XDS_BOOTSTRAP e utilizza uno script di supporto per generare il file di bootstrap. I valori TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME e zona nel file di bootstrap generato vengono ottenuti dal server metadati che conosce questi dettagli sulle istanze VM di Compute Engine. Puoi fornire questi valori allo script helper manualmente utilizzando le opzioni -gcp-project-number e -vpc-network-name.

Verifica la configurazione utilizzando lo strumento grpcurl

Esegui i comandi seguenti nella shell SSH per verificare che wallet-service, stats-service e account-service siano 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

Vedrai 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 client

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 instradate ai servizi di backend in base alle regole di corrispondenza della mappa URL. Per ogni risposta, il comando stampa anche il nome host dell'istanza VM, per mostrare a quale istanza VM è stata instradata la richiesta.

Java

1. Per verificare il servizio con un client Java gRPC, esegui questo comando:

   sudo apt-get install -y openjdk-11-jdk-headless
   

2. 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
   

Go

1. 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
   

2. 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++

1. Per verificare il servizio con un client gRPC C++, esegui questo comando:

   sudo apt-get install -y build-essential
   

2. 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 opzioni avanzate di routing del traffico utilizzando le istruzioni riportate nelle sezioni seguenti.

Interruzione di circuito

L'interruzione di circuito consente di impostare soglie di errore per evitare che le richieste client sovraccarichino i servizi di backend. Una volta che il numero di richieste in sospeso ha raggiunto un limite che hai impostato, il client smette di inviare richieste aggiuntive, dando ai tuoi servizi di backend il tempo di recuperare.

L'interruzione di circuito previene gli errori a cascata restituendo un errore al client anziché sovraccaricare un servizio di backend. In questo modo, è possibile gestire una parte del traffico fornendo al contempo il tempo necessario per gestire la situazione di sovraccarico, ad esempio per 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 consente ai client di inviare una sola richiesta in attesa a stats-service alla volta. Poiché esiste un solo servizio wallet-v2, l'esecuzione di due operazioni simultanee del client di Wallet WatchBalance mostra errori nella seconda istanza.

Java

1. 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
   

2. L'output sarà 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}
   

3. Esegui il comando kill:

   kill %%
   

Go

1. 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
   

2. L'output sarà 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
   

3. Esegui il comando kill:

   kill %%
   

C++

1. 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
   

2. L'output sarà 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
   

3. Esegui il comando kill:

   kill %%
   

Fault injection

La Fault injection introduce errori durante la gestione delle richieste per simulare errori, tra cui alta latenza, sovraccarico dei servizi, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio ai guasti simulati.

Quando hai creato la mappa URL in precedenza, hai impostato il criterio di fault injection in modo che il 50% delle RPC inviate a wallet.grpcwallet.io con l'intestazione route=fault non vada a buon fine.

Per dimostrare la fault injection, utilizza il codice nei seguenti linguaggi.

Java

1. 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
   

2. L'output sarà 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}
   

Go

1. 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
   

2. L'output sarà 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++

1. 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
   

2. L'output sarà 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 dello stream

La durata massima dello stream consente di applicare un timeout massimo a tutte le RPC. In questo modo, i client che dimenticano di impostare una scadenza o che impostano una scadenza eccessiva di sprecare 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, interrompiamo prima 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 rimarrebbe bloccato per sempre, perché non esiste un servizio di backend in grado di gestirlo e l'applicazione non imposta una scadenza.

Java

1. 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. Il comando smette di rispondere. Premi ^C per interrompere il comando.

Go

1. Esegui questi comandi:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   

2. Il comando smette di rispondere. Premi ^C per interrompere il comando.

C++

1. 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. Il comando smette di rispondere. Premi ^C per interrompere il comando.

Tuttavia, il seguente comando che utilizza la route timeout ha esito negativo dopo 5 secondi a causa dell'impostazione maxStreamDuration.

Java

1. 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
   

2. L'output sarà 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}
   

Go

1. 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
   

2. L'output sarà simile al seguente:

   failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.
   

C++

1. 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
   

2. L'output sarà 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 consentendo alle applicazioni gRPC di ritentare le richieste in uscita in base a un criterio per i nuovi tentativi. In un criterio per i nuovi tentativi, puoi configurare le condizioni in base alle quali deve essere riprovata una richiesta non riuscita e il numero massimo di nuovi tentativi, ad esempio quando una richiesta ha esito negativo con un determinato codice di risposta.

Quando hai creato la mappa URL in precedenza, hai impostato un criterio di nuovo tentativo per le RPC al metodo FetchBalance con l'intestazione membership=premium. Questo criterio riprova per un massimo di 3 volte le RPC con esito negativo con il codice di stato unavailable. Puoi anche impostare un criterio di fault injection su account.grpcwallet.io con l'intestazione route=account-fault che non riesce per il 30% delle RPC dal servizio Wallet al servizio Account. Di conseguenza, il 30% delle RPC provenienti dal client di prova 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

Go

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 determinate caratteristiche (intestazioni HTTP) alla stessa istanza, utilizzando il criterio del "best effort" fintanto che l'istanza è integro e ha capacità sufficiente. Ciò è utile per i server di applicazioni stateful che traggono vantaggio da prestazioni ed efficienza migliorate quando le richieste di un determinato client vengono inviate alla stessa istanza anziché, ad esempio, la distribuzione round robin a istanze diverse.

Nota: un client gRPC che non supporta il criterio di bilanciamento del carico RING_HASH restituirà la configurazione negativa a Cloud Service Mesh quando una mappa URL fa riferimento a un servizio di backend con localityLbPolicy=RING_HASH. Ciò causa lo stato di errore temporaneo del canale client fino a quando la configurazione non viene corretta. Per maggiori dettagli, vedi Limitazione del servizio di backend.

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 seguente configurazione per modificare il valore localityLbPolicy in RING_HASH.

sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: "session_id"

gcloud

1. 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
   

2. 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}"
   

Nota: la propagazione dell'aggiornamento del servizio di backend ai client potrebbe richiedere diversi minuti.

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 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

Go

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à consente di identificare ed escludere temporaneamente gli host in stato non integro dal pool di bilanciamento del carico. Questi host non integri 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 percentuale è interessata da errori come errori gRPC, errori HTTP, timeout e altri problemi.

Quando configuri il rilevamento di outlier tramite Cloud Service Mesh, puoi ottimizzare il modo in cui gRPC valuta gli host e come gestisce i valori anomali. Ad esempio, puoi specificare criteri come i seguenti:

• Il numero di richieste che un host deve ricevere prima che gRPC lo analizzi per verificare il possibile stato outlier.

• La misura in cui un host può discostarsi dalla percentuale di successo media prima di essere considerato un outlier.

• La percentuale massima di host che possono essere espulsi in qualsiasi momento dal pool di bilanciamento del carico.

• Il periodo di tempo per cui un outlier viene escluso dal pool di bilanciamento del carico.

Per ulteriori informazioni sui parametri disponibili, consulta la documentazione di riferimento su REST Resource: backendServices. Tuttavia, esistono alcune limitazioni per gRPC, come descritto nella sezione seguente.

Limitazioni

I seguenti campi non sono supportati per i client gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Configura il rilevamento outlier

La seguente procedura mostra come configurare il rilevamento di outlier per un servizio che utilizza un gruppo di istanze come backend. Questa procedura stabilisce la seguente configurazione:

• L'analisi del rilevamento di outlier viene eseguita ogni secondo. Puoi configurare questo comportamento utilizzando il campo interval.
• I valori anomali vengono esclusi dal pool di bilanciamento del carico per incrementi di 30 secondi, come segue:
  • Se un host non è mai stato escluso in precedenza, viene espulso per soli 30 secondi.
  • Se un host è stato escluso in precedenza, il tempo aumenta di 30 secondi per ogni espulsione precedente. Ad esempio, quando un host viene escluso per la terza volta, viene espulso per 90 secondi. Puoi configurare questo comportamento utilizzando il campo baseEjectionTime.
• Un host è considerato non integro se la sua percentuale di successo è una deviazione standard sotto la media durante l'intervallo di tempo selezionato (in questo caso, 1 secondo). Puoi configurare la deviazione standard massima utilizzando il campo successRateStdevFactor.

Per configurare il rilevamento di outlier in questo modo, segui i passaggi riportati di seguito.

gcloud

1. Esporta il file di configurazione del servizio di backend grpcwallet-wallet-v2-service utilizzando il comando gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
    --destination=bs_config.yaml \
    --global
   

2. Nel file bs_config.yaml, aggiorna la configurazione grpcwallet-wallet-v2-service in modo da includere i campi di rilevamento outlier:

   outlierDetection:
    interval:
      seconds: 1
      nanos: 0
    baseEjectionTime:
      seconds: 30
      nanos: 0
    successRateStdevFactor: 1000
   

3. Importa il file aggiornato utilizzando il comando gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service \
    --source=bs_config.yaml \
    --global

Nota: l'esempio relativo a Wallet non è progettato per includere host che non funzionano correttamente. Per questo motivo, gli host grpcwallet-wallet-v2-service in genere non vengono rimossi, anche se configuri correttamente il rilevamento di outlier.

Bilanciamento del carico per le località

Per utilizzare nel modo più efficiente le tue risorse, configura il bilanciamento del carico per le località. Questa funzionalità ti aiuta a risparmiare risorse distribuendo in modo uniforme le richieste client tra i backend.

Quando configuri il bilanciamento del carico per le località, puoi utilizzare le opzioni descritte nella tabella seguente. Tutte le opzioni richiedono di configurare la risorsa 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 successive, in un mesh che include solo client gRPC	localityLbPolicies
Definire un elenco dei criteri preferiti	Client Java che utilizzano gRPC versione 1.47 o successive, in un mesh che include solo client gRPC	localityLbPolicies

Puoi utilizzare qualsiasi combinazione delle opzioni precedenti. Tuttavia, se configuri sia localityLbPolicy sia localityLbPolicies, gRPC tenta prima di utilizzare la configurazione localityLbPolicies.

Se non configuri il bilanciamento del carico per le località, Cloud Service Mesh utilizza il criterio ROUND_ROBIN.

Per informazioni su ROUND_ROBIN e su altri criteri integrati, consulta la descrizione di localityLbPolicy nella pagina backendServices.

Utilizzare un criterio integrato

Se vuoi che tutti i tuoi client utilizzino un unico criterio integrato, puoi selezionarlo 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 client possono utilizzare lo stesso criterio, consulta Definire un elenco dei criteri preferiti.

gcloud

1. Esporta il file di configurazione del servizio di backend grpcwallet-wallet-v2-service utilizzando il comando gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
   --destination=bs_config.yaml \
   --global
   

2. Aggiorna il file bs_config.yaml esportato in modo da includere le seguenti righe:

   localityLbPolicy:
    -- policy
       name: RING_HASH
   

3. Importa il file aggiornato utilizzando il comando gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

Utilizza una norma personalizzata

Se opportuno, puoi utilizzare un criterio di bilanciamento del carico personalizzato che hai creato e di cui hai eseguito il deployment con gRPC. Questa funzionalità è disponibile per i client Java che utilizzano gRPC versione 1.47 o successive. Utilizzalo solo in un mesh che include tutti i client gRPC.

Quando crei un criterio personalizzato, potrebbe essere utile la seguente documentazione:

• Per rendere il tuo criterio personalizzato più sofisticato, puoi utilizzare le API Open Request Cost Aggregation (ORCA). Queste API consentono di acquisire metriche sul costo delle query e sull'utilizzo del server. Per utilizzare queste API è necessario gRPC 1.48.1 o versioni successive. Per maggiori informazioni, consulta Esempio di gRPC ORCA.

• Per informazioni su come le configurazioni di bilanciamento del carico personalizzate vengono inviate a gRPC tramite xDS, consulta Configurazione del bilanciatore del carico personalizzato gRPC xDS.

Per configurare Cloud Service Mesh per l'utilizzo del tuo criterio personalizzato, identifica il criterio utilizzando il campo localityLbPolicies.

I passaggi seguenti illustrano questa procedura. In questa procedura, aggiornerai la configurazione del servizio di backend grpcwallet-wallet-v2-service in modo che i client che vi si connettono utilizzino un criterio personalizzato denominato example.ExampleLoadBalancer.

Attenzione: questa funzionalità è destinata all'utilizzo in un mesh di servizi che include solo client gRPC. I proxy Envoy non possono utilizzare servizi di backend con questa configurazione.

gcloud

1. Esporta il file di configurazione del servizio di backend grpcwallet-wallet-v2-service utilizzando il comando gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
   --destination=bs_config.yaml \
   --global
   

2. Aggiorna il file bs_config.yaml esportato in modo che faccia riferimento al criterio example.ExampleLoadBalancer. Includi le seguenti righe:

   localityLbPolicies:
     - customPolicy:
         name: example.ExampleLoadBalancer
         data: '{ "message": "Hello load-balancing world!" }'
   

3. Importa il file aggiornato utilizzando il comando gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

4. (Facoltativo) Testa la configurazione del 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, visualizzerai il messaggio che hai incluso nella configurazione ("Hello Load-balancing world!").

Definisci un elenco di criteri preferiti

Se hai più client che non tutti supportano un unico criterio di bilanciamento del carico, crea un elenco di criteri utilizzabili dai tuoi client. Con questa opzione, se il primo criterio preferito non può essere utilizzato da un determinato client, gRPC torna al criterio successivo nell'elenco.

Quando crei un elenco di criteri preferiti, le opzioni valide includono i criteri personalizzati, ROUND_ROBIN e, per i client Java, LEAST_REQUEST. Puoi Elencare fino a 10 criteri.

Questa funzionalità è disponibile solo per i client Java che utilizzano gRPC versione 1.47 o successive. Utilizzalo solo in un mesh che include tutti i client gRPC.

Attenzione: questa funzionalità è destinata all'utilizzo in un mesh di servizi che include solo client gRPC. I proxy Envoy non possono utilizzare servizi di backend con questa configurazione.

gcloud

1. Esporta il file di configurazione del servizio di backend grpcwallet-wallet-v2-service utilizzando il comando gcloud compute backend-services export:

gcloud compute backend-services export grpcwallet-wallet-v2-service \
  --destination=bs_config.yaml \
  --global

1. Aggiorna il file bs_config.yaml esportato in modo da includere il campo localityLbPolicies. Compilalo con voci che rappresentano i seguenti criteri:

   • Una norma personalizzata non valida (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
   

2. Importa il file aggiornato utilizzando il comando gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

3. (Facoltativo) Testa la configurazione del 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
   

   In risposta, gRPC tenta e non riesce a trovare example.InvalidLoadBalancer. Dopodiché, riprende a utilizzare example.ExampleLoadBalancer e viene visualizzato il messaggio che hai incluso nella configurazione ("Hello Load-balancing world!"). Il logging gRPC sul client include un messaggio che indica che example.InvalidLoadBalancer non è stato trovato.

Esegui la pulizia delle risorse

Per eseguire la pulizia delle risorse, esegui questo comando dal tuo 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 deployment è su GKE, configura la sicurezza del servizio e utilizza un criterio di autorizzazione per bloccare il traffico tra i servizi. Per istruzioni complete, consulta Sicurezza del servizio Traffic Director 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 di deployment che utilizzano gRPC senza proxy.