Configure o gerenciamento de tráfego avançado com serviços gRPC sem proxy

Observação: este guia só oferece suporte ao Cloud Service Mesh com as APIs do Google Cloud e não oferece suporte às APIs do Istio. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Essa configuração tem suporte para clientes de pré-lançamento, mas não é recomendada para novos usuários do Cloud Service Mesh. Para mais informações, consulte a Visão geral do roteamento de serviços do Cloud Service Mesh.

Neste documento, você encontra instruções para configurar o Cloud Service Mesh com os seguintes recursos de gerenciamento de tráfego:

• Correspondência de rota
• Divisão de tráfego
• Disjuntores
• Injeção de falha
• Duração máxima do streaming
• Tentar novamente
• Afinidade da sessão
• Detecção de outlier
• Balanceamento de carga da região administrativa

Este documento se concentra na configuração do gerenciamento avançado de tráfego com gRPC sem proxy no Compute Engine, mas o gerenciamento avançado de tráfego também é compatível quando você usa o gRPC sem proxy no Google Kubernetes Engine (GKE).

Antes de começar

Antes de configurar o gerenciamento avançado de tráfego, consulte os requisitos em Preparar-se para configurar a Cloud Service Mesh com serviços do gRPC sem proxy. Só é possível configurar o gerenciamento de tráfego avançado se todos os requisitos forem atendidos.

Para informações conceituais sobre esses recursos, consulte Gerenciamento de tráfego avançado.

Sobre o exemplo do gRPC para Wallet

Para ilustrar esses recursos, implante um exemplo de gRPC do Wallet. Neste exemplo, há três serviços do gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats e grpc.examples.wallet.account.Account, que são implantados como três aplicativos separados.

Conforme mostrado no diagrama a seguir, você cria um cliente gRPC que chama o serviço Wallet para receber o saldo de uma conta e chama o serviço Stats para receber 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 receber informações do usuário.

Exemplo de configuração de roteamento de tráfego do Wallet para gRPC (clique para ampliar)

No exemplo, você implanta duas versões das implementações Wallet e Stats para ilustrar o roteamento de solicitações com base nas regras configuradas. Para simular a criação e a implantação de diferentes versões de um serviço, use sinalizações de servidor para alterar o comportamento dos binários criados apenas uma vez.

• A sinalização --port especifica a porta em que o serviço em uma instância de VM atende.
• A sinalização --hostname_suffix especifica um valor anexado ao nome do host da instância de VM que responde a uma solicitação. O valor resultante é adicionado como os metadados hostname na resposta. Isso ajuda a identificar qual instância em um grupo respondeu à solicitação do cliente.
• A sinalização --premium_only com o valor true especifica que se trata de uma versão premium do serviço stats.
• A sinalização --v1_behavior com o valor true especifica que o binário da carteira atua como uma versão v1.

A tabela a seguir mostra os valores dessas sinalizações para cada instância de VM que está executando um dos serviços do gRPC, o número de instâncias em um grupo de instâncias e os serviços de back-end a que esses grupos de instâncias pertencem.

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

Serviço de back-end	Grupo de instâncias	Instâncias	Sinalizações 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 implantar esses serviços, configure o Cloud Service Mesh para rotear solicitações de um cliente de teste para esses serviços de back-end, na tabela a seguir. O cliente se conecta ao nome do host virtual de um serviço, conforme mostrado na coluna Host.

Observação: o pseudo-cabeçalho :path HTTP/2 em uma solicitação gRPC tem o formato /ServiceName/MethodName, em que ServiceName é o nome do serviço gRPC que está sendo chamado na solicitação gRPC e MethodName é o método nesse serviço.

