Configura la administración avanzada del tráfico con servicios de gRPC sin proxy

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

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

  • Coincidencia de ruta
  • División del tráfico
  • Disyuntores
  • Inyección de fallas
  • Duración máxima de la transmisión
  • Reintentar
  • Afinidad de sesión
  • Detección de valores atípicos
  • Balanceo de cargas de localidad

Si bien este documento se centra en la configuración de la administración avanzada del tráfico con gRPC sin proxy en Compute Engine, la administración avanzada del tráfico también es compatible cuando usas gRPC sin proxy en Google Kubernetes Engine (GKE).

Antes de comenzar

Antes de configurar la administración avanzada de tráfico, revisa los requisitos en Prepárate para configurar la malla de servicios de Cloud con servicios de gRPC sin proxy. No puedes configurar la administración avanzada de tráfico, a menos que se cumplan todos los requisitos.

Para obtener información conceptual sobre estas características, consulta Administración avanzada del tráfico.

Acerca del ejemplo de Wallet de gRPC

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

Como se muestra en el siguiente diagrama, creas un cliente de gRPC que llama al servicio Wallet para obtener el saldo de una cuenta y al servicio Stats para de 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 del enrutamiento de tráfico de Wallet de gRPC.
Ejemplo de configuración del enrutamiento de tráfico de Wallet de gRPC (haz clic para ampliar)

En el ejemplo, implementas dos versiones de las implementaciones Wallet y Stats para ilustrar el enrutamiento de solicitudes según las reglas que configures. Para simular la compilación y la implementación de diferentes versiones de un servicio, usa las marcas del servidor a fin de cambiar el comportamiento de los objetos binarios que compilas una sola vez.

  • La marca --port especifica el puerto en el que escucha el servicio en una instancia de VM.
  • La marca --hostname_suffix especifica un valor que se agrega al nombre de host de la instancia de VM que responde a una solicitud. El valor resultante se agrega como los metadatos hostname en la respuesta. Esto te ayuda a identificar qué instancia de un grupo de instancias respondió 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 objeto binario de Wallet se comporta como una versión v1.

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

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

Luego de implementar estos servicios, configura Cloud Service Mesh para enrutar solicitudes a estos servicios de backend desde un cliente de prueba, según el enrutamiento en la siguiente tabla. El cliente se conecta al nombre de host virtual de un servicio, como se muestra en la columna de host.

Host Reglas de coincidencia Acción de enrutamiento
wallet.grpcwallet.io Prefijo de la ruta de acceso: "/"
Encabezado presente: "session_id" 		Ruta a wallet-v1-affinity
Prefijo de la ruta de acceso: "/"
Encabezado: {"route": "timeout"} 		Establece el tiempo de espera de 5 segundos y
la ruta a wallet-v2
Prefijo de la ruta de acceso: "/"
Encabezado: {"route": "fault"} 		Falla el 50% de las solicitudes y
enruta el resto a wallet-v2
Prefijo de la ruta de acceso: "/"
Encabezado: {"membership": "premium"} 		Enruta a wallet-v1 y
vuelve a intentarlo hasta 3 veces en caso de error
Ruta de acceso completa: /grpc.examples.wallet.Wallet/FetchBalance Ruta a
wallet-v1: 70%
wallet-v2: 30%
Predeterminada Ruta a wallet-v1
stats.grpcwallet.io Prefijo de la ruta de acceso: "/"
Encabezado: {"membership": "premium"} 		Ruta a stats-premium
Predeterminada Ruta a stats
account.grpcwallet.io Prefijo de la ruta de acceso: "/"
Encabezado: {"route": "account-fault"} 		Falla las solicitudes del 30% y
enruta el resto a account
Predeterminada account

En este ejemplo, se usa una división del tráfico de 70/30 entre dos servicios existentes. Si divides el tráfico a un servicio nuevo al que no se ha hecho referencia en el mapa de URL antes, primero agrega el servicio nuevo a weightedBackendServices y asígnale un peso de 0. Luego, aumenta de forma gradual 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 administración de tráfico.

