Configure a gestão avançada de tráfego com serviços gRPC sem proxy

Nota: este guia só suporta a Cloud Service Mesh com Google Cloud APIs e não suporta as APIs Istio. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Esta configuração é suportada para clientes de pré-visualização, mas não a recomendamos para novos utilizadores do Cloud Service Mesh. Para mais informações, consulte a vista geral do encaminhamento de serviços do Cloud Service Mesh.

Este documento fornece instruções para configurar a Cloud Service Mesh com as seguintes funcionalidades de gestão de tráfego:

• Correspondência de trajetos
• Divisão de tráfego
• Interrupção de circuito
• Injeção de falhas
• Duração máxima do stream
• Tentar novamente
• Afinidade de sessão
• Deteção de valores atípicos
• Balanceamento de carga de localidade

Embora este documento se foque na configuração da gestão de tráfego avançada com gRPC sem proxy no Compute Engine, a gestão de tráfego avançada também é suportada quando usa gRPC sem proxy no Google Kubernetes Engine (GKE).

Antes de começar

Antes de configurar a gestão de tráfego avançada, reveja os requisitos em Prepare-se para configurar o Cloud Service Mesh com serviços gRPC sem proxy. Não pode configurar a gestão avançada de tráfego, a menos que todos os requisitos sejam cumpridos.

Para informações conceptuais sobre estas funcionalidades, consulte o artigo Gestão de tráfego avançada.

Acerca do exemplo da Carteira gRPC

Para ilustrar estas funcionalidades, implementa um exemplo da Carteira gRPC. Neste exemplo, existem três serviços gRPC: grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats e grpc.examples.wallet.account.Account, que são implementados como três aplicações separadas.

Conforme mostrado no diagrama seguinte, cria um cliente gRPC que chama o serviço Wallet para obter o saldo de uma conta e chama o serviço Stats para obter o preço de uma moeda. O serviço Wallet chama os serviços Stats e Account para calcular o saldo. O serviço Stats também chama o serviço Account para obter informações do utilizador.

Exemplo de configuração de encaminhamento de tráfego da Carteira gRPC (clique para aumentar)

No exemplo, implementa duas versões das implementações Wallet e Stats para ilustrar o encaminhamento de pedidos com base nas regras que configurar. Para simular a criação e a implementação de diferentes versões de um serviço, usa flags do servidor para alterar o comportamento dos ficheiros binários que cria apenas uma vez.

• A flag --port especifica a porta na qual o serviço numa instância de VM ouve.
• A flag --hostname_suffix especifica um valor que é anexado ao nome do anfitrião da instância de VM que responde a um pedido. O valor resultante é adicionado como metadados hostname na resposta. Isto ajuda a identificar que instância num grupo de instâncias respondeu ao pedido do cliente.
• A flag --premium_only com o valor true especifica que o serviço é uma versão premium do serviço stats.
• A flag --v1_behavior com o valor true especifica que o binário da carteira funciona como uma versão v1.

A tabela seguinte mostra os valores destas flags para cada instância de VM que está a executar um dos serviços gRPC, o número de instâncias num grupo de instâncias e os serviços de back-end aos quais estes grupos de instâncias pertencem.

Nota: para simplificar, o prefixo e o sufixo comuns nos nomes dos serviços de back-end e dos grupos de instâncias não são apresentados. Por exemplo, o serviço de back-end grpcwallet-wallet-v1-service é apresentado como wallet-v1.

Serviço de back-end	Grupo de instâncias	Instâncias	Sinalizadores do 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"

Depois de implementar estes serviços, configure a Cloud Service Mesh para encaminhar pedidos para estes serviços de back-end a partir de um cliente de teste, com base nas regras de encaminhamento na tabela seguinte. O cliente estabelece ligação ao nome do anfitrião virtual de um serviço, conforme apresentado na coluna Anfitrião.

Nota: o pseudo-cabeçalho HTTP/2 num pedido gRPC tem o formato /ServiceName/MethodName, em que ServiceName é o nome do serviço gRPC que está a ser chamado no pedido gRPC e MethodName é o método nesse serviço.

:path