Host	Corresponder às regras	Ação de rota
wallet.grpcwallet.io	Prefixo do caminho: "/" Cabeçalho presente: "session_id"	Trajeto para wallet-v1-affinity
	Prefixo do caminho: "/" Cabeçalho: {"route": "timeout"}	Definir o tempo limite de cinco segundos e o caminho para wallet-v2
	Prefixo do caminho: "/" Cabeçalho: {"route": "fault"}	Falha em 50% de solicitações e roteia o restante para wallet-v2
	Prefixo do caminho: "/" Cabeçalho: {"membership": "premium"}	Trajeto para wallet-v1 e tentativa novamente até três vezes em caso de falha
	Caminho completo: /grpc.examples.wallet.Wallet/FetchBalance	Trajeto para: wallet-v1: 70% wallet-v2: 30%
	Padrão	Trajeto para wallet-v1
stats.grpcwallet.io	Prefixo do caminho: "/" Cabeçalho: {"membership": "premium"}	Trajeto para stats-premium
	Padrão	Trajeto para stats
account.grpcwallet.io	Prefixo do caminho: "/" Cabeçalho: {"route": "account-fault"}	Falha em 30% das solicitações e roteie o restante para account.
	Padrão	account

Este exemplo usa uma divisão de tráfego de 70/30 entre dois serviços existentes. Se você estiver dividindo o tráfego para um novo serviço que não foi referenciado pelo mapa de URL, primeiro adicione o novo serviço a weightedBackendServices e atribua um peso de 0 a ele. Em seguida, aumente gradualmente o peso atribuído a esse serviço.

O cliente de teste tem as seguintes opções que permitem gerar solicitações apropriadas para demonstrar os recursos de gerenciamento de tráfego.

Opção	Descrição
--watch=true	Chamar métodos de streaming para assistir saldo/preço
--unary_watch=true	Chamar métodos unários repetidamente para observar 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"}

Preparar o ambiente local

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

1. Atualize o binário gcloud para garantir que você tenha a versão mais recente:

   gcloud components update
   

2. Faça o download do 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
   

Criar e configurar instâncias do Cloud Router

Nesta seção, você cria instâncias do Cloud Router em cada região e as configura para o Cloud NAT. As VMs criadas por este exemplo não têm endereços IP externos, mas precisam 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 roteadores 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
   

Criar a verificação de integridade e a regra de firewall do gRPC

Nesta seção, você cria uma verificação de integridade e uma regra de firewall do gRPC que permite que as solicitações de verificação de integridade do gRPC alcancem sua rede. Posteriormente, a verificação de integridade do gRPC será associada a serviços de back-end para que ela possa verificar a integridade das instâncias de back-end desses serviços.

gcloud

1. Crie a verificação de integridade:

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

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

   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
   

Criar o modelo da instância

Nesta seção, você cria um modelo de instância para implantar o serviço gRPC account que é exposto na porta 50053.

gcloud

• Crie o modelo da 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")
  

Criar o grupo gerenciado de instâncias

Os grupos de instâncias gerenciadas (MIGs, na sigla em inglês) usam o escalonamento automático para criar novas instâncias de VM, conforme necessário. Nesta seção, você cria um MIG usando o modelo de instância criado na seçã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
  

Configurar a porta nomeada

Nesta seção, você configura a porta nomeada do serviço gRPC. A porta nomeada é aquela em que o serviço gRPC detecta solicitações. Neste exemplo, a porta nomeada é a porta 50053.

gcloud

• Crie a porta nomeada:

  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 seção, você cria um serviço de back-end global com o esquema de balanceamento de carga de INTERNAL_SELF_MANAGED e o protocolo GRPC. Em seguida, associe a verificação de integridade e o grupo de instâncias ao serviço de back-end. Neste exemplo, use o MIG criado em Criar o grupo de instâncias gerenciadas. Esse MIG executa o serviço gRPC account. A porta na sinalização --port-name é a porta nomeada que você criou em Configurar a porta nomeada.

gcloud

1. Crie o serviço de back-end e associe a verificação de integridade a esse novo serviço.

   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 gerenciado de instâncias 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
   

As etapas para criar os serviços de back-end restantes usados no exemplo do Wallet para gRPC são semelhantes às etapas anteriores. Execute um script de shell para criar os serviços restantes. O script implanta 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"'

