O Endpoints é um sistema de gestão de APIs distribuído que inclui serviços, tempos de execução e ferramentas. Os Endpoints oferecem gestão, monitorização e autenticação.
Os componentes que constituem os pontos finais são:
Proxy de serviço extensível (ESP) ou proxy de serviço extensível V2 (ESPv2) para injetar a funcionalidade dos Endpoints.
Controlo de serviços: para aplicar regras de gestão de APIs.
Service Management: para configurar regras de gestão de APIs.
CLI do Google Cloud: para implementação e gestão.
Google Cloud consola: para registo, monitorização e partilha.
Arquitetura de endpoints
Componentes de endpoints
ESP
O ESP é um proxy baseado no NGINX que é executado à frente do back-end e injeta funcionalidades dos Endpoints, como autenticação, monitorização e registo. O ESP obtém uma configuração de serviço da gestão de serviços e usa-a para validar os pedidos recebidos.
O ESP foi concebido para ser implementado num ambiente em contentores e validar JWTs e tokens de ID Google. Emprega várias técnicas, como o armazenamento em cache pesado e chamadas assíncronas, para permanecer leve e com um desempenho elevado.
O suporte de ESP está disponível para as seguintes plataformas:
ESPv2
O ESPv2 é um proxy escalável de alto desempenho baseado no Envoy que é executado à frente de um back-end de API OpenAPI ou gRPC. Os pontos finais no ESPv2 suportam a versão 2 da especificação OpenAPI e as especificações gRPC.
O ESPv2 integra-se com a infraestrutura de serviços Google para ativar funcionalidades de gestão de APIs em grande escala, incluindo autenticação, relatórios de telemetria, métricas e segurança.
O suporte do ESPv2 está disponível para as seguintes plataformas:Controlo de Serviços
O Service Control aplica regras de gestão de APIs em tempo de execução, como autenticação de chaves, monitorização e registo. O Service Control fornece os seguintes métodos:
Check: valida a autenticação e as chaves da API e indica se uma chamada deve ser permitida
Comunicação: notifica os sistemas de registo para registo e monitorização
Gestão de serviços
Descreve o comportamento do seu serviço gRPC num ficheiro YAML denominado configuração do Endpoints. Implementa a configuração do Endpoints e os seus ficheiros.proto compilados na gestão de serviços através da CLI gcloud, que configura as regras de gestão de APIs.
Outras tarefas relacionadas com a configuração também ocorrem aqui, como partilhar a sua API com outros programadores, ativar ou desativar a API em diferentes projetos e gerar chaves da API.
A CLI gcloud
A CLI gcloud fornece a CLI do Google Cloud que pode usar para fazer chamadas para vários Google Cloud serviços. Usa a Google Cloud CLI para implementar a configuração dos Endpoints na gestão de serviços.
Google Cloud consola
A Google Cloud consola é a interface gráfica do utilizador para Google Cloud. Os Endpoints usam aGoogle Cloud consola para expor dados de monitorização e registo enviados a partir do ESP ou ESPv2 e registados pelo Service Control, bem como partilhar APIs com outros programadores, e para estes gerarem chaves de API para chamar a API.
Cenários de implementação
As opções de implementação variam consoante a utilização do ESP ou do ESPv2 como proxy dos Endpoints. O ESPv2 pode ser implementado como um proxy remoto e o ESPv2 e o ESP podem ser implementados no modo sidecar, conforme explicado nas secções seguintes.
Modo proxy remoto
Se usar o ESPv2, os Endpoints podem ser implementados como um proxy remoto. Este modo é usado para suportar aplicações executadas em plataformas sem servidor, como o Cloud Run, as funções do Cloud Run e o App Engine para ambientes padrão.
Neste modo, o ESPv2 é implementado como uma aplicação do Cloud Run. A aplicação está configurada para usar o ESPv2 como um back-end remoto através do campo x-google-backend na configuração do serviço OpenAPI. Quando funciona como um proxy remoto neste modo de implementação, um único ESPv2 pode suportar vários back-ends remotos.
Modo Sidecar
O ESP e o ESPv2 suportam a implementação num contentor juntamente com cada instância do seu back-end. Esta topologia local do servidor é ideal para APIs viradas para a Web e microsserviços. Evita o salto de rede normalmente associado a proxies centralizados e permite uma gestão de APIs de alto desempenho e escalável.
Normalmente, o equilíbrio de carga é aplicado antes de o tráfego atingir o ESP ou o ESPv2. No Compute Engine, isto é feito através do Cloud Load Balancing. Para implementações do Kubernetes, pode usar um proxy de entrada para o equilíbrio de carga. No Google Kubernetes Engine, pode usar o Cloud Load Balancing ou um proxy de entrada para o balanceamento de carga.
No arranque, o ESP ou o ESPv2 obtém a respetiva configuração de serviço a partir da gestão de serviços. A configuração do serviço é gerada a partir da especificação OpenAPI ou do gRPC, o ficheiro YAML de configuração do serviço. Indica ao ESP ou ao ESPv2 a superfície da API a ser gerida juntamente com as políticas, como os métodos que requerem autenticação e os que requerem chaves da API.
Encaminhamento de pedidos
Quando é recebido um pedido, o ESP ou o ESPv2 cria um token de rastreio para o Cloud Trace.
Em seguida, o ESP ou o ESPv2 faz corresponder o caminho dos pedidos recebidos à superfície da API. Depois de encontrar uma rota correspondente, o ESP ou o ESPv2 executa todos os passos de autenticação para o método especificado.
Se a validação JWT for necessária, o ESP ou o ESPv2 valida a autenticação através da chave pública adequada para o signatário e valida o campo de público-alvo no JWT. Se for necessária uma chave da API, o ESP ou o ESPv2 chama a API Service Control para validar a chave.
O Service Control procura a chave para a validar e garante que o projeto associado à chave ativou a API. Se a chave não for válida ou o projeto não tiver ativado a API, a chamada é rejeitada e registada através da API Service Control.
Se o Service Control validar a chave com êxito, o pedido, juntamente com todos os cabeçalhos originais, mais um cabeçalho de validação JWT, se adequado, é encaminhado para o back-end.
Quando é recebida uma resposta do back-end, o ESP ou o ESPv2 devolve a resposta ao autor da chamada e envia as informações de tempo finais para o rastreio. Os pontos de chamada são registados pela API Service Control, que escreve métricas e registos nos respetivos destinos adequados.
ESP ou ESPv2 no Kubernetes
O diagrama seguinte mostra a arquitetura geral em que o ESP é executado como um contentor side-car à frente do contentor da aplicação do serviço API, com a API my-api alojada em my-api.com e suportada por um serviço Kubernetes. A arquitetura seria a mesma para uma implementação sidecar com o ESPv2.