Anfitrião	Regras de correspondência	Ação de planeamento de trajeto
wallet.grpcwallet.io	Prefixo do caminho: "/" Cabeçalho presente: "session_id"	Trajeto para wallet-v1-affinity
	Prefixo do caminho: "/" Cabeçalho: {"route": "timeout"}	Definir tempo limite de 5 segundos e encaminhar para wallet-v2
	Prefixo do caminho: "/" Cabeçalho: {"route": "fault"}	Falhar 50% dos pedidos e encaminhar o resto para wallet-v2
	Prefixo do caminho: "/" Cabeçalho: {"membership": "premium"}	Encaminhe para wallet-v1 e repita até 3 vezes em caso de falha
	Caminho completo: /grpc.examples.wallet.Wallet/FetchBalance	Rota para: wallet-v1: 70% wallet-v2: 30%
	Predefinição	Trajeto para wallet-v1
stats.grpcwallet.io	Prefixo do caminho: "/" Cabeçalho: {"membership": "premium"}	Trajeto para stats-premium
	Predefinição	Trajeto para stats
account.grpcwallet.io	Prefixo do caminho: "/" Cabeçalho: {"route": "account-fault"}	Falhar 30% dos pedidos e encaminhar o resto para account
	Predefinição	account

Este exemplo usa uma divisão de tráfego de 70/30 entre dois serviços existentes. Se estiver a dividir o tráfego para um novo serviço que não tenha sido referenciado pelo mapa de URLs anteriormente, adicione primeiro o novo serviço a weightedBackendServices e atribua-lhe um peso de 0. Em seguida, aumente gradualmente o peso atribuído a esse serviço.

O cliente de teste tem as seguintes opções que lhe permitem gerar pedidos adequados para demonstrar as funcionalidades de gestão de tráfego.

Opção	Descrição
--watch=true	Métodos de streaming de chamadas para ver o saldo/preço
--unary_watch=true	Chamar métodos unários repetidamente para monitorizar o saldo/preço
--user=Alice	Injetar cabeçalho {"membership": "premium"}
--user=Bob	Injetar cabeçalho {"membership": "normal"}
--route=value	Injetar cabeçalho {"route": "value"}
--affinity=true	Injetar cabeçalho {"session_id": "value"}

Prepare o seu ambiente local

Para configurar o ambiente local para estes exemplos, execute os seguintes comandos:

1. Atualize o ficheiro binário gcloud para garantir que tem a versão mais recente:

   gcloud components update
   

2. Transfira o repositório de exemplos:

   sudo apt-get install git -y
   

3. Clone o repositório correto para o exemplo:

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

Crie e configure instâncias do Cloud Router

Nesta secção, cria instâncias do Cloud Router em cada região e configura-as para o Cloud NAT. As VMs criadas por este exemplo não têm endereços IP externos, mas precisam de ter acesso à Internet. A configuração do Cloud Router com o Cloud NAT fornece o acesso necessário.

gcloud

1. Crie as instâncias do Cloud Router:

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

2. Configure os routers para o 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
   

Crie a verificação de funcionamento de gRPC e a regra de firewall

Nesta secção, cria uma verificação de funcionamento gRPC e uma regra de firewall para permitir que os pedidos de verificação de funcionamento gRPC alcancem a sua rede. Posteriormente, a verificação de estado do gRPC é associada aos serviços de back-end para que possa verificar o estado das instâncias de back-end desses serviços de back-end.

gcloud

1. Crie a verificação de funcionamento:

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

2. Crie a regra de firewall para a verificação de funcionamento:

   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
   

Crie o modelo de instância

Nesta secção, cria um modelo de instância para implementar o serviço account gRPC que é exposto na porta 50053.

gcloud

• Crie o modelo de instância:

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

Crie o grupo de instâncias geridas

Os grupos de instâncias geridas (GIGs) usam a escala automática para criar novas instâncias de VM conforme necessário. Nesta secção, cria um MIG usando o modelo de instância que criou na secção anterior.

gcloud

• Crie o grupo de instâncias:

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

Configure a porta com nome

Nesta secção, configura a porta com nome para o serviço gRPC. A porta nomeada é a porta na qual o serviço gRPC deteta pedidos. Neste exemplo, a porta com nome é a porta 50053.

gcloud

• Crie a porta com nome:

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

Crie o serviço de back-end

Nesta secção, cria um serviço de back-end global com um esquema de balanceamento de carga de INTERNAL_SELF_MANAGED e um protocolo GRPC. Em seguida, associa a verificação de estado e o grupo de instâncias ao serviço de back-end. Neste exemplo, usa o MIG que criou em Crie o grupo de instâncias geridas. Este MIG executa o serviço account gRPC. A porta na flag --port-name é a porta com nome que criou em Configure a porta com nome.