Criar as regras de roteamento

Nesta seção, você cria um mapa de URL que é usado para demonstrar vários recursos de gerenciamento de tráfego. O mapa de URL especifica os nomes do host virtuais dos serviços neste exemplo e as regras de roteamento associadas. Para saber mais, consulte Como rotear mapas de regras.

No mapa de URL, hostRules especifica os nomes de host virtuais dos serviços no exemplo. Esses são os nomes que um cliente usa no URI de canal para se conectar a um serviço específico. Por exemplo, para enviar uma solicitação ao serviço account, um cliente usa xds:///account.grpcwallet.io no URI do canal. Em 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 roteamento desse host virtual. Uma configuração pathMatcher consiste em regras correspondentes e regras de ação correspondentes, conforme descrito em Sobre o exemplo da carteira do gRPC.

gcloud

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

Criar o proxy de destino e a regra de encaminhamento

Nesta seção, você criará o proxy gRPC de destino e uma regra de encaminhamento.

O proxy gRPC de destino faz referência ao mapa de URL que você criou na etapa anterior. A flag --validate-for-proxyless ativa verificações de configuração para que você não ativar acidentalmente um recurso que não é compatível com gRPC sem proxy. implantações.

gcloud

• Crie o proxy de destino do gRPC:

  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 criado. O esquema de balanceamento de carga é definido como INTERNAL_SELF_MANAGED para indicar que essa regra de encaminhamento é usada pelo Cloud Service Mesh. Ela precisa ser uma regra de encaminhamento global. O endereço IP é definido como 0.0.0.0 porque um cliente gRPC sem proxy resolve o hostname:port no URI de destino ao enviar uma solicitação de LDS à malha de serviço do Cloud em vez de fazer uma pesquisa DNS. Para mais informações, consulte Esquema de resolução de nomes.

Quando uma porta não é especificada no URI de destino, o valor padrão é 80. Por exemplo, um URI de destino xds:///foo.myservice:8080 corresponde a uma regra de encaminhamento configurada com a porta 8080. Neste exemplo, a regra de encaminhamento é 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
  

Verificar a configuração

Quando o processo de configuração for concluído, verifique se os serviços de back-end que você configurou estão disponíveis marcando o Página do Cloud Service Mesh no console do Google Cloud. Confirme se os serviços de back-end e os back-ends associados são informados como em bom estado. Isso pode levar algum tempo.

Verificar a configuração de roteamento

Nesta seção, você verifica se a configuração de roteamento está funcionando corretamente. Use a ferramenta grpcurl para testar a configuração.

gcloud

1. Crie uma VM cliente em que você executará os clientes para testar o serviço. Também é possível incluir a sinalização --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. Acesse a VM usando SSH e execute os seguintes comandos para prepará-la:

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

3. Execute os comandos a seguir:

   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 acessar os serviços sem um proxy sidecar, o cliente gRPC precisa usar o esquema de resolução de nomes xds. Esse esquema instrui a biblioteca gRPC usada no cliente a usar um servidor xDS para resolver o nome do host. Para isso, é necessária uma configuração de inicialização.

O script de inicialização na seção anterior define a variável de ambiente GRPC_XDS_BOOTSTRAP e usa um script auxiliar para gerar o arquivo de inicialização. Os valores de TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME e da zona no arquivo de inicialização gerado são recebidos do servidor de metadados que conhece esses detalhes das instâncias de VM do Compute Engine. É possível fornecer esses valores para o script auxiliar manualmente usando as opções -gcp-project-number e -vpc-network-name.

Observação: de acordo com a política, recomendamos que os usuários verifiquem se há atualizações do gerador de bootstrap do gRPC TD anualmente.

Verificar a configuração usando a ferramenta grpcurl

Execute os seguintes comandos no shell SSH para verificar se os serviços wallet-service, stats-service e account-service estão sendo executados.

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

