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): para injetar 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 Platform: para geraçã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 utiliza para validar as solicitações recebidas.

O ESP foi projetado para você implantá-lo em um ambiente em contêiner e para validar os JWTs e os tokens do código do Google. Ele emprega várias técnicas como armazenamento pesado em cache e chamadas assíncronas para manter sua leveza e alto desempenho.

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. Para implantar as configurações do Endpoints e seus arquivos .proto compilados no gerenciamento de serviços, use o Cloud SDK, que configura as regras de gerenciamento de 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 chamar vários serviços do GCP. Com o gcloud, você implanta a configuração do Endpoints no Service Management.

Console do Google Cloud Platform

O Console do GCP é a interface gráfica do usuário do Google Cloud Platform (GCP). Ele é usado pelo Endpoints para expor dados de monitoramento e de geração de registros enviados do ESP e registrados pelo Service Control. O Console também compartilha APIs com outros desenvolvedores e é usado por eles para gerar chaves e chamar a API.

Cenários de implantação

O ESP foi projetado para você implantá-lo 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 que o tráfego chegue ao ESP. No Compute Engine, isso é realizado por meio do 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 solicita a configuração de serviço ao Service Management. Ela é gerada a partir da especificação OpenAPI ou do gRPC, o arquivo YAML de configuração de serviço. Ela informa o ESP 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 cria um token de trace para o Stackdriver Trace.

Em seguida, o ESP compara o caminho das solicitações recebidas com a superfície da API. Depois de encontrar uma rota correspondente, o ESP executa as etapas de autenticação no método especificado.

Se for necessária a validação do JWT, o ESP validará a autenticação usando a chave pública apropriada do signatário e confirmará o campo de público no JWT. Se for necessária uma chave de API, o ESP 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 chega uma resposta do back-end, o ESP a retorna para o autor da chamada e envia as informações de duração 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 no Kubernetes

No diagrama a seguir, veja a arquitetura geral em que o ESP é executado como contêiner auxiliar do contêiner de aplicativos de serviço da API, sendo que a API my-api está hospedada em my-api.com e tem como base um serviço do Kubernetes.

Visão geral do Endpoints no Kubernetes

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Cloud Endpoints com gRPC
Precisa de ajuda? Acesse nossa página de suporte.