gcloud

1. Crie o serviço de back-end e, em seguida, associe a verificação de funcionamento ao novo serviço de back-end:

   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. Adicione o grupo de instâncias geridas como o back-end:

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

Os passos para criar os restantes serviços de back-end usados no exemplo da carteira gRPC são semelhantes aos passos anteriores. Crie os restantes serviços executando um script de shell. O script implementa os seguintes serviços de back-end:

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

Execute o script de shell que cria os serviços de back-end adicionais:

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

Crie as regras de encaminhamento

Nesta secção, cria um mapa de URLs que é usado para demonstrar várias funcionalidades de gestão de tráfego. O mapa de URLs especifica os nomes de anfitriões virtuais dos serviços neste exemplo e as regras de encaminhamento associadas. Para mais informações, consulte o artigo Mapas de regras de encaminhamento.

No mapa de URLs, os hostRules especificam os nomes de anfitrião virtuais dos serviços no exemplo. Estes são os nomes que um cliente usa no URI do canal para se ligar a um serviço específico. Por exemplo, para enviar um pedido para o serviço account, um cliente usa xds:///account.grpcwallet.io no URI do canal. No hostRules, configure uma entrada hosts com o valor account.grpcwallet.io.

O pathMatcher associado a uma entrada hosts especifica o nome de um pathMatcher que contém todas as regras de encaminhamento para esse anfitrião virtual. Uma configuração de pathMatcher consiste em regras de correspondência e regras de ação correspondentes, conforme descrito no artigo Acerca do exemplo da Carteira do gRPC.

gcloud

Crie o mapa de URLs:

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet

gcloud compute url-maps import grpcwallet-url-map << EOF
name: grpcwallet-url-map
defaultService: $BS_PREFIX-account-service

hostRules:
- hosts:
  - account.grpcwallet.io
  pathMatcher: grpcwallet-account-path-matcher
- hosts:
  - stats.grpcwallet.io
  pathMatcher: grpcwallet-stats-path-matcher
- hosts:
  - wallet.grpcwallet.io
  pathMatcher: grpcwallet-wallet-path-matcher

pathMatchers:
- name: grpcwallet-account-path-matcher
  defaultService: $BS_PREFIX-account-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: account-fault
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-account-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 30

- name: grpcwallet-stats-path-matcher
  defaultService: $BS_PREFIX-stats-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 0
    service: $BS_PREFIX-stats-premium-service

- name: grpcwallet-wallet-path-matcher
  defaultService: $BS_PREFIX-wallet-v1-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: session_id
        presentMatch: true
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-affinity-service
        weight: 100

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: timeout
    priority: 1
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      maxStreamDuration:
        seconds: 5

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: fault
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 50

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 3
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 100
      retryPolicy:
        retryConditions:
          - unavailable
        numRetries: 3

  - matchRules:
    - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance
    priority: 4
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 70
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 30

  - matchRules:
    - prefixMatch: /grpc.examples.wallet.Wallet/
    priority: 5
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
EOF

Crie o proxy de destino e a regra de encaminhamento

Nesta secção, cria o proxy gRPC de destino e uma regra de encaminhamento.

O proxy gRPC de destino faz referência ao mapa de URLs que criou no passo anterior. A flag --validate-for-proxyless ativa as verificações de configuração para que não ative acidentalmente uma funcionalidade que não seja compatível com implementações de gRPC sem proxy.

gcloud

• Crie o proxy gRPC de destino:

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

A regra de encaminhamento faz referência ao proxy gRPC de destino que criou. O esquema de balanceamento de carga está definido como INTERNAL_SELF_MANAGED para indicar que esta regra de encaminhamento é usada pela Cloud Service Mesh. Tem de ser uma regra de encaminhamento global. O endereço IP está definido como 0.0.0.0 porque um cliente gRPC sem proxy resolve o hostname:port no URI de destino enviando um pedido LDS para a Cloud Service Mesh em vez de fazer uma procura de DNS. Para mais informações, consulte o artigo Esquema de resolução de nomes.

Quando não é especificada uma porta no URI de destino, o valor predefinido é 80. Por exemplo, um URI de destino xds:///foo.myservice:8080 corresponde a uma regra de encaminhamento que está configurada com a porta 8080. Neste exemplo, a regra de encaminhamento está configurada com a porta 80.

