Como as solicitações são encaminhadas

Esta página descreve como as solicitações HTTP dos usuários chegam à versão apropriada de um serviço. As solicitações podem ser roteadas das seguintes maneiras:

• Roteamento com URLs

• Roteamento com um arquivo de expedição

• Roteamento com o Cloud Load Balancing

Se você testar o aplicativo no servidor de desenvolvimento local, os recursos disponíveis de roteamento e expedição serão ligeiramente diferentes. Para criar de maneira programática URLs que funcionem com servidores de produção e desenvolvimento, use o método ModulesService.getVersionHostname.

Consulte Roteamento no servidor de desenvolvimento para saber mais.

Roteamento com URLs

Quando seu aplicativo estiver em execução no App Engine, use o seguinte URL para enviar solicitações HTTP ao aplicativo:
https://PROJECT_ID.REGION_ID.r.appspot.com

em que PROJECT_ID é o ID do projeto do Google Cloud que contém o aplicativo.

Esse URL envia solicitações para o serviço padrão do aplicativo na versão configurada para receber tráfego.

URLs para serviços e versões

Se você criar mais de um serviço no aplicativo, cada serviço terá seu próprio URL. Cada versão de um serviço também tem um URL próprio para que seja possível implantar e testar uma versão nova antes de configurá-la para receber o tráfego.

Os URLs de serviços e versões específicos estão no seguinte formato:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

É possível omitir VERSION-dot- se não for necessário visar uma versão específica.

Para recuperar os IDs dos serviços e versões do app, é possível usar qualquer uma das seguintes ferramentas:

Exemplos de URL

Veja alguns exemplos de URLs do App Engine que mostram o domínio appspot.com que o App Engine atribui ao app e um domínio personalizado, que é possível configurar para o app.

• Envia a solicitação para uma instância disponível do serviço default:

  
  https://PROJECT_ID.REGION_ID.r.appspot.com
  https://CUSTOM_DOMAIN

  As solicitações são recebidas por qualquer versão configurada para tráfego no serviço default.

• Envia uma solicitação para uma instância disponível de um serviço específico:

  
  https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://SERVICE_ID.CUSTOM_DOMAIN

  As solicitações são recebidas por qualquer versão configurada para o recebimento do tráfego no serviço de destino. Se o serviço de destino não existir, a solicitação será encaminhada probabilisticamente.

• Envia uma solicitação para uma instância disponível de uma versão específica no

  serviço default:

  
  https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://VERSION_ID.CUSTOM_DOMAIN

  Quando um serviço não é direcionado, as solicitações são enviadas para o serviço default.

Roteamento probabilístico

Se uma solicitação corresponder à parte PROJECT_ID.REGION_ID.r.appspot.com do nome do host, mas incluir um serviço, uma versão ou um nome de instância que não existe, a solicitação será roteada para o serviço default. O roteamento probabilístico não se aplica a domínios personalizados. As solicitações feitas a eles retornarão um código de status HTTP 404 se o nome do host for inválido.

Roteamento direcionado

Os padrões de URL a seguir têm a garantia de que chegarão ao destino, se ele existir. Essas solicitações nunca são interceptadas e reencaminhadas pelos padrões definidos no arquivo de expedição:

• Envia a solicitação para uma instância disponível de um serviço e versão específicos:

  
  https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

• Se você usa serviços dimensionados manualmente, será possível direcionar e enviar uma solicitação a uma instância ao incluir o ID da instância. Esse ID é um número inteiro no intervalo de 0 até o número total de instâncias em execução e pode ser especificado da maneira a seguir:

  Envia uma solicitação para um serviço e versão específicos em uma instância determinada:

  https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN

Roteamento com um arquivo de expedição

É possível criar um arquivo de expedição para modificar as regras de roteamento baseadas em URL do App Engine e definir suas próprias regras de roteamento personalizadas. Com um arquivo de expedição, é possível enviar solicitações a serem recebidas por um serviço específico com base no caminho ou nome do host no URL da solicitação.

Como criar um arquivo de expedição

Para criar um arquivo de expedição:

1. Crie um arquivo chamado dispatch.yaml no mesmo diretório usado para os outros arquivos de configuração, como app.yaml.

2. Defina regras de roteamento no arquivo conforme descrito na referência dispatch.yaml.

Observe o seguinte sobre as regras de roteamento:

