Visão geral da arquitetura do Cloud Endpoints

O Endpoints é um sistema de gerenciamento de APIs distribuído que abrange serviços, ambientes de execução e ferramentas. Ele fornece gerenciamento, monitoramento e autenticação.

Os componentes que formam o Endpoints são:

  • Extensible Service Proxy (ESP) ou Extensible Service Proxy V2 Beta (ESPv2 Beta) para introduzir a funcionalidade do Endpoints.

  • Service Control: para aplicar regras de gerenciamento de APIs;

  • Service Management: para configurar regras de gerenciamento de APIs;

  • SDK do Cloud: para implantação e gerenciamento;

  • Console do Google Cloud: para criação de registros, monitoramento e compartilhamento.

Arquitetura do Endpoints

Arquitetura do Endpoints

Componentes do Endpoints

ESP

O ESP é um proxy baseado em NGINX executado na frente do back-end. Ele injeta as funcionalidades do Endpoints como autenticação, monitoramento e geração de registros. O ESP recupera uma configuração de serviço do Service Management e a usa para validar solicitações recebidas.

O ESP foi projetado para ser implantado em um ambiente em contêiner e para validar os JWTs e os tokens de ID do Google. Ele emprega várias técnicas como armazenamento pesado em cache e chamadas assíncronas para manter sua leveza e alto desempenho.

O suporte ao ESP está disponível nas seguintes plataformas:

ESPv2 Beta

O ESPv2 Beta é um proxy escalonável de alto desempenho baseado no Envoy (em inglês) que é executado em um back-end de OpenAPI ou gRPC. O Endpoints no ESPv2 Beta é compatível com a versão 2 das especificações OpenAPI e especificações gRPC.

O ESPv2 Beta se integra à infraestrutura de serviços do Google para permitir recursos de gerenciamento de API em escala, incluindo autenticação, relatórios de telemetria, métricas e segurança.

O suporte ao ESPv2 Beta está disponível nas seguintes plataformas:

Service Control

Com o Service Control, você aplica regras de gerenciamento de APIs no ambiente de execução como autenticação de chave, monitoramento e geração de registros. Ele fornece os seguintes métodos:

  • Verificação: confere as chaves de autenticação e de API e indica se uma chamada é permitida.

  • Relatório: notifica os sistemas de registro para geração de registros e monitoramento.

Service Management

Descreva o funcionamento do serviço do gRPC em um arquivo YAML chamado de configuração do Endpoints. Implemente a configuração do Endpoints e seus arquivos .proto compilados no Service Management usando o SDK do Cloud, que configura as regras de gerenciamento da API. No Service Management, você também realiza outras tarefas relacionadas à configuração. Por exemplo, compartilhar a API com outros desenvolvedores, ativá-la ou desativá-la em diferentes projetos e gerar chaves de API.

SDK do Cloud

O SDK do Cloud fornece a ferramenta de linha de comando gcloud que pode ser usada para fazer chamadas para diversos serviços do Google Cloud. Use a ferramenta de linha de comando gcloud para implantar a configuração do Endpoints no Service Management.

Google Cloud Console

O Console do Cloud é a interface gráfica do usuário para Google Cloud. O Endpoints usa o Console do Cloud para exibir dados de monitoramento e registro enviados do ESP ou do ESPv2 Beta e registrados pelo Service Control, para compartilhar APIs com outros desenvolvedores e para a geração de chaves de API a fim de chamar o API.

Cenários de implantação

As opções para implantação variam de acordo com o uso de ESP ou ESPv2 Beta como o proxy do Endpoints. O ESPv2 Beta pode ser implantado como um proxy remoto e o ESPv2 Beta e o ESP podem ser implantados no modo secundário, conforme explicado nas seções a seguir.

Modo de proxy remoto

Se estiver usando o ESPv2 Beta, o Endpoints poderá ser implantado como um proxy remoto. Esse modo é usado para oferecer suporte a aplicativos executados em plataformas sem servidor, como o Cloud Run, o Cloud Functions e o App Engine em ambientes padrão.

Neste modo, o ESPv2 Beta é implantado como um aplicativo Cloud Run. O aplicativo está configurado para usar o ESPv2 Beta como um back-end remoto usando o campo x-google-backend na configuração do serviço da OpenAPI. Ao trabalhar como proxy remoto nesse modo de implantação, um único ESPv2 Beta pode aceitar vários back-ends remotos.

Para saber mais detalhes, consulte Como configurar o Endpoints.

Modo de arquivo secundário

Tanto o ESP quanto o ESPv2 Beta são compatíveis com a implantação em um contêiner com cada instância do back-end. Essa topologia de servidor local é perfeita para as APIs da Web e também para microsserviços. Ela evita o salto de rede normalmente associado a proxies centralizados, além de possibilitar o gerenciamento de APIs com alto desempenho e escalonabilidade.

Normalmente, o balanceamento de carga é aplicado antes do tráfego atingir o ESP ou o ESPv2 Beta. No Compute Engine, ele é realizado pelo Cloud Load Balancing. Nas implantações do Kubernetes, é possível usar um proxy de entrada no balanceamento de carga. Já no Google Kubernetes Engine, use o Cloud Load Balancing ou um proxy de entrada.

Na inicialização, o ESP ou o ESPv2 Beta extrai a configuração do serviço do Service Management. Ela é gerada a partir da especificação OpenAPI ou do gRPC, o arquivo YAML de configuração de serviço. Ele informa ao ESP ou ao ESPv2 Beta sobre a superfície da API a ser gerenciada com as políticas. Por exemplo, quais métodos exigem autenticação e quais exigem chaves de API.

Roteamento de solicitações

Quando uma solicitação é recebida, o ESP ou o ESPv2 Beta cria um token de rastreamento para o Cloud Trace.

Em seguida, o ESP ou o ESPv2 Beta correspondem ao caminho das solicitações recebidas com a superfície da API. Depois de encontrar uma rota correspondente, o ESP ou o ESPv2 Beta executam quaisquer etapas de autenticação para o método especificado.

Se for necessária a validação do JWT, o ESP ou ESPv2 Beta valida a autenticação usando a chave pública apropriada do signatário e valida o campo de público no JWT. Se uma chave de API for necessária, o ESP ou o ESPv2 Beta chamará a API Service Control para validar a chave.

O Service Control procura a chave para validá-la e garante que o projeto associado a ela tenha ativado a API. Se a chave for inválida ou o projeto não tiver ativado a API, a chamada será recusada e registrada por meio da API Service Control.

Se o Service Control validar a chave, a solicitação será encaminhada para o back-end com todos os cabeçalhos originais e o de validação do JWT, se apropriado.

Quando uma resposta é recebida do back-end, o ESP ou o ESPv2 Beta retornam a resposta ao autor da chamada e envia as informações de tempo finais para o Trace. Os pontos de chamada são registrados pela API Service Control, que grava métricas e as registra nos destinos apropriados.

ESP ou ESPv2 Beta no Kubernetes

No diagrama a seguir, veja a arquitetura geral em que o ESP é executado como um contêiner auxiliar do contêiner de aplicativos de serviço da API, com a API my-api hospedada em my-api.com e baseada em um serviço Kubernetes (em inglês). A arquitetura seria a mesma para uma implantação secundária com o ESPv2 Beta.

Visão geral do Endpoints no Kubernetes

A seguir