gcloud

• Crie a regra de encaminhamento:

  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
  

Valide a configuração

Quando o processo de configuração estiver concluído, verifique se os serviços de back-end que configurou estão disponíveis consultando a página Cloud Service Mesh na Google Cloud consola. Confirme se os serviços de back-end e os back-ends associados são comunicados como em bom estado. Este processo pode demorar alguns minutos.

Valide a configuração de encaminhamento

Nesta secção, verifica se a configuração de encaminhamento está a funcionar corretamente. Usa a ferramenta grpcurl para testar a configuração.

gcloud

1. Crie uma VM do cliente na qual executa os clientes para testar o serviço. Opcionalmente, pode incluir a flag --network-interface=no-address.

   gcloud compute instances create grpc-wallet-client \
       --zone=us-central1-a \
       --scopes=https://www.googleapis.com/auth/cloud-platform \
       --image-family=debian-10 \
       --image-project=debian-cloud \
       --metadata-from-file=startup-script=<(echo '#! /bin/bash
   set -e
   export GRPC_XDS_BOOTSTRAP=/run/td-grpc-bootstrap.json
   # Expose bootstrap variable to SSH connections
   echo export GRPC_XDS_BOOTSTRAP=$GRPC_XDS_BOOTSTRAP | sudo tee /etc/profile.d/grpc-xds-bootstrap.sh
   # Create the bootstrap file
   curl -L https://storage.googleapis.com/traffic-director/td-grpc-bootstrap-0.16.0.tar.gz | tar -xz
   ./td-grpc-bootstrap-0.16.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')
   

2. Aceda à VM através de SSH e execute os seguintes comandos para preparar a VM:

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

3. Execute os seguintes 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 aceder aos serviços sem um proxy sidecar, o cliente gRPC tem de usar o esquema de resolução de nomes xds. Este esquema indica à biblioteca gRPC usada no cliente que use um servidor xDS para resolver o nome do anfitrião. Para isso, é necessária uma configuração de arranque.

O script de arranque na secção anterior define a variável de ambiente GRPC_XDS_BOOTSTRAP e usa um script auxiliar para gerar o ficheiro de arranque. Os valores de TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME e zona no ficheiro de arranque gerado são obtidos a partir do servidor de metadados que conhece estes detalhes sobre as instâncias de VM do Compute Engine. Pode fornecer estes valores ao script auxiliar manualmente através das opções -gcp-project-number e -vpc-network-name.

Nota: de acordo com a política, recomendamos que os utilizadores verifiquem anualmente se existem atualizações do gerador de arranque do gRPC de TD.

Valide a configuração através da grpcurl ferramenta

Execute os seguintes comandos na shell SSH para verificar se o wallet-service, o stats-service e o account-service estão em execução:

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

São apresentados os seguintes resultados:

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

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

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Valide com clientes do grpc-wallet

Use as instruções específicas do idioma que se seguem para validar a configuração. Os comandos enviam várias RPCs, algumas com metadados adicionais, para mostrar que os pedidos são encaminhados para serviços de back-end com base nas regras de correspondência do mapa de URLs. O comando também imprime o nome do anfitrião da instância de VM para cada resposta para mostrar a instância de VM para a qual o pedido foi encaminhado.

Java

1. Para validar o serviço com um cliente Java gRPC, execute o seguinte:

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

2. Execute os seguintes 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
   

Ir

1. Para validar o serviço com um cliente Go gRPC, instale o golang ou siga as instruções oficiais:

   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. Execute os seguintes 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 validar o serviço com um cliente C++ gRPC, execute o seguinte:

   sudo apt-get install -y build-essential
   

2. Execute os seguintes 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
   

Configure opções mais avançadas

Pode configurar opções de planeamento de trajeto avançadas adicionais através das instruções nas secções seguintes.

Interrupção de circuito

A interrupção de circuitos permite-lhe definir limites de falhas para evitar que os pedidos de clientes sobrecarreguem os seus serviços de back-end. Depois de o número de pedidos pendentes atingir um limite que definiu, o cliente deixa de enviar pedidos adicionais, dando aos seus serviços de back-end tempo para recuperar.

A interrupção de circuitos impede falhas em cascata devolvendo um erro ao cliente em vez de sobrecarregar um serviço de back-end. Isto permite o fornecimento de algum tráfego enquanto dá tempo para gerir a situação de sobrecarga, como processar um pico de tráfego aumentando a capacidade através do dimensionamento automático.

Quando cria o serviço de back-end para o stats-service, o script create_service.sh inclui as seguintes linhas na respetiva configuração:

circuitBreakers:
  maxRequests: 1

Esta definição limita os clientes a um pedido pendente para o stats-service de cada vez. Uma vez que existe apenas um serviço wallet-v2, a execução de duas operações de cliente da Carteira WatchBalance em simultâneo apresenta falhas na segunda instância.

Java

1. Execute os seguintes 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. O resultado tem o seguinte aspeto:

   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. Emita o comando kill:

   kill %%
   

Ir

1. Execute os seguintes 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. O resultado tem o seguinte aspeto:

   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. Emita o comando kill:

   kill %%
   

C++

1. Execute os seguintes 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. O resultado tem o seguinte aspeto:

   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. Emita o comando kill:

   kill %%
   

Injeção de falhas

A injeção de falhas introduz erros ao processar pedidos para simular falhas, incluindo latência elevada, sobrecarga do serviço, falhas do serviço e partição de rede. Esta funcionalidade é útil para testar a resiliência de um serviço a falhas simuladas.

Quando criou o mapa de URLs anteriormente, definiu a política de injeção de falhas para falhar 50% dos RPCs enviados para wallet.grpcwallet.io com o cabeçalho route=fault.

Para demonstrar a injeção de falhas, use o código nos seguintes idiomas.

Java

1. Execute os seguintes 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. O resultado tem o seguinte aspeto:

   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}
   