Opción Descripción
--watch=true Llama a los métodos de transmisión para ver el saldo o el precio
--unary_watch=true Llama a métodos unarios repetidas veces para ver el saldo o el precio.
--user=Alice Incorporar encabezado {"membership": "premium"}
--user=Bob Incorporar encabezado {"membership": "normal"}
--route=value Incorporar encabezado {"route": "value"}
--affinity=true Incorporar encabezado {"session_id": "value"}

Prepara el entorno local

A fin de configurar el entorno local para estos ejemplos, ejecuta los siguientes comandos:

  1. Actualiza el objeto binario gcloud para asegurarte de tener 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

Crea y configura instancias de Cloud Router

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

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 de 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 la verificación de estado de gRPC y la regla de firewall

En esta sección, crearás una verificación de estado de gRPC y una regla de firewall para permitir que las solicitudes de verificación de estado de gRPC lleguen a tu red. Luego, se asocia la verificación de estado de gRPC a los servicios de backend para verificar el estado de los backends en esos servicios de backend.

gcloud

  1. Crea la verificación de estado:

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

  2. Crea la regla de firewall para la verificación de 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 instancias.

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

gcloud

  • Crea la plantilla de instancias:

    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 el grupo de instancias administrado

Los grupos de instancias administrados (MIG) usan el ajuste de escala automático para crear instancias de VM nuevas según sea necesario. En esta sección, crearás un MIG mediante la plantilla de instancias 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

Configura el puerto con nombre

En esta sección, configurarás el puerto con nombre para el servicio de gRPC. El puerto con nombre es el puerto en el que el servicio de 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 cargas de INTERNAL_SELF_MANAGED y el protocolo GRPC. Luego, asociarás la verificación de estado y el grupo de instancias con el servicio de backend. En este ejemplo, usarás el MIG que creaste en Crea el grupo de instancias administrado. Este MIG ejecuta el servicio de gRPC account. El puerto en la marca --port-name es el puerto con nombre que creaste en Configura el puerto con nombre.

gcloud

  1. Crea el servicio de backend y asocia la verificación de estado con el servicio de backend nuevo:

    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. Agrega el grupo de instancias administrado 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 Wallet de gRPC son similares a los pasos anteriores. Crea los servicios restantes mediante la ejecución de una secuencia de comandos 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 de 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"'

Crea las reglas de enrutamiento

En esta sección, crearás un mapa de URL que se usa para demostrar varias funciones de administración del tráfico. El mapa de URL 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 URL, hostRules especifica los nombres de host virtuales de los servicios del ejemplo. Estos son los nombres que un cliente usa 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, configura una entrada hosts con el valor account.grpcwallet.io.

El pathMatcher asociado con una entrada de hosts especifica el nombre de un pathMatcher que contiene todas las reglas de enrutamiento para ese host virtual. ApathMatcher consiste en reglas de coincidencia y reglas de acción correspondientes, como se describe enAcerca del ejemplo de Billet de gRPC.

gcloud

Crea el mapa de 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 el proxy de destino y la regla de reenvío

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

El proxy de gRPC de destino hace referencia al mapa de URL que creaste en el paso anterior. La marca --validate-for-proxyless habilita verificaciones de configuración para que no descuides habilitar accidentalmente una función que no es compatible con gRPC sin proxy de Google Cloud.

gcloud

  • Crea el proxy de 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 de gRPC de destino que creaste. El de balanceo de cargas se estableció en INTERNAL_SELF_MANAGED para indicar que este de reenvío de red de Cloud la usa Cloud Service Mesh. Debe ser una regla de reenvío global. La dirección IP está configurada en 0.0.0.0 porque un gRPC sin proxy resuelve el hostname:port en el URI de destino enviando un LDS a la malla de servicios de Cloud en lugar de realizar una búsqueda de DNS. Para obtener más información, consulta Esquema de resolución de nombres.

Cuando no se especifica un 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 configurada con el puerto 8080. En este ejemplo, la regla de reenvío se configura 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

Verifica la configuración

Cuando se complete el proceso de configuración, verifica que los servicios de backend que configuraste estén disponibles. Para ello, revisa la página de Cloud Service Mesh en la consola de Google Cloud. Confirma que los servicios de backend y los backends asociados estén en buen estado. Esto puede tardar varios minutos.

