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

Service Control

O Service Control aplica regras de gerenciamento de API 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 e registrados pelo Service Control, para compartilhar APIs com outros desenvolvedores e para a geração de chaves de API para 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 de o tráfego atingir o ESP. 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 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 Cloud 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 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).

Visão geral do Endpoints no Kubernetes

A seguir