Ir

1. Execute os seguintes 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. O resultado tem o seguinte aspeto:

    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. Execute os seguintes 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. O resultado tem o seguinte aspeto:

   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
   

Duração máxima do stream

A duração máxima da stream permite aplicar um limite de tempo máximo a todos os RPCs. Isto impede que os clientes que se esquecem de definir um prazo ou que definem um prazo excessivo desperdicem recursos do servidor.

Quando criou o mapa de URLs anteriormente, definiu uma duração máxima da stream de 5 segundos para RPCs enviados para wallet.grpcwallet.io com o cabeçalho route=timeout.

Para demonstrar os limites de tempo, paramos primeiro o serviço wallet-v2.

gcloud

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

O seguinte comando ficaria bloqueado para sempre porque não existe um serviço de back-end para o processar e a aplicação não define um prazo.

Java

1. Execute os seguintes comandos:

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

2. O comando deixa de responder. Prima ^C para interromper o comando.

Ir

1. Execute os seguintes comandos:

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

2. O comando deixa de responder. Prima ^C para interromper o comando.

C++

1. Execute os seguintes comandos:

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

2. O comando deixa de responder. Prima ^C para interromper o comando.

No entanto, o seguinte comando que usa a rota timeout falha após 5 segundos devido à definição maxStreamDuration.

Java

1. Execute o seguinte 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. O resultado tem o seguinte aspeto:

   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}
   

Ir

1. Execute o seguinte comando:

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

2. O resultado tem o seguinte aspeto:

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

C++

1. Execute o seguinte 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. O resultado tem o seguinte aspeto:

   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
   

Reinicie o serviço wallet-v2.

gcloud

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

Tentar novamente

As novas tentativas ajudam a melhorar a disponibilidade do serviço, permitindo que as suas aplicações gRPC tentem novamente os pedidos de saída de acordo com uma política de novas tentativas. Numa política de repetição, pode configurar as condições sob as quais um pedido com falha deve ser repetido e o número máximo de tentativas de repetição, por exemplo, quando um pedido falha com um código de resposta específico.

Quando criou o mapa de URLs anteriormente, definiu uma política de repetição para RPCs para o método FetchBalance com o cabeçalho membership=premium. Esta política tenta novamente RPCs que falham com o código de estado unavailable até um máximo de 3 vezes. Também definiu uma política de injeção de falhas para RPCs para account.grpcwallet.io com o cabeçalho route=account-fault que falha em 30% das RPCs do serviço Wallet para o serviço Account. Como resultado, 30% das RPCs do cliente de teste com o cabeçalho membership=normal falham, enquanto a taxa de falhas das RPCs com o cabeçalho membership=premium é inferior a 1%.

