Configurar la gestión avanzada del tráfico con servicios de gRPC sin proxy

Nota: Esta guía solo admite Cloud Service Mesh con APIs de Google Cloud y no admite APIs de Istio. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Esta configuración es compatible con los clientes de la versión preliminar, pero no la recomendamos para los nuevos usuarios de Cloud Service Mesh. Para obtener más información, consulta la información general sobre el enrutamiento de servicios de Cloud Service Mesh.

En este documento se proporcionan instrucciones para configurar Cloud Service Mesh con las siguientes funciones de gestión del tráfico:

• Coincidencia de ruta
• División del tráfico
• Interrupción de circuitos
• Inyección de fallos
• Duración máxima de la transmisión
• Reintentar
• Afinidad de sesión
• Detección de valores atípicos
• Balanceo de carga según la localidad

Aunque este documento se centra en la configuración de la gestión avanzada del tráfico con gRPC sin proxy en Compute Engine, también se admite la gestión avanzada del tráfico cuando se usa gRPC sin proxy en Google Kubernetes Engine (GKE).

Antes de empezar

Antes de configurar la gestión avanzada del tráfico, consulta los requisitos en Prepararse para configurar Cloud Service Mesh con servicios de gRPC sin proxy. No puedes configurar la gestión avanzada del tráfico a menos que se cumplan todos los requisitos.

Para obtener información conceptual sobre estas funciones, consulta Gestión avanzada del tráfico.

Acerca del ejemplo de gRPC Wallet

Para ilustrar estas funciones, implementa un ejemplo de Wallet de gRPC. En este ejemplo, hay tres servicios gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats y grpc.examples.wallet.account.Account, que se implementan como tres aplicaciones independientes.

Como se muestra en el siguiente diagrama, creas un cliente gRPC que llama al servicio Wallet para obtener el saldo de una cuenta y llama al servicio Stats para obtener el precio de una moneda. El servicio Wallet llama a los servicios Stats y Account para calcular el saldo. El servicio Stats también llama al servicio Account para obtener información del usuario.

Ejemplo de configuración de enrutamiento de tráfico de gRPC Wallet (haz clic en la imagen para ampliarla)

En el ejemplo, se implementan dos versiones de Wallet y Stats para ilustrar el enrutamiento de solicitudes en función de las reglas que configure. Para simular la compilación y la implementación de diferentes versiones de un servicio, se usan marcas de servidor para cambiar el comportamiento de los archivos binarios que se compilan solo una vez.

• La marca --port especifica el puerto en el que escucha el servicio de una instancia de VM.
• La marca --hostname_suffix especifica un valor que se añade al nombre de host de la instancia de VM que responde a una solicitud. El valor resultante se añade como metadatos hostname en la respuesta. De esta forma, puedes identificar qué instancia de un grupo de instancias ha respondido a la solicitud del cliente.
• La marca --premium_only con el valor true especifica que el servicio es una versión premium del servicio stats.
• La marca --v1_behavior con el valor true especifica que el archivo binario de la cartera se comporta como una versión 1.

En la siguiente tabla se muestran los valores de estas marcas para cada instancia de VM que ejecuta uno de los servicios gRPC, el número de instancias de un grupo de instancias y los servicios de backend a los que pertenecen estos grupos de instancias.

Nota: Para abreviar, no se muestran el prefijo y el sufijo comunes en los nombres de los servicios backend y los grupos de instancias. Por ejemplo, el servicio de backend grpcwallet-wallet-v1-service se muestra como wallet-v1.

Servicio de backend	Grupo de instancias	Instancias	Marcas de servidor
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"

Una vez que hayas desplegado estos servicios, configura Cloud Service Mesh para enrutar las solicitudes a estos servicios backend desde un cliente de prueba, según las reglas de enrutamiento de la siguiente tabla. El cliente se conecta al nombre de host virtual de un servicio, como se muestra en la columna Host.

Nota: El pseudoencabezado :path de HTTP/2 en una solicitud gRPC tiene el formato /ServiceName/MethodName, donde ServiceName es el nombre del servicio gRPC al que se llama en la solicitud gRPC y MethodName es el método de ese servicio.

