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.
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 metadatoshostname
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 valortrue
especifica que el servicio es una versión premium del serviciostats
. - La marca
--v1_behavior
con el valortrue
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 yvuelve 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:
Actualiza el objeto binario
gcloud
para asegurarte de tener la versión más reciente:gcloud components update
Descarga el repositorio de ejemplos:
sudo apt-get install git -y
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
Crea las instancias de Cloud Router:
gcloud compute routers create nat-router-us-central1 \ --network=default \ --region=us-central1
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
Crea la verificación de estado:
gcloud compute health-checks create grpc grpcwallet-health-check \ --use-serving-port
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
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
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
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')
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
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
Para verificar el servicio con un cliente de Java de gRPC, ejecuta el siguiente comando:
sudo apt-get install -y openjdk-11-jdk-headless
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
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
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++
Para verificar el servicio con un cliente de C++ de gRPC, ejecuta el siguiente comando:
sudo apt-get install -y build-essential
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
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
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}
Ejecuta el comando
kill
.kill %%
Go
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
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
Ejecuta el comando
kill
.kill %%
C++
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
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
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
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
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
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
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++
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
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
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
El comando deja de responder. Presiona ^C para interrumpir el comando.
Go
Ejecute los siguientes comandos:
cd ~/traffic-director-grpc-examples/go/wallet_client ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
El comando deja de responder. Presiona ^C para interrumpir el comando.
C++
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
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
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
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
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
El resultado luce de la siguiente manera:
failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.
C++
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
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
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
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
Exporta el servicio de backend de
grpcwallet-wallet-v2-service
de Terraform con el Comandogcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
En el archivo
bs_config.yaml
, actualizagrpcwallet-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
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
Exporta la configuración del servicio de backend de
grpcwallet-wallet-v2-service
congcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Actualiza el archivo
bs_config.yaml
exportado de modo que incluya el siguientes líneas:localityLbPolicy: -- policy name: RING_HASH
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
Exporta la configuración del servicio de backend de
grpcwallet-wallet-v2-service
congcloud compute backend-services export
:gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Actualiza el archivo
bs_config.yaml
exportado para hacer referencia al Política deexample.ExampleLoadBalancer
. Incluye las siguientes líneas:localityLbPolicies: - customPolicy: name: example.ExampleLoadBalancer data: '{ "message": "Hello load-balancing world!" }'
Importa el archivo actualizado con gcloud compute backend-services import. :
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
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
- Exporta el archivo de configuración del servicio de backend
grpcwallet-wallet-v2-service
con el comandogcloud compute backend-services export
:
gcloud compute backend-services export grpcwallet-wallet-v2-service \ --destination=bs_config.yaml \ --global
Actualiza el archivo
bs_config.yaml
exportado de modo que incluya ellocalityLbPolicies
. 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
- Una política personalizada no válida (
Importa el archivo actualizado con gcloud compute backend-services import. :
gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
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 usarexample.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?
- Para ayudarte a resolver problemas de configuración de Cloud Service Mesh, consulta Soluciona problemas de implementaciones que usan gRPC sin proxy.