Para demonstrar as novas tentativas, use o código nos seguintes idiomas.

Java

Execute os seguintes 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

Ir

Execute os seguintes 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++

Execute os seguintes 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

Afinidade de sessão

A afinidade de sessão oferece uma tentativa de melhor esforço para enviar pedidos com características específicas (cabeçalhos HTTP) para a mesma instância durante o tempo em que a instância estiver em bom estado e tiver capacidade. Isto é útil para servidores de aplicações com estado que beneficiam de um desempenho e uma eficiência melhorados quando os pedidos de um cliente específico são enviados para a mesma instância em vez de, por exemplo, uma distribuição rotativa para instâncias diferentes.

Nota: um cliente gRPC que não suporte a política de balanceamento de carga RING_HASH vai acusar negativamente a configuração da Cloud Service Mesh quando um mapa de URL referenciar um serviço de back-end com localityLbPolicy=RING_HASH. Isto faz com que o canal do cliente entre num estado de erro temporário até que a configuração seja corrigida. Consulte a secção Limitação do serviço de back-end para ver mais detalhes.

Quando criou o serviço de back-end grpcwallet-wallet-v1-affinity-service no script create_service.sh, o localityLbPolicy foi definido como ROUND_ROBIN. Neste exemplo, vai aplicar a seguinte configuração para alterar o localityLbPolicy para RING_HASH.

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

gcloud

1. Guarde a configuração do serviço de back-end grpcwallet-wallet-v1-affinity-service:

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

2. Atualize o serviço de back-end grpcwallet-wallet-v1-affinity-service:

   project_id="$(gcloud config list --format 'value(core.project)')"
   backend_config="
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: projects/${project_id}/zones/us-central1-a/instanceGroups/grpcwallet-wallet-v1-mig-us-central1
   connectionDraining:
     drainingTimeoutSec: 0
   healthChecks:
   - projects/${project_id}/global/healthChecks/grpcwallet-health-check
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   name: grpcwallet-wallet-v1-affinity-service
   portName: grpcwallet-wallet-port
   protocol: GRPC
   sessionAffinity: HEADER_FIELD
   localityLbPolicy: RING_HASH
   consistentHash:
     httpHeaderName: session_id"
   gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service --global <<< "${backend_config}"
   

Nota: a atualização do serviço de back-end pode demorar vários minutos a propagar-se aos clientes.

Para demonstrar a afinidade de sessão, use o código nos seguintes idiomas. Com a flag --affinity=true, o cliente insere um cabeçalho session-id com um valor único para cada utilizador. É usada uma hash deste valor para enviar o pedido para uma instância específica no grupo de instâncias do serviço de back-end grpcwallet-wallet-v1-affinity-service.

Java

Execute os seguintes 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

Ir

Execute os seguintes 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++

Execute os seguintes 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

Restaure a configuração do serviço de back-end grpcwallet-wallet-v1-affinity-service.

gcloud

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

Deteção de valores atípicos

Para melhorar a disponibilidade do serviço, configure a deteção de valores atípicos. Esta funcionalidade permite-lhe identificar e rejeitar temporariamente anfitriões não saudáveis do conjunto de balanceamento de carga. Estes anfitriões não saudáveis são denominados valores atípicos.

O gRPC avalia os anfitriões com base na taxa de êxito, ou seja, a frequência com que um anfitrião processa pedidos com êxito. A taxa é afetada por falhas, como erros gRPC, erros HTTP, limites de tempo e outros problemas.

Quando configura a deteção de valores atípicos através da Cloud Service Mesh, pode ajustar a forma como o gRPC avalia os anfitriões e como processa os valores atípicos. Por exemplo, pode especificar critérios como os seguintes:

• O número de pedidos que um anfitrião tem de receber antes de o gRPC o analisar para verificar um possível estado de valor atípico.

• O grau em que um anfitrião pode desviar-se da taxa de êxito média antes de ser considerado um valor atípico.

• A percentagem máxima de anfitriões que podem ser rejeitados em qualquer altura do conjunto de balanceamento de carga.

• O período durante o qual um valor atípico é excluído do conjunto de equilíbrio de carga.

Para mais informações sobre os parâmetros disponíveis, consulte a REST Resource: backendServices referência. No entanto, existem algumas limitações para o gRPC, conforme descrito na secção seguinte.

Limitações

