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 (ESPv2) para injetar a funcionalidade do Endpoints.
Service Control: para aplicar regras de gerenciamento de APIs;
Service Management: para configurar regras de gerenciamento de APIs;
Google Cloud CLI: para implantação e gerenciamento.
Console do Google Cloud: para geração de registros, monitoramento e compartilhamento.
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
O ESPv2 é um proxy escalonável de alto desempenho baseado no Envoy que é executado em um back-end de uma API OpenAPI ou gRPC. O Endpoints no ESPv2 é compatível com a versão 2 das especificações OpenAPI e especificações gRPC.
O ESPv2 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 do ESPv2 está disponível para as seguintes plataformas:- Ambiente padrão do App Engine
- Cloud Functions
- Cloud Run
- Knative serving
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
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
Use a especificação da OpenAPI para descrever a superfície e o comportamento da sua API em um arquivo de texto conhecido como a configuração do Endpoints. Para implantar a configuração do Endpoints no Service Management, use a CLI gcloud, 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.A CLI gcloud
A gcloud CLI fornece a Google Cloud CLI que pode ser usada para fazer chamadas para vários serviços do Google Cloud. Use a Google Cloud CLI para implantar a configuração do Endpoints no Service Management.
Console do Google Cloud
O Console do Google Cloud é a interface gráfica do usuário do Google Cloud. O Endpoints usa o console do Google Cloud para expor dados de monitoramento e geração de registros que são enviados do ESP ou do ESPv2 e registrados pelo Service Control, além de compartilhar APIs com outros desenvolvedores e para que eles gerem chaves de API para chamar a API.
Cenários de implantação
As opções para implantação variam de acordo com o uso de ESP ou ESPv2 como o proxy do Endpoints. O ESPv2 pode ser implantado como um proxy remoto, e o ESPv2 e o ESP podem ser implantados no modo de arquivo secundário, conforme explicado nas seções a seguir.
Modo de proxy remoto
Se estiver usando o ESPv2, 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 é implantado como um aplicativo Cloud Run. O aplicativo está configurado para usar o ESPv2 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 pode aceitar vários back-ends remotos.
Modo de arquivo secundário
Tanto o ESP quanto o ESPv2 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. No App Engine, o balanceamento de carga é automático. Já no Compute Engine, esse balanceamento é 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 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 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 cria um token de rastreamento para o Cloud Trace.
Em seguida, o ESP ou o ESPv2 correspondem ao caminho das solicitações recebidas com a superfície da API. Depois de encontrar uma rota correspondente, o ESP ou o ESPv2 executam quaisquer etapas de autenticação para o método especificado.
Se for necessária a validação do JWT, o ESP ou ESPv2 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 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 não for válida ou o projeto não tiver ativado a API, a chamada será rejeitada 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 ou o ESPv2 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 ou ESPv2 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.