Verifica la configuración de enrutamiento

En esta sección, verificarás que la configuración de enrutamiento funcione de forma correcta. Usa la herramienta de grpcurl para probar la configuración.

gcloud

  1. Crea una VM de cliente en la que ejecutes los clientes para probar el servicio. De manera opcional, puedes incluir la marca --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.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. Ejecute los siguientes 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 de sidecar, el cliente de gRPC debe usar el esquema de resolución de nombres de xds. Este esquema indica a la biblioteca de gRPC que se usa en el cliente que debe usar un servidor xDS para resolver el nombre de host. Para ello, se requiere una configuración de arranque.

La secuencia de comandos de inicio de la sección anterior configura la variable de entorno GRPC_XDS_BOOTSTRAP y usa una secuencia de comandos auxiliar para generar el archivo de arranque. Los valores para 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 de las instancias de VM de Compute Engine. Puedes proporcionar estos valores a la secuencia de comandos auxiliar de forma manual con las opciones -gcp-project-number y -vpc-network-name.

Verifica la configuración mediante la herramienta de grpcurl

Ejecuta los siguientes comandos en la shell de SSH para verificar que wallet-service, stats-service y account-service estén en ejecución:

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

Verifica con los clientes grpc-wallet

Usa las siguientes instrucciones específicas para cada lenguaje a fin de verificar la configuración. Los comandos envían varias RPC, algunas con metadatos adicionales, para mostrar que las solicitudes se enrutan a servicios de backend en función de las reglas de coincidencia del mapa de URL. El comando también imprime el nombre de host de la instancia de VM para cada respuesta a fin de mostrar a qué instancia de VM se enruta la solicitud.

Java

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

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

  2. Ejecute los siguientes 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. A fin de verificar el servicio con un cliente de gRPC para Go, instala Golang 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. Ejecute los siguientes 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 de C++ de gRPC, ejecuta el siguiente comando:

    sudo apt-get install -y build-essential

  2. Ejecute los siguientes 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

Configura opciones más avanzadas

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

Disyuntores

La interrupción de circuitos te permite establecer umbrales de fallas para evitar que las solicitudes del cliente sobrecarguen tus servicios de backend. Cuando la cantidad de solicitudes pendientes alcanza el límite que estableciste, el cliente deja de enviar solicitudes adicionales, lo que le da tiempo a los servicios de backend para recuperarse.

De esta manera, la interrupción de circuitos evita errores en cascada, ya que muestra un error al cliente en vez de sobrecargar un servicio backend. Esto permite que se entregue parte del tráfico mientras se proporciona tiempo para administrar la situación de sobrecarga, como controlar un aumento repentino de tráfico mediante el aumento de la capacidad a través del ajuste de escala automático.

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

circuitBreakers:
  maxRequests: 1

Este parámetro de configuración limita a los clientes a una solicitud pendiente a stats-service a la vez. Debido a que solo hay un servicio de wallet-v2, ejecutar dos operaciones de WatchBalance simultáneas del cliente de Wallet presenta fallas desde la segunda instancia.

Java

  1. Ejecute los siguientes 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. El resultado luce de la siguiente manera:

    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. Ejecute los siguientes 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. El resultado luce de la siguiente manera:

    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. Ejecute los siguientes 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. El resultado luce de la siguiente manera:

    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 fallas

Presenta errores cuando se entregan solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta característica es útil para probar la resiliencia de un servicio ante fallas simuladas.

Cuando creaste el mapa de URL, configuraste la política de inserción de fallas para que falle el 50% de las RPC enviadas a wallet.grpcwallet.io con el encabezado route=fault.

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

Java

  1. Ejecute los siguientes 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. El resultado luce de la siguiente manera:

    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. Ejecute los siguientes 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. El resultado luce de la siguiente manera:

     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. Ejecute los siguientes 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. El resultado luce de la siguiente manera:

    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 transmisión permite que se aplique un tiempo de espera máximo a todas las RPC. Esto evita que los clientes que olvidan establecer un plazo o que establecen un plazo excesivo desperdicien recursos del servidor.