Host	Reglas de coincidencia	Acción de ruta
wallet.grpcwallet.io	Prefijo de ruta: "/" Encabezado presente: "session_id"	Ruta para llegar a wallet-v1-affinity
	Prefijo de ruta: "/" Encabezado: {"route": "timeout"}	Establece un tiempo de espera de 5 segundos y ruta a wallet-v2
	Prefijo de ruta: "/" Encabezado: {"route": "fault"}	Falla el 50% de las solicitudes y ruta el resto a wallet-v2
	Prefijo de ruta: "/" Encabezado: {"membership": "premium"}	Dirigir a wallet-v1 y reintentar hasta 3 veces si falla
	Ruta completa: /grpc.examples.wallet.Wallet/FetchBalance	Ruta a: wallet-v1: 70% wallet-v2: 30%
	Predeterminado	Ruta para llegar a wallet-v1
stats.grpcwallet.io	Prefijo de ruta: "/" Encabezado: {"membership": "premium"}	Ruta para llegar a stats-premium
	Predeterminado	Ruta para llegar a stats
account.grpcwallet.io	Prefijo de ruta: "/" Encabezado: {"route": "account-fault"}	Falla el 30% de las solicitudes y dirige el resto a account
	Predeterminado	account

En este ejemplo, se usa una división del tráfico del 70/30 entre dos servicios. Si vas a dividir el tráfico a un nuevo servicio al que no se ha hecho referencia en el mapa de URLs anteriormente, primero añade el nuevo servicio a weightedBackendServices y dale un peso de 0. Después, aumenta gradualmente el peso asignado a ese servicio.

El cliente de prueba tiene las siguientes opciones que te permiten generar solicitudes adecuadas para demostrar las funciones de gestión del tráfico.

Opción	Descripción
--watch=true	Métodos de streaming de llamadas para ver el saldo o el precio
--unary_watch=true	Llamar a métodos unarios repetidamente para monitorizar el saldo o el precio
--user=Alice	Inyectar encabezado {"membership": "premium"}
--user=Bob	Inyectar encabezado {"membership": "normal"}
--route=value	Inyectar encabezado {"route": "value"}
--affinity=true	Inyectar encabezado {"session_id": "value"}

Preparar el entorno local

Para configurar el entorno local de estos ejemplos, ejecuta los siguientes comandos:

1. Actualiza el archivo binario gcloud para asegurarte de que tienes la versión más reciente:

   gcloud components update
   

2. Descarga el repositorio de ejemplos:

   sudo apt-get install git -y
   

3. Clona el repositorio correcto para el ejemplo:

   export EXAMPLES_VERSION=v1.1.x
   git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
     https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
   

Crear y configurar instancias de Cloud Router

En esta sección, creará instancias de Cloud Router en cada región y las configurará para Cloud NAT. Las VMs creadas en este ejemplo no tienen direcciones IP externas, pero necesitan tener acceso a Internet. Configurar Cloud Router con Cloud NAT proporciona el acceso necesario.

gcloud

1. Crea las instancias de Cloud Router:

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

2. Configura los routers para 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
   

Crear la comprobación del estado de gRPC y la regla de cortafuegos

En esta sección, creará una comprobación del estado de gRPC y una regla de cortafuegos para permitir que las solicitudes de comprobación del estado de gRPC lleguen a su red. Más adelante, la comprobación de estado de gRPC se asocia a los servicios de backend para que pueda comprobar el estado de las instancias de backend de esos servicios.

gcloud

1. Crea la comprobación del estado:

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

2. Crea la regla de cortafuegos para la comprobación del estado:

   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 la plantilla de instancia

En esta sección, crearás una plantilla de instancia para desplegar el servicio account gRPC que se expone en el puerto 50053.

gcloud

• Crea la plantilla de instancia:

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

Crear el grupo de instancias gestionado

Los grupos de instancias gestionados (MIGs) usan el autoescalado para crear nuevas instancias de VM según sea necesario. En esta sección, crearás un MIG usando la plantilla de instancia que creaste en la sección anterior.

gcloud

• Crea el grupo de instancias:

  gcloud compute instance-groups managed create grpcwallet-account-mig-us-central1 \
     --zone=us-central1-a \
     --size=2 \
     --template=grpcwallet-account-template
  