• É possível definir até 20 regras de roteamento. Cada regra precisa conter os elementos url e service.
• As regras precisam usar padrões do URL de HTTP que incluam a notação "." para separar subdomínios. URLs definidos com a notação "-dot-" do HTTPS não são compatíveis.
• As regras também se aplicam aos URLs definidos no arquivo cron.

Por exemplo, é possível criar um arquivo de expedição para rotear solicitações de dispositivos móveis como https://simple-sample.uc.r.appspot.com/mobile/ para um front-end móvel e rotear solicitações de worker como https://simple-sample.uc.r.appspot.com/work/ para um back-end estático:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

Como implantar o arquivo de expedição

gcloud app deploy dispatch.yaml

mvn appengine:deployDispatch dispatch.yaml

gradle appengineDeployDispatch dispatch.yaml

Roteamento com o Cloud Load Balancing

O Cloud Load Balancing é um produto separado que permite configurações avançadas de rede para todos os seus aplicativos em execução no Google Cloud.

Quando o balanceamento de carga HTTP(S) está ativado para aplicativos sem servidor, é possível:

• Configurar seu aplicativo sem servidor para ser exibido a partir de um endereço IP IPv4 e/ou IPv dedicado que não seja compartilhado com outros serviços.

• Reutilizar os mesmos certificados SSL e as chaves privadas que você usa para o Compute Engine, o Google Kubernetes Engine e o Cloud Storage. Isso elimina a necessidade de gerenciar certificados separados para aplicativos sem servidor.

O balanceador de carga não interfere nem interage com as regras de roteamento no arquivo dispatch.yaml. As regras dispatch.yaml não são avaliadas até que um NEG sem servidor direcione o tráfego para o App Engine.

Observe o seguinte:

• Recomendamos usar controles de entrada para que o aplicativo receba apenas solicitações enviadas do balanceador de carga (e da VPC, se você usá-la). Caso contrário, os usuários poderão usar o URL do App Engine do aplicativo para ignorar o balanceador de carga, as políticas de segurança do Google Cloud Armor, os certificados SSL e as chaves privadas transmitidas pelo balanceador de carga.

Roteamento no servidor de desenvolvimento

Descobrir endereços de instâncias

O servidor de desenvolvimento local cria todas as instâncias na inicialização. Observe que, neste momento, as instâncias básicas de escalonamento não são compatíveis com o servidor de desenvolvimento local. Uma porta é atribuída a cada instância criada. As atribuições de portas aparecem no stream de mensagens de registro do servidor. Os clientes Web podem se comunicar com uma instância específica ao apontar a porta da instância. Apenas uma instância (e porta) é criada para serviços com escalonamento automático. É assim que aparece no registro do servidor. Observe que os serviços eram previamente chamados de módulos:

INFO: Module instance service-auto is running at http://localhost:37251/

Uma porta única é atribuída a cada instância de um serviço escalonado manualmente:

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

Além disso, cada serviço escalonado manualmente recebe uma porta adicional para que os clientes possam acessar o serviço sem especificar uma instância específica. As solicitações para essa porta são encaminhadas automaticamente para uma das instâncias configuradas:

INFO: Module instance service-manual is running at http://localhost:12361/

A tabela a seguir mostra como esses serviços podem ser chamados no servidor de desenvolvimento e no ambiente do App Engine:

é usado pelo servidor de desenvolvimento local. Para detalhes, consulte Apache Maven ou Gradle.

Arquivos de despacho

Restringir o acesso a um serviço

Todos os serviços são públicos por padrão. Se você quiser restringir o acesso a um serviço, adicione o elemento <role-name>admin</role-name> à restrição de segurança.

Detalhes adicionais sobre URLs do App Engine

Noções básicas sobre o ID da região em URLs

O REGION_ID é um código abreviado que o Google atribui com base na região que você selecionou ao criar o aplicativo. O código não corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes aos códigos de país e estado geralmente usados. Para apps criados após fevereiro de 2020, o REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criados antes dessa data, o ID da região é opcional no URL.

Use as seguintes ferramentas para ver o ID de região do seu aplicativo:

O nome de domínio está incluído nos dados da solicitação

O nome de domínio usado para a solicitação está incluído nos dados da solicitação que são passados para seu aplicativo. Portanto, é possível usar os dados da solicitação para controlar como o aplicativo responde com base no nome de domínio na solicitação. Por exemplo, se você quiser redirecionar para um domínio oficial, codifique o aplicativo para que verifique o cabeçalho da solicitação Host e responda de acordo com o nome de domínio.