Os seguintes campos não são suportados para clientes gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Configure a deteção de valores atípicos

O procedimento seguinte mostra como configurar a deteção de valores atípicos para um serviço que usa um grupo de instâncias como back-end. Este procedimento estabelece a seguinte configuração:

• A análise de deteção de valores atípicos é executada a cada segundo. Configura este comportamento através do campo interval.
• Os valores atípicos são rejeitados do conjunto de balanceamento de carga em incrementos de 30 segundos, da seguinte forma:
  • Se um anfitrião nunca tiver sido expulso anteriormente, é expulso durante apenas 30 segundos.
  • Se um anfitrião tiver sido anteriormente expulso, o tempo aumenta 30 segundos para cada expulsão anterior. Por exemplo, quando um anfitrião é expulso pela terceira vez, é expulso durante 90 segundos. Configura este comportamento através do campo baseEjectionTime.
• Um anfitrião é considerado não saudável se a respetiva taxa de êxito for um desvio padrão inferior à média durante o intervalo de tempo selecionado (neste caso, 1 segundo). Pode configurar o desvio padrão máximo através do campo successRateStdevFactor.

Para configurar a deteção de valores atípicos desta forma, siga os passos abaixo.

gcloud

1. Exporte o ficheiro de configuração do serviço de back-end grpcwallet-wallet-v2-service através do comando gcloud compute backend-services export:

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

2. No ficheiro bs_config.yaml, atualize a configuração grpcwallet-wallet-v2-service para incluir os campos de deteção de valores atípicos:

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

3. Importe o ficheiro atualizado através do comando gcloud compute backend-services import:

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

Nota: o exemplo da Carteira não foi concebido para incluir anfitriões não saudáveis. Por esse motivo, os anfitriões grpcwallet-wallet-v2-service não são normalmente removidos, mesmo que configure corretamente a deteção de valores atípicos.

Balanceamento de carga de localidade

Para usar os seus recursos da forma mais eficiente, configure o equilíbrio de carga de localidade. Esta funcionalidade ajuda a conservar recursos distribuindo uniformemente as solicitações de clientes pelos seus back-ends.

Quando configura o equilíbrio de carga de localidade, pode usar as opções descritas na tabela seguinte. Todas as opções requerem que configure o recurso backendServices.

Opção	Disponível para	Campo de configuração relevante
Use uma política integrada	Todos os clientes gRPC	localityLbPolicy
Use uma política personalizada	Clientes Java que usam a versão 1.47 ou posterior do gRPC, numa malha que inclui apenas clientes gRPC	localityLbPolicies
Defina uma lista de políticas preferenciais	Clientes Java que usam a versão 1.47 ou posterior do gRPC, numa malha que inclui apenas clientes gRPC	localityLbPolicies

Pode usar qualquer combinação das opções anteriores. No entanto, se configurar localityLbPolicy e localityLbPolicies, o gRPC tenta primeiro usar a configuração localityLbPolicies.

Se não configurar o balanceamento de carga de localidade, o Cloud Service Mesh usa a política ROUND_ROBIN.

Para informações sobre a ROUND_ROBIN e outras políticas incorporadas, consulte a descrição da localityLbPolicy na página backendServices.

Use uma política integrada

Se quiser que todos os seus clientes usem uma única política incorporada, pode selecioná-la configurando o campo localityLbPolicy.

Quando configura este campo, pode escolher entre as seguintes políticas:

• LEAST_REQUEST (apenas clientes Java)
• RING_HASH
• ROUND_ROBIN

Se nem todos os seus clientes puderem usar a mesma política, consulte o artigo Defina uma lista de políticas preferenciais.

gcloud

1. Exporte o ficheiro de configuração do serviço de back-end com o comando gcloud compute backend-services export:grpcwallet-wallet-v2-service

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

2. Atualize o ficheiro bs_config.yaml exportado para incluir as seguintes linhas:

   localityLbPolicy:
    -- policy
       name: RING_HASH
   

3. Importe o ficheiro atualizado através do comando gcloud compute backend-services import:

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

Use uma política personalizada

Se for adequado, pode usar uma política de equilíbrio de carga personalizada que criou e implementou com o gRPC. Esta funcionalidade está disponível para clientes Java que usam o gRPC versão 1.47 ou posterior. Use-o apenas numa malha que inclua todos os clientes gRPC.

Ao criar uma política personalizada, a seguinte documentação pode ser útil:

• Para tornar a sua política personalizada mais sofisticada, pode usar as APIs de agregação de custos de pedidos abertos (ORCA). Estas APIs permitem-lhe captar métricas sobre o custo das consultas e a utilização do servidor. A utilização destas APIs requer a versão 1.48.1 ou posterior do gRPC. Para mais informações, consulte o artigo Exemplo de ORCA de gRPC.

• Para obter informações sobre como as configurações de equilíbrio de carga personalizadas são enviadas para o gRPC pelo xDS, consulte Configuração do equilibrador de carga personalizado do gRPC xDS.

Para configurar o Cloud Service Mesh para usar a sua política personalizada, identifique a política usando o campo localityLbPolicies.

Os passos seguintes demonstram este processo. Neste procedimento, atualiza a configuração do serviço de back-end para que os clientes que se ligam a ele usem uma política personalizada denominada example.ExampleLoadBalancer.grpcwallet-wallet-v2-service

Aviso: esta funcionalidade destina-se a utilização numa malha de serviços que inclua apenas clientes gRPC. Os proxies Envoy não podem usar serviços de back-end com esta configuração.

gcloud

1. Exporte o ficheiro de configuração do serviço de back-end com o comando gcloud compute backend-services export:grpcwallet-wallet-v2-service

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

2. Atualize o ficheiro bs_config.yaml exportado para fazer referência à política de example.ExampleLoadBalancer. Inclua as seguintes linhas:

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

3. Importe o ficheiro atualizado através do comando gcloud compute backend-services import:

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

4. Opcional: teste a configuração do balanceamento de carga:

   Java

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

   Se configurou corretamente a política de balanceamento de carga personalizada, vê a mensagem que incluiu na configuração ("Olá, mundo do balanceamento de carga!").

Defina uma lista de políticas preferenciais

Se tiver vários clientes que não suportam todos uma única política de equilíbrio de carga, crie uma lista de políticas que os seus clientes possam usar. Com esta opção, se não for possível usar a primeira política preferida por um cliente específico, o gRPC recorre à política seguinte na lista.

Quando cria uma lista de políticas preferenciais, as opções válidas incluem políticas personalizadas, ROUND_ROBIN e, para clientes Java, LEAST_REQUEST. Pode listar até 10 políticas.

Esta funcionalidade só está disponível para clientes Java que usam a versão 1.47 ou posterior do gRPC. Use-o apenas numa malha que inclua todos os clientes gRPC.

Aviso: esta funcionalidade destina-se a utilização numa malha de serviços que inclua apenas clientes gRPC. Os proxies Envoy não podem usar serviços de back-end com esta configuração.

gcloud

1. Exporte o ficheiro de configuração do serviço de back-end com o comando gcloud compute backend-services export:grpcwallet-wallet-v2-service

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

1. Atualize o ficheiro bs_config.yaml exportado para incluir o campo localityLbPolicies. Preencha-o com entradas que representam as seguintes políticas:

   • Uma política personalizada inválida (example.InvalidLoadBalancer)
   • Uma política personalizada válida (example.ExampleLoadBalancer)
   • Uma política integrada suportada (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. Importe o ficheiro atualizado através do comando gcloud compute backend-services import:

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

3. Opcional: teste a configuração do balanceamento de carga:

   Java

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

   Em resposta, o gRPC tenta e não consegue encontrar example.InvalidLoadBalancer. Posteriormente, volta a usar example.ExampleLoadBalancer e vê a mensagem que incluiu na configuração ("Olá, mundo do equilíbrio de carga!"). O registo gRPC no cliente inclui uma mensagem a indicar que não foi encontrado o elemento example.InvalidLoadBalancer.

Limpe os recursos

Para limpar os recursos, execute o seguinte comando a partir do seu sistema local:

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

Bloqueie o tráfego entre serviços

Se quiser bloquear o tráfego entre o Serviço A e o Serviço B, e a sua implementação estiver no GKE, configure a segurança do serviço e use uma política de autorização para bloquear o tráfego entre serviços. Para ver instruções completas, consulte o artigo Segurança do serviço Cloud Service Mesh e as instruções de configuração com o Envoy e o gRPC sem proxy.

O que se segue?

• Para ajudar a resolver problemas de configuração do Cloud Service Mesh, consulte o artigo Resolução de problemas de implementações que usam gRPC sem proxy.