Cuando creaste el mapa de URL, estableciste una duración máxima de transmisión de 5 segundos para las RPC a wallet.grpcwallet.io con el encabezado route=timeout.

Para demostrar los tiempos de espera, primero debemos detener 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 detendría para siempre, porque no hay un servicio de backend que lo maneje y la aplicación no establece un plazo límite.

Java

  1. Ejecute los siguientes 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. Presiona ^C para interrumpir el comando.

Go

  1. Ejecute los siguientes 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. Presiona ^C para interrumpir el comando.

C++

  1. Ejecute los siguientes 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. Presiona ^C para interrumpir el comando.

Sin embargo, el siguiente comando que usa la ruta timeout falla después de 5 segundos debido a la configuración 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. El resultado luce de la siguiente manera:

    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. El resultado luce de la siguiente manera:

    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. El resultado luce de la siguiente manera:

    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 las aplicaciones de gRPC reintenten las solicitudes salientes según una política de reintento. En una política de reintento, puedes configurar las condiciones en las que se debe reintentar una solicitud con errores y la cantidad máxima de reintentos, por ejemplo, cuando falla una solicitud con un código de respuesta específico.

Cuando creaste el mapa de URL, estableciste una política de reintento para las RPC en el método FetchBalance con el encabezado membership=premium. Esta política reintenta las RPC que fallan con el código de estado unavailable hasta un máximo de 3 veces. También estableciste una política de inserción de fallas para RPC en account.grpcwallet.io con el encabezado route=account-fault que falla en el 30% de las RPC del servicio Wallet al servicio Account. Como resultado, el 30% de las RPC del cliente de prueba con el encabezado membership=normal fallan, mientras que la tasa de fallas para las RPC con el encabezado membership=premium es inferior al 1%.

Para demostrar los reintentos, usa el código en los siguientes lenguajes.

Java

Ejecute los siguientes 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

Ejecute los siguientes 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++

Ejecute los siguientes 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 hace su mejor esfuerzo para enviar solicitudes con características particulares (encabezados HTTP) a la misma instancia, siempre que la instancia esté en buen estado y tenga capacidad. Esto es útil para los servidores de aplicaciones con estado que se benefician del rendimiento y la eficiencia mejorados cuando las solicitudes de un cliente en particular se envían a la misma instancia, en lugar de, por ejemplo, la distribución round robin a instancias diferentes.

Cuando creaste el servicio de backend grpcwallet-wallet-v1-affinity-service, en la secuencia de comandos create_service.sh, localityLbPolicy se configuró 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 de 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}"

Para demostrar la afinidad de sesión, usa el código en los siguientes lenguajes. 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 en particular en el grupo de instancias del servicio de backend grpcwallet-wallet-v1-affinity-service.

Java

Ejecute los siguientes 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

Ejecute los siguientes 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++

Ejecute los siguientes 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

Restablece 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 en mal estado del grupo de balanceo de cargas. Estos hosts no saludables se denominan valores atípicos.

gRPC evalúa los hosts según la tasa de éxito, es decir, la frecuencia con el que un host maneja las solicitudes correctamente. El porcentaje se ve afectado por fallas, 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 la malla de servicios de Cloud, puedes ajustar la forma en que gRPC evalúa los hosts y cómo maneja los valores atípicos. Por ejemplo, puede especificar criterios como los siguientes:

  • La cantidad de solicitudes que debe recibir un host antes de gRPC los analiza en busca de posibles estados de valores atípicos.

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

  • El porcentaje máximo de hosts que se pueden expulsar a la vez desde el grupo de balanceo de cargas.

  • La cantidad de tiempo durante la cual se excluye un valor atípico del balanceo de cargas piscina.

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

Limitaciones

Los siguientes campos no son compatibles con los clientes de gRPC:

  • outlierDetection.consecutiveErrors

  • outlierDetection.enforcingConsecutiveErrors

  • outlierDetection.consecutiveGatewayFailure

  • outlierDetection.enforcingConsecutiveGatewayFailure

Configura la detección de valores atípicos

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

  • El análisis de detección de valores atípicos se ejecuta cada segundo. Tú lo configuras con el campo interval.
  • Los valores atípicos se expulsan del grupo de balanceo de cargas en incrementos de 30 segundos, de la siguiente manera:
    • Si un host nunca se expulsó antes, se expulsará solo por 30 segundos.
    • Si se expulsó un host anteriormente, el tiempo aumenta en 30 segundos por cada expulsión anterior. Por ejemplo, cuando se expulsa un host por tercera vez, se expulsa durante 90 segundos. Para configurar este comportamiento, usa el campo baseEjectionTime.
  • Un host se considera en mal estado si su tasa de éxito es una desviación estándar por debajo del promedio 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 valores atípicos de esta manera, sigue estos pasos.

gcloud

  1. Exporta el servicio de backend de grpcwallet-wallet-v2-service de Terraform 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 grpcwallet-wallet-v2-service. 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

Balanceo de cargas de localidad

Para hacer el uso más eficiente de tus recursos, configura la carga de localidad el balanceo de cargas. Esta función te ayuda a conservar recursos, ya que distribuye de manera uniforme las solicitudes de los clientes entre tus backends.

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

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

Puedes usar cualquier combinación de las opciones anteriores. Sin embargo, si configurar localityLbPolicy y localityLbPolicies, gRPC primero intenta para usar la configuración de localityLbPolicies.

Si no configuras el balanceo de cargas de localidad, Cloud Service Mesh usa 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.

Usa una política integrada

Si deseas que todos tus clientes usen una sola política integrada, puedes configurar el campo localityLbPolicy para seleccionarla.

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 utilizar la misma política, consulta la Define una lista de políticas preferidas.

gcloud

  1. Exporta la configuración del servicio de backend de grpcwallet-wallet-v2-service con 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 de modo que incluya el 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

Usa una política personalizada

Si corresponde, puedes usar una política de balanceo de cargas personalizada que hayas creado y implementado con gRPC. Esta función está disponible para clientes de Java que usan la versión 1.47 o posterior de gRPC. Úsala solo en una malla que incluya a todos los clientes de gRPC.

Cuando creas una política personalizada, la siguiente documentación podría ser útil:

  • Para que tu política personalizada sea más sofisticada, puedes usar el botón Open Request de agregación de costos (ORCA). Estas APIs te permiten capturar métricas sobre el costo de las consultas y el uso del servidor. El uso de estas APIs requiere Versión 1.48.1 o posterior de gRPC. Para obtener más información, consulta Ejemplo de ORCA de gRPC.

  • Para obtener información sobre cómo se configuran entregados a gRPC por xDS, consulta Configuración del balanceador de cargas personalizado de gRPC xDS.

Para configurar Cloud Service Mesh para que use tu política personalizada, identifica la política con el campo localityLbPolicies.

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

gcloud

  1. Exporta la configuración del servicio de backend de grpcwallet-wallet-v2-service con 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 al Política de example.ExampleLoadBalancer. Incluye las siguientes líneas:

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

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

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

  4. Prueba la configuración del balanceo de cargas (opcional):

    Java 

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

    Si configuraste correctamente la política de balanceo de cargas personalizada, verás el mensaje que incluiste en la configuración ("¡Hola mundo del balanceo de cargas!").

Define una lista de políticas preferidas

Si tienes varios clientes que no admiten una sola política de balanceo de cargas, crea una lista de políticas que tus clientes puedan usar. Con esta opción, Si un cliente en particular no puede usar tu primera política preferida, gRPC regresa a la siguiente política de la lista.

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

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

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. Actualiza el archivo bs_config.yaml exportado de modo que incluya el localityLbPolicies. Complétalo con entradas que representen el 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 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 cargas:

    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 y no encuentra example.InvalidLoadBalancer Luego, vuelve a usar example.ExampleLoadBalancer y verás el mensaje que incluiste en la configuración ("¡Hola mundo del balanceo de cargas!"). El registro de gRPC en el cliente incluye un mensaje que indica que no se encontró example.InvalidLoadBalancer.

Limpia los recursos

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

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

Bloquea el tráfico entre servicios

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

¿Qué sigue?