Você verá os seguintes resultados:

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

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

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Verificar com clientes do grpc-wallet

Use as seguintes instruções específicas da linguagem para verificar a configuração. Os comandos enviam várias RPCs, algumas com metadados extras, para mostrar que as solicitações são roteadas para serviços de back-end com base nas regras correspondentes do mapa de URL. O comando também imprime o nome do host da instância de VM para cada resposta para mostrar para qual instância de VM a solicitação foi roteada.

Java

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

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

2. Execute os comandos a seguir:

   cd ~/traffic-director-grpc-examples/java
   ./gradlew installDist
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests are
   # sent to 'wallet-v2'.
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium and Bob's go to regular.
   ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
   ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
   

Go

1. Para verificar o serviço com um cliente gRPC Go, 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 comandos a seguir:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   go build
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests
   # are sent to 'wallet-v2'.
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium and Bob's go to regular.
   ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Bob
   ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Alice
   

C++

1. Para verificar o serviço com um cliente gRPC em C++, execute o seguinte:

   sudo apt-get install -y build-essential
   

2. Execute os comandos a seguir:

   cd ~/traffic-director-grpc-examples/cpp
   ../tools/bazel build :client
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance'  from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests are sent to 'wallet-v2'.
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium, and Bob's go to regular.
   ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
   ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
   

Configurar opções mais avançadas

É possível configurar outras opções de roteamento avançado de tráfego seguindo as instruções nas seções a seguir.

Disjuntores

A quebra de circuito permite definir limites de falha para impedir que as solicitações do cliente sobrecarreguem os serviços back-ends. Depois que o número de solicitações pendentes atingir um limite definido, o cliente deixará de enviar solicitações adicionais, dando aos serviços de back-end tempo para se recuperar.

A quebra de circuito evita falhas em cascata retornando um erro ao cliente em vez de sobrecarregar um serviço de back-end. Isso permite que pouco tráfego seja vinculado enquanto fornece tempo para gerenciar a situação de sobrecarga, como lidar com um pico de tráfego aumentando a capacidade com escalonamento automático.

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

circuitBreakers:
  maxRequests: 1

Essa configuração limita os clientes a uma solicitação pendente para stats-service por vez. Como há apenas um serviço wallet-v2, a execução de duas operações WatchBalancesimultâneas do cliente do Wallet exibe falhas da segunda instância.

Java

1. Execute os comandos a seguir:

   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. A saída será assim:

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

Go

1. Execute os comandos a seguir:

   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. A saída será assim:

   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 comandos a seguir:

   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. A saída será assim:

   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 falha

A injeção de falhas inserve erros ao atender ao veicular solicitações para simular falhas, incluindo alta latência, sobrecarga, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas.

Ao criar o mapa de URL anteriormente, você define a política de injeção de falha para falhar 50% das RPCs enviadas para wallet.grpcwallet.io com o cabeçalho route=fault.

Para demonstrar a injeção de falhas, use o código nas linguagens a seguir.

Java

1. Execute os comandos a seguir:

   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. A saída será assim:

   server host: grpcwallet-wallet-v2-mig-us-central1-zznc
   total balance: 10340491
   - address: 148de9c5, balance: 2549839
   - address: 2e7d2c03, balance: 7790652
   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=UNAVAILABLE, description=RPC terminated due to fault injection: HTTP status code 503, cause=null}
   

Go

1. Execute os comandos a seguir:

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

2. A saída será assim:

    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 comandos a seguir:

   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. A saída será assim:

   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 streaming

A duração máxima do streaming permite que um tempo limite máximo seja aplicado a todas as RPCs. Isso evita que os clientes que se esquecem de definir um prazo ou que definam um prazo excessivo, desperdiçando recursos do servidor.

Ao criar o mapa de URL anteriormente, você definiu uma duração máxima de streaming de cinco segundos para RPCs enviado ao wallet.grpcwallet.io com o cabeçalho route=timeout.