Configurar el puerto con nombre

En esta sección, configurarás el puerto con nombre del servicio gRPC. El puerto con nombre es el puerto en el que el servicio gRPC escucha las solicitudes. En este ejemplo, el puerto con nombre es el puerto 50053.

gcloud

• Crea el puerto con nombre:

  gcloud compute instance-groups set-named-ports grpcwallet-account-mig-us-central1 \
     --named-ports=grpcwallet-account-port:50053 \
     --zone=us-central1-a
  

Crea el servicio de backend

En esta sección, crearás un servicio de backend global con un esquema de balanceo de carga INTERNAL_SELF_MANAGED y un protocolo GRPC. A continuación, asocia la comprobación del estado y el grupo de instancias al servicio de backend. En este ejemplo, usarás el MIG que has creado en Crear el grupo de instancias gestionado. Este MIG ejecuta el servicio gRPC account. El puerto de la marca --port-name es el puerto con nombre que has creado en Configurar el puerto con nombre.

gcloud

1. Crea el servicio de backend y, a continuación, asocia la comprobación del estado al nuevo servicio de 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. Añade el grupo de instancias gestionado como backend:

   gcloud compute backend-services add-backend grpcwallet-account-service \
       --instance-group=grpcwallet-account-mig-us-central1 \
       --instance-group-zone=us-central1-a \
       --global
   

Los pasos para crear los servicios de backend restantes que se usan en el ejemplo de cartera de gRPC son similares a los anteriores. Para crear los servicios restantes, ejecuta un script de shell. La secuencia de comandos implementa los siguientes servicios de backend:

• stats
• stats-premium
• wallet-v1
• wallet-v1-affinity
• wallet-v2

Ejecuta la secuencia de comandos shell que crea los servicios de backend adicionales:

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

Crear las reglas de enrutamiento

En esta sección, creará un mapa de URLs que se usará para mostrar varias funciones de gestión del tráfico. El mapa de URLs especifica los nombres de host virtuales de los servicios de este ejemplo y las reglas de enrutamiento asociadas. Para obtener más información, consulta Mapas de reglas de enrutamiento.

En el mapa de URLs, las hostRules especifican los nombres de host virtuales de los servicios del ejemplo. Estos son los nombres que usa un cliente en el URI del canal para conectarse a un servicio específico. Por ejemplo, para enviar una solicitud al servicio account, un cliente usa xds:///account.grpcwallet.io en el URI del canal. En hostRules, configure una entrada hosts con el valor account.grpcwallet.io.

El pathMatcher asociado a una entrada hosts especifica el nombre de un pathMatcher que contiene todas las reglas de enrutamiento de ese host virtual. Una configuración de pathMatcher consta de reglas de coincidencia y reglas de acción correspondientes, tal como se describe en Acerca del ejemplo de gRPC Wallet.

gcloud

Crea la asignación de URLs:

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

Crear el proxy de destino y la regla de reenvío

En esta sección, crearás el proxy gRPC de destino y una regla de reenvío.

El proxy gRPC de destino hace referencia al mapa de URLs que ha creado en el paso anterior. La marca --validate-for-proxyless habilita las comprobaciones de configuración para que no habilites por error una función que no sea compatible con las implementaciones de gRPC sin proxy.

gcloud

• Crea el proxy gRPC de destino:

  gcloud compute target-grpc-proxies create grpcwallet-proxy \
     --url-map=grpcwallet-url-map \
     --validate-for-proxyless
  

La regla de reenvío hace referencia al proxy gRPC de destino que has creado. El esquema de balanceo de carga se define como INTERNAL_SELF_MANAGED para indicar que Cloud Service Mesh usa esta regla de reenvío. Debe ser una regla de reenvío global. La dirección IP se ha definido como 0.0.0.0 porque un cliente gRPC sin proxy resuelve hostname:port en el URI de destino enviando una solicitud LDS a Cloud Service Mesh en lugar de hacer una búsqueda de DNS. Para obtener más información, consulta el artículo Esquema de resolución de nombres.

Si no se especifica ningún puerto en el URI de destino, el valor predeterminado es 80. Por ejemplo, un URI de destino xds:///foo.myservice:8080 coincide con una regla de reenvío que se ha configurado con el puerto 8080. En este ejemplo, la regla de reenvío se ha configurado con el puerto 80.

gcloud

• Crea la regla de reenvío:

  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
  

Verificar la configuración

Cuando se complete el proceso de configuración, comprueba que los servicios backend que has configurado estén disponibles en la página Cloud Service Mesh de la consola Google Cloud . Confirma que los servicios de backend y los backends asociados se indican como correctos. Este proceso puede tardar varios minutos.

Verificar la configuración de enrutamiento

En esta sección, comprobarás que la configuración de enrutamiento funciona correctamente. Utiliza la herramienta grpcurl para probar la configuración.

gcloud

1. Crea una VM cliente en la que ejecutes los clientes para probar el servicio. También puedes incluir la marca --network-interface=no-address de forma opcional.

   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.16.0.tar.gz | tar -xz
   ./td-grpc-bootstrap-0.16.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')
   

2. Accede a la VM mediante SSH y ejecuta los siguientes comandos para prepararla:

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

3. Ejecuta estos comandos:

   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
   

Para acceder a los servicios sin un proxy sidecar, el cliente de gRPC debe usar el esquema de resolución de nombres xds. Este esquema indica a la biblioteca gRPC utilizada en el cliente que use un servidor xDS para resolver el nombre de host. Para ello, se necesita una configuración de arranque.

La secuencia de comandos de inicio de la sección anterior define la variable de entorno GRPC_XDS_BOOTSTRAP y usa una secuencia de comandos auxiliar para generar el archivo de arranque. Los valores de TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME y la zona del archivo de arranque generado se obtienen del servidor de metadatos, que conoce estos detalles sobre tus instancias de VM de Compute Engine. Puedes proporcionar estos valores a la secuencia de comandos auxiliar manualmente mediante las opciones -gcp-project-number y -vpc-network-name.

Nota: De acuerdo con la política, recomendamos a los usuarios que comprueben si hay actualizaciones del generador de bootstrap de gRPC de TD cada año.

Verificar la configuración con la herramienta grpcurl

Ejecuta los siguientes comandos en el shell SSH para verificar que wallet-service, stats-service y account-service se están ejecutando:

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

Verás los siguientes resultados:

grpc.examples.wallet.account.Account
grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection

{
  "name": "Alice",
  "membership": "PREMIUM"
}

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Verificar con clientes de grpc-wallet

Sigue las instrucciones específicas de cada idioma para verificar la configuración. Los comandos envían varias llamadas a procedimientos remotos, algunas con metadatos adicionales, para mostrar que las solicitudes se enrutan a los servicios de backend en función de las reglas coincidentes del mapa de URLs. El comando también imprime el nombre de host de la instancia de VM en cada respuesta para mostrar a qué instancia de VM se ha dirigido la solicitud.

Java

1. Para verificar el servicio con un cliente Java de gRPC, ejecuta lo siguiente:

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

2. Ejecuta estos comandos:

   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. Para verificar el servicio con un cliente gRPC Go, instala Go o sigue las instrucciones oficiales:

   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. Ejecuta estos comandos:

   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. Para verificar el servicio con un cliente gRPC C++, ejecuta lo siguiente:

   sudo apt-get install -y build-essential
   

2. Ejecuta estos comandos:

   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
   

Configurar opciones más avanzadas

Puedes configurar opciones avanzadas adicionales de enrutamiento del tráfico siguiendo las instrucciones de las secciones siguientes.

Interrupción de circuitos

La interrupción de circuitos te permite definir umbrales de errores para evitar que las solicitudes de los clientes sobrecarguen tus servicios backend. Cuando el número de solicitudes pendientes alcanza el límite que has definido, el cliente deja de enviar solicitudes adicionales, lo que da tiempo a tus servicios backend para recuperarse.

El interruptor evita que se produzcan fallos en cascada devolviendo un error al cliente en lugar de sobrecargar un servicio de backend. De esta forma, se puede atender parte del tráfico mientras se gestiona la situación de sobrecarga, por ejemplo, gestionando un pico de tráfico aumentando la capacidad mediante el escalado automático.

Cuando crees el servicio de backend para stats-service, la secuencia de comandos create_service.sh incluirá las siguientes líneas en su configuración:

circuitBreakers:
  maxRequests: 1

Este ajuste limita los clientes a una solicitud pendiente a la vez a la stats-service. Como solo hay un servicio de wallet-v2, si se ejecutan dos operaciones simultáneas del cliente de cartera WatchBalance, se producirán errores en la segunda instancia.

Java

1. Ejecuta estos comandos:

   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. La salida tiene este aspecto:

   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. Ejecuta el comando kill:

   kill %%
   

Go

1. Ejecuta estos comandos:

   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. La salida tiene este aspecto:

   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. Ejecuta el comando kill:

   kill %%
   

C++

1. Ejecuta estos comandos:

   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. La salida tiene este aspecto:

   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. Ejecuta el comando kill:

   kill %%
   

Inyección de fallos

La inyección de errores introduce errores al atender solicitudes para simular fallos, como alta latencia, sobrecarga del servicio, fallos del servicio y partición de la red. Esta función es útil para probar la resiliencia de un servicio ante fallos simulados.

Cuando creaste el mapa de URLs anteriormente, definiste la política de inyección de errores para que fallara el 50% de las llamadas a procedimiento remoto enviadas a wallet.grpcwallet.io con el encabezado route=fault.

Para demostrar la inyección de errores, usa el código en los siguientes lenguajes.

Java

1. Ejecuta estos comandos:

   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. La salida tiene este aspecto:

   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. Ejecuta estos comandos:

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

2. La salida tiene este aspecto:

    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. Ejecuta estos comandos:

   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. La salida tiene este aspecto:

   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
   

Duración máxima de la transmisión

La duración máxima de la transmisión permite aplicar un tiempo de espera máximo a todas las llamadas a procedimientos remotos. De esta forma, se evita que los clientes que olvidan definir un plazo o que definen un plazo excesivo desperdicien recursos del servidor.

Cuando creaste el mapa de URLs anteriormente, definiste una duración máxima de la emisión de 5 segundos para las llamadas a procedimiento remoto enviadas a wallet.grpcwallet.io con el encabezado route=timeout.

Para mostrar los tiempos de espera, primero detenemos el servicio wallet-v2.

gcloud

gcloud compute instance-groups managed resize \
    --size=0 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

El siguiente comando se quedaría bloqueado para siempre, ya que no hay ningún servicio backend que lo gestione y la aplicación no establece ningún plazo.

Java

1. Ejecuta estos comandos:

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. El comando deja de responder. Pulsa ^C para interrumpir el comando.

Go

1. Ejecuta estos comandos:

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

2. El comando deja de responder. Pulsa ^C para interrumpir el comando.

C++

1. Ejecuta estos comandos:

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. El comando deja de responder. Pulsa ^C para interrumpir el comando.

Sin embargo, el siguiente comando que usa la ruta timeout falla después de 5 segundos debido al ajuste maxStreamDuration.

Java

1. Ejecuta el siguiente 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. La salida tiene este aspecto:

   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. Ejecuta el siguiente comando:

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

2. La salida tiene este aspecto:

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

C++

1. Ejecuta el siguiente 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. La salida tiene este aspecto:

   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
   

Reinicia el servicio wallet-v2.

gcloud

gcloud compute instance-groups managed resize \
    --size=1 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

Reintentar

Los reintentos te ayudan a mejorar la disponibilidad del servicio, ya que permiten que tus aplicaciones gRPC reintenten las solicitudes salientes según una política de reintentos. En una política de reintentos, puedes configurar las condiciones en las que se debe reintentar una solicitud fallida y el número máximo de intentos. Por ejemplo, cuando una solicitud falla con un código de respuesta concreto.

Cuando creaste el mapa de URLs, definiste una política de reintentos para las llamadas a procedimientos remotos (RPCs) en el método FetchBalance con el encabezado membership=premium. Esta política vuelve a intentar las llamadas RPC que fallan con el código de estado unavailable hasta un máximo de 3 veces. También puedes definir una política de inyección de errores para las llamadas RPC a account.grpcwallet.io con el encabezado route=account-fault, que provoca un error en el 30% de las llamadas RPC del servicio Wallet al servicio Account. Como resultado, el 30% de las llamadas a procedimiento remoto del cliente de prueba con la cabecera membership=normal fallan, mientras que la tasa de errores de las llamadas a procedimiento remoto con la cabecera membership=premium es inferior al 1%.

Para mostrar cómo se reintenta, usa el código en los siguientes lenguajes.

Java

Ejecuta estos comandos:

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

Ejecuta estos comandos:

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

Ejecuta estos comandos:

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

Afinidad de sesión

La afinidad de sesión intenta enviar solicitudes con características concretas (encabezados HTTP) a la misma instancia mientras la instancia esté en buen estado y tenga capacidad. Esto resulta útil para los servidores de aplicaciones con estado, que se benefician de un mejor rendimiento y eficiencia cuando las solicitudes de un cliente concreto se envían a la misma instancia en lugar de, por ejemplo, distribuirse de forma rotatoria a diferentes instancias.

Nota: Un cliente de gRPC que no admita la política de balanceo de carga RING_HASH enviará una confirmación negativa de la configuración de Cloud Service Mesh cuando un mapa de URLs haga referencia a un servicio de backend con localityLbPolicy=RING_HASH. Esto hará que el canal del cliente pase a un estado de error transitorio hasta que se corrija la configuración. Para obtener más información, consulte Limitación del servicio backend.

Cuando creaste el servicio de backend grpcwallet-wallet-v1-affinity-service, en la secuencia de comandos create_service.sh, el localityLbPolicy se definió como ROUND_ROBIN. En este ejemplo, aplicarás la siguiente configuración para cambiar localityLbPolicy a RING_HASH.

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

gcloud

1. Guarda la configuración del servicio de backend grpcwallet-wallet-v1-affinity-service:

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

2. Actualiza el servicio 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 actualización del servicio backend puede tardar varios minutos en propagarse a los clientes.

Para demostrar la afinidad de sesión, usa el código en los siguientes idiomas. Con la marca --affinity=true, el cliente inserta un encabezado session-id con un valor único para cada usuario. Se usa un hash de este valor para enviar la solicitud a una instancia concreta del grupo de instancias del servicio de backend grpcwallet-wallet-v1-affinity-service.

Java

Ejecuta estos comandos:

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

Ejecuta estos comandos:

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

Ejecuta estos comandos:

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

Restaura la configuración del servicio de backend grpcwallet-wallet-v1-affinity-service.

gcloud

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

Detección de valores atípicos

Para mejorar la disponibilidad del servicio, configura la detección de valores atípicos. Esta función te permite identificar y expulsar temporalmente los hosts que no están en buen estado del grupo de balanceo de carga. Estos hosts no saludables se denominan valores atípicos.

gRPC evalúa los hosts en función de la tasa de éxito, es decir, la frecuencia con la que un host gestiona las solicitudes correctamente. La tasa se ve afectada por fallos como errores de gRPC, errores de HTTP, tiempos de espera y otros problemas.

Cuando configuras la detección de valores atípicos a través de Cloud Service Mesh, puedes ajustar cómo evalúa gRPC los hosts y cómo gestiona los valores atípicos. Por ejemplo, puedes especificar criterios como los siguientes:

• Número de solicitudes que debe recibir un host antes de que gRPC las analice para determinar si se trata de valores atípicos.

• El grado en que un host puede desviarse de la tasa de éxito media antes de que se considere un valor atípico.

• Porcentaje máximo de hosts que se pueden expulsar en un momento dado del grupo de balanceo de carga.

• El tiempo durante el que se excluye un valor atípico del grupo de balanceo de carga.

Para obtener más información sobre los parámetros disponibles, consulta la referencia de REST Resource: backendServices. Sin embargo, gRPC tiene algunas limitaciones, tal como se describe en la sección siguiente.

Limitaciones

Los siguientes campos no se admiten en los clientes de gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Configurar la detección de valores atípicos

En el siguiente procedimiento se muestra cómo configurar la detección de valores atípicos en un servicio que usa un grupo de instancias como backend. Este procedimiento establece la siguiente configuración:

• El análisis de detección de valores atípicos se ejecuta cada segundo. Para configurar este comportamiento, usa el campo interval.
• Los valores atípicos se expulsan del grupo de balanceo de carga en incrementos de 30 segundos, de la siguiente manera:
  • Si un host no se ha expulsado nunca, solo se expulsará durante 30 segundos.
  • Si un anfitrión ya ha sido expulsado, el tiempo aumenta en 30 segundos por cada expulsión anterior. Por ejemplo, si se expulsa a un host por tercera vez, se le expulsará durante 90 segundos. Para configurar este comportamiento, usa el campo baseEjectionTime.
• Un host se considera no apto si su tasa de éxito es una desviación estándar inferior a la media durante el intervalo de tiempo seleccionado (en este caso, 1 segundo). Para configurar la desviación estándar máxima, usa el campo successRateStdevFactor.

Para configurar la detección de anomalías de esta forma, sigue estos pasos.

gcloud

1. Exporta el archivo de configuración del servicio de backend grpcwallet-wallet-v2-service con el comando gcloud compute backend-services export:

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

2. En el archivo bs_config.yaml, actualiza la grpcwallet-wallet-v2-service configuración para incluir los campos de detección de valores atípicos:

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

3. Importa el archivo actualizado con el comando gcloud compute backend-services import:

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

Nota: El ejemplo de Wallet no se ha diseñado para incluir hosts no saludables. Por este motivo, grpcwallet-wallet-v2-service los hosts no se suelen eliminar,grpcwallet-wallet-v2-serviceaunque configures correctamente la detección de valores atípicos.

Balanceo de carga según la localidad

Para aprovechar al máximo tus recursos, configura el balanceo de carga por localidad. Esta función te ayuda a ahorrar recursos distribuyendo de forma uniforme las solicitudes de los clientes entre tus back-ends.

Cuando configuras el balanceo de carga de localidad, puedes usar las opciones que se describen en la siguiente tabla. Todas las opciones requieren que configure el recurso backendServices.

Opción	Disponible para	Campo de configuración pertinente
Usar una política integrada	Todos los clientes de gRPC	localityLbPolicy
Usar una política personalizada	Clientes Java que usan gRPC 1.47 o una versión posterior en una malla que solo incluye clientes gRPC	localityLbPolicies
Definir una lista de políticas preferidas	Clientes Java que usan gRPC 1.47 o una versión posterior en una malla que solo incluye clientes gRPC	localityLbPolicies

Puedes usar cualquier combinación de las opciones anteriores. Sin embargo, si configuras tanto localityLbPolicy como localityLbPolicies, gRPC intentará usar primero tu configuración de localityLbPolicies.

Si no configuras el balanceo de carga según la ubicación, Cloud Service Mesh usará la política ROUND_ROBIN.

Para obtener información sobre ROUND_ROBIN y otras políticas integradas, consulta la descripción de localityLbPolicy en la página backendServices.

Usar una política integrada

Si quieres que todos tus clientes usen una sola política integrada, puedes seleccionarla configurando el campo localityLbPolicy.

Cuando configures este campo, podrás elegir entre las siguientes políticas:

• LEAST_REQUEST (solo clientes de Java)
• RING_HASH
• ROUND_ROBIN

Si no todos tus clientes pueden usar la misma política, consulta Definir una lista de políticas preferidas.

gcloud

1. Exporta el archivo de configuración del servicio de backend grpcwallet-wallet-v2-service con el comando gcloud compute backend-services export:

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

2. Actualiza el archivo bs_config.yaml exportado para que incluya las siguientes líneas:

   localityLbPolicy:
    -- policy
       name: RING_HASH
   

3. Importa el archivo actualizado con el comando gcloud compute backend-services import:

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

Usar una política personalizada

Si es necesario, puedes usar una política de balanceo de carga personalizada que hayas creado e implementado con gRPC. Esta función está disponible para los clientes de Java que usen gRPC versión 1.47 o posterior. Úsalo solo en una malla que incluya a todos los clientes de gRPC.

Al crear una política personalizada, puede consultar la siguiente documentación:

• Para que tu política personalizada sea más sofisticada, puedes usar las APIs de agregación de costes de solicitudes abiertas (ORCA). Estas APIs te permiten registrar métricas sobre el coste de las consultas y la utilización del servidor. Para usar estas APIs, se necesita la versión 1.48.1 de gRPC o una posterior. Para obtener más información, consulta el ejemplo de ORCA de gRPC.

• Para obtener información sobre cómo se entregan las configuraciones de balanceo de carga personalizadas a gRPC mediante xDS, consulta Configuración de balanceador de carga personalizado de gRPC xDS.

Para configurar Cloud Service Mesh de forma que use tu política personalizada, identifica la política mediante el campo localityLbPolicies.

En los pasos siguientes se muestra este proceso. En este procedimiento, actualizas la configuración del servicio de backend grpcwallet-wallet-v2-service para que los clientes que se conecten a él usen una política personalizada llamada example.ExampleLoadBalancer.

Precaución: Esta función está diseñada para usarse en una malla de servicios que solo incluya clientes de gRPC. Los proxies de Envoy no pueden usar servicios de backend que tengan esta configuración.

gcloud

1. Exporta el archivo de configuración del servicio de backend grpcwallet-wallet-v2-service con el comando gcloud compute backend-services export:

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

2. Actualiza el archivo bs_config.yaml exportado para hacer referencia a la política example.ExampleLoadBalancer. Incluya las siguientes líneas:

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

3. Importa el archivo actualizado con el comando gcloud compute backend-services import:

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

4. Opcional: Prueba la configuración del balanceo de carga:

   Java

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

   Si has configurado correctamente la política de balanceo de carga personalizada, verás el mensaje que has incluido en la configuración ("Hello load-balancing world!").

Definir una lista de políticas preferidas

Si tienes varios clientes que no admiten una única política de balanceo de carga, crea una lista de políticas que puedan usar tus clientes. Con esta opción, si un cliente concreto no puede usar la primera política preferida, gRPC recurre a la siguiente política de la lista.

Cuando creas una lista de políticas preferidas, las opciones válidas incluyen políticas personalizadas, ROUND_ROBIN y, en el caso de los clientes de Java, LEAST_REQUEST. Puedes incluir hasta 10 políticas.

Esta función solo está disponible para los clientes de Java que usen gRPC versión 1.47 o posterior. Úsalo solo en una malla que incluya a todos los clientes de gRPC.

Precaución: Esta función está diseñada para usarse en una malla de servicios que solo incluya clientes de gRPC. Los proxies de Envoy no pueden usar servicios de backend que tengan esta configuración.

gcloud

1. Exporta el archivo de configuración del servicio de backend grpcwallet-wallet-v2-service con el comando gcloud compute backend-services export:

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

1. Actualice el archivo bs_config.yaml exportado para incluir el campo localityLbPolicies. Rellénelo con entradas que representen las siguientes políticas:

   • Una política personalizada no válida (example.InvalidLoadBalancer)
   • Una política personalizada válida (example.ExampleLoadBalancer)
   • Una política integrada admitida (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 el archivo actualizado con el comando gcloud compute backend-services import:

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

3. Opcional: Prueba la configuración del balanceo de carga:

   Java

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

   En respuesta, gRPC intenta encontrar example.InvalidLoadBalancer y no lo consigue. Después, vuelve a usar example.ExampleLoadBalancer y verás el mensaje que has incluido en la configuración ("Hello load-balancing world!"). El registro de gRPC en el cliente incluye un mensaje que indica que no se ha encontrado example.InvalidLoadBalancer.

Limpiar los recursos

Para limpiar los recursos, ejecuta el siguiente comando desde tu sistema local:

traffic-director-grpc-examples/scripts/cleanup.sh

Bloquear el tráfico entre servicios

Si quieres bloquear el tráfico entre el servicio A y el servicio B, y tu implementación está en GKE, configura la seguridad del servicio y usa una política de autorización para bloquear el tráfico entre los servicios. Para obtener instrucciones completas, consulta Seguridad de los servicios de Cloud Service Mesh y las instrucciones de configuración con Envoy y gRPC sin proxy.

Siguientes pasos

• Para ayudarte a resolver problemas de configuración de Cloud Service Mesh, consulta Solucionar problemas de despliegues que utilizan gRPC sin proxy.