Para demonstrar os tempos limite, primeiro interrompemos 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 comando a seguir fica travado permanentemente, porque não há serviço de back-end para processá-lo e o aplicativo não define um prazo.

Java

1. Execute os comandos a seguir:

   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 para de responder. Pressione ^C para interromper o comando.

Go

1. Execute os comandos a seguir:

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

2. O comando para de responder. Pressione ^C para interromper o comando.

C++

1. Execute os comandos a seguir:

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

2. O comando para de responder. Pressione ^C para interromper o comando.

No entanto, o comando a seguir que usa a rota timeout falha após cinco segundos devido à configuração maxStreamDuration.

Java

1. Execute este 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. A saída será assim:

   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=DEADLINE_EXCEEDED, description=deadline exceeded after 4.999594070s.         [wait_for_ready, buffered_nanos=5000553401, waiting_for_connection], cause=null}
   

Go

1. Execute este comando:

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

2. A saída será assim:

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

C++

1. Execute este 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. A saída será assim:

   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 seus aplicativos gRPC repitam solicitações de saída de acordo com uma política de repetição. Em uma política de nova tentativa, é possível configurar as condições sob as quais uma solicitação com falha precisa ser repetida e o número máximo de tentativas. Por exemplo, quando uma solicitação falha com um código de resposta específico.

Ao criar o mapa de URLs anteriormente, você define uma política de repetição de RPCs para o método FetchBalance com o cabeçalho membership=premium. Esta política repete as RPCs que falham com o código de status unavailable até um máximo de três vezes. Você também define uma política de injeção de falhas para RPCs como account.grpcwallet.io com o cabeçalho route=account-fault que falha 30% dos RPCs do serviço Wallet para o Account serviço. Como resultado, 30% das RPCs do cliente de teste com cabeçalho membership=normal falham, enquanto a taxa de falha das RPCs com cabeçalho membership=premium é inferior a 1%.

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

Java

Execute os comandos a seguir:

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

Execute os comandos a seguir:

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 comandos a seguir:

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 da sessão

A afinidade de sessão oferece uma tentativa de melhor esforço de enviar solicitações com características específicas (cabeçalhos HTTP) para a mesma instância, desde que ela esteja íntegra e tenha capacidade. Isso é útil para servidores de aplicativos com estado que se beneficiam de melhoria no desempenho e eficiência quando solicitações de um determinado cliente são enviadas para a mesma instância, e não como uma distribuição de round-robin para instâncias diferentes.

Observação: um cliente gRPC incompatível com a política de balanceamento de carga RING_HASH confirme de forma negativa a configuração do Cloud Service Mesh quando um O mapa de URLs referencia um serviço de back-end com localityLbPolicy=RING_HASH. Isso fará com que o canal cliente entre em um estado de erro temporário até que a configuração seja corrigida. Consulte Limitação do serviço de back-end para ver mais detalhes.

Quando você 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, você aplicará a seguinte configuração para alterar localityLbPolicy para RING_HASH.

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

gcloud

1. Salve 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}"
   

Observação: a atualização do serviço de back-end pode levar vários minutos para ser propagada nos clientes.

Para demonstrar a afinidade da sessão, use o código nos seguintes idiomas. Com a sinalização --affinity=true, o cliente insere um cabeçalho session-id com um valor exclusivo para cada usuário. Um hash desse valor é usado para enviar a solicitação 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 comandos a seguir:

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

Execute os comandos a seguir:

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 comandos a seguir:

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

Detecção de outlier

Para melhorar a disponibilidade do serviço, configure a detecção de outliers. Esse recurso permite identificar e expulsar temporariamente hosts não íntegros do pool de balanceamento de carga. Esses hosts não íntegros são chamados de outliers.

O gRPC avalia os hosts com base na taxa de sucesso, ou seja, a frequência com que um host processa as solicitações. A taxa é afetada por falhas, como erros de gRPC, erros de HTTP, tempo limite e outros problemas.

Ao configurar a detecção de outliers usando o Cloud Service Mesh, você pode ajustar a forma como o gRPC avalia os hosts e como ele lida com outliers. Por exemplo, é possível especificar critérios como estes:

• O número de solicitações que um host precisa receber antes que o gRPC analise um possível status de outlier.

• O quanto um host pode desviar da taxa de sucesso média antes de ser considerado um outlier.

• A porcentagem máxima de hosts que podem ser expulsos a qualquer momento do pool de balanceamento de carga.

• O valor de tempo durante o qual um outlier foi excluído do pool de balanceamento de carga.

Saiba mais sobre os parâmetros disponíveis na referência REST Resource: backendServices. No entanto, há algumas limitações para o gRPC, conforme descrito na próxima seção.

Limitações

Os seguintes campos não são aceitos por clientes gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Configurar a detecção de outliers

O procedimento a seguir mostra como configurar a detecção de outliers para um serviço que usa um grupo de instâncias como back-end. Este procedimento define a seguinte configuração:

• A análise de detecção de outliers é executada a cada segundo. Para configurar esse comportamento, use o campo interval.
• Os outliers são expulsos do pool de balanceamento de carga em incrementos de 30 segundos da seguinte maneira:
  • Se for a primeira vez, o host fica expulso por apenas 30 segundos.
  • Se um host tiver sido expulso anteriormente, o tempo aumentará em 30 segundos para cada expulsão anterior. Por exemplo, na terceira vez, o host fica expulso por 90 segundos. Para configurar esse comportamento, use o campo baseEjectionTime.
• Um host é considerado não íntegro se a taxa de sucesso for um desvio padrão abaixo da média durante o intervalo de tempo selecionado (neste caso, 1 segundo). Use o campo successRateStdevFactor para configurar o desvio padrão máximo.

Para configurar a detecção de outliers dessa maneira, use as etapas a seguir.

gcloud

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

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

2. No arquivo bs_config.yaml, atualize a configuração grpcwallet-wallet-v2-service para incluir os campos de detecção outliers:

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

3. Importe o arquivo atualizado usando o comando gcloud compute backend-services import:

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

Observação: o exemplo da Carteira não foi planejado para incluir hosts não íntegros. Por isso, os hosts grpcwallet-wallet-v2-service não costumam ser removidos, mesmo que você configure a detecção de outliers corretamente.

Balanceamento de carga da região administrativa

Para usar seus recursos da maneira mais eficiente, configure o balanceamento de carga da região administrativa. Esse recurso ajuda a economizar recursos distribuindo uniformemente as solicitações de clientes nos back-ends.

Ao configurar o balanceamento de carga de localidade, é possível usar as opções descritas na tabela a seguir. Todas as opções exigem que você configure o recurso backendServices.

Opção	Disponível para	Campo de configuração relevante
Usar uma política integrada	Todos os clientes gRPC	localityLbPolicy
Usar uma política personalizada	Clientes Java que usam gRPC versão 1.47 ou posterior, em uma malha que inclui apenas clientes gRPC	localityLbPolicies
Definir uma lista de políticas preferidas	Clientes Java que usam gRPC versão 1.47 ou posterior, em uma malha que inclui apenas clientes gRPC	localityLbPolicies

É possível usar qualquer combinação das opções anteriores. No entanto, se você configurar localityLbPolicy e localityLbPolicies, o gRPC primeiro tentará usar a configuração localityLbPolicies.

Se você não configurar o balanceamento de carga de localidade, o Cloud Service Mesh vai usar a política ROUND_ROBIN.

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

Usar uma política integrada

Se você quiser que todos os clientes usem uma única política integrada, selecione-a configurando o campo localityLbPolicy.

Ao configurar esse campo, é possível escolher entre as seguintes políticas:

• LEAST_REQUEST (somente clientes Java)
• RING_HASH
• ROUND_ROBIN

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

gcloud

1. Exportar a configuração do serviço de back-end grpcwallet-wallet-v2-service arquivo usando gcloud compute backend-services export comando:

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

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

   localityLbPolicy:
    -- policy
       name: RING_HASH
   

3. Importe o arquivo atualizado usando gcloud compute backend-services import. comando:

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

Usar uma política personalizada

Se apropriado, é possível usar uma política de balanceamento de carga personalizada que você criou e implantou com o gRPC. Esse recurso está disponível para clientes Java que usam o gRPC versão 1.47 ou posterior. Use-o apenas em uma malha que inclua todos os clientes gRPC.

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

• Para tornar sua política personalizada mais sofisticada, use as APIs de agregação de custo de solicitação aberta (ORCA, na sigla em inglês). Essas APIs permitem capturar métricas sobre o custo de consulta e a utilização do servidor. O uso dessas APIs requer a versão 1.48.1 ou posterior do gRPC. Para mais informações, consulte Exemplo de ORCA do gRPC.

• Para informações sobre como as configurações de balanceamento de carga personalizado são entregues ao gRPC pelo xDS, consulte Configuração do balanceador de carga personalizado gRPC xDS.

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

As etapas a seguir demonstram esse processo. Neste procedimento, atualize a configuração do serviço de back-end grpcwallet-wallet-v2-service para que os clientes se conectem a ele usem uma política personalizada chamada example.ExampleLoadBalancer.

Cuidado: esse recurso é destinado a uso em uma malha de serviço que inclui apenas clientes gRPC. Os proxies do Envoy não podem usar serviços de back-end que tenham essa configuração.

gcloud

1. Exportar a configuração do serviço de back-end grpcwallet-wallet-v2-service arquivo usando gcloud compute backend-services export comando:

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

2. Atualize o arquivo bs_config.yaml exportado para fazer referência à política example.ExampleLoadBalancer. Inclua as linhas a seguir:

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

3. Importe o arquivo atualizado usando gcloud compute backend-services import. comando:

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

4. Opcional: teste a configuração de 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 você tiver configurado a política de balanceamento de carga personalizada corretamente, a mensagem incluída na configuração ("Olá, mundo de balanceamento de carga!") será exibida.

Definir uma lista de políticas preferidas

Se você tiver vários clientes que não sejam todos compatíveis com uma única política de balanceamento de carga, crie uma lista de políticas que seus clientes podem usar. Com essa opção, se a primeira política preferencial não puder ser usada por um cliente específico, o gRPC recorrerá à próxima política da lista.

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

Esse recurso está disponível apenas para clientes Java que usam o gRPC versão 1.47 ou posterior. Use-o apenas em uma malha que inclua todos os clientes gRPC.

Cuidado: esse recurso é destinado a uso em uma malha de serviço que inclui apenas clientes gRPC. Os proxies do Envoy não podem usar serviços de back-end que tenham essa configuração.

gcloud

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

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

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

   • Uma política personalizada inválida (example.InvalidLoadBalancer)
   • Uma política personalizada válida (example.ExampleLoadBalancer)
   • Uma política integrada compatível (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 arquivo atualizado usando gcloud compute backend-services import. comando:

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

3. Opcional: teste a configuração de 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. Depois, ele voltará a usar example.ExampleLoadBalancer, e você verá a mensagem incluída na configuração ("Olá, balanceamento de carga!"). A geração de registros do gRPC no cliente inclui uma mensagem informando que example.InvalidLoadBalancer não foi encontrado.

Limpe os recursos

Para limpar os recursos, execute o seguinte comando no sistema local:

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

Bloquear tráfego entre os serviços

Caso você queira bloquear o tráfego entre os Serviços A e B, e a implantaçã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 eles. Para instruções completas, consulte Segurança do serviço do Cloud Service Mesh e as instruções de configuração com o Envoy e o gRPC sem proxy.

A seguir

• Para ajudar você a resolver problemas de configuração do Cloud Service Mesh, consulte Solução de problemas em implantações que usam gRPC sem proxy.