Endpoints es un sistema de gestión de APIs distribuido que incluye servicios, tiempos de ejecución y herramientas. Endpoints proporciona gestión, monitorización y autenticación.
Los componentes que forman Endpoints son los siguientes:
Proxy de servicios extensible (ESP) o proxy de servicios extensible V2 (ESPv2): para insertar la funcionalidad de Endpoints.
Service Control: para aplicar reglas de gestión de APIs.
Service Management: para configurar reglas de gestión de APIs.
CLI de Google Cloud: para la implementación y la gestión.
Google Cloud Consola: para registrar, monitorizar y compartir.
Arquitectura de Endpoints
Componentes de Endpoints
ESP
ESP es un proxy basado en NGINX que se ejecuta delante del backend e inserta funciones de Endpoints, como la autenticación, la monitorización y el registro. ESP obtiene una configuración de servicio de Service Management y la usa para validar las solicitudes entrantes.
ESP se ha diseñado para que lo implementes en un entorno contenedorizado y valides JWTs y tokens de ID de Google. Emplea varias técnicas, como el almacenamiento en caché y las llamadas asíncronas, para seguir siendo ligero y ofrecer un rendimiento elevado.
La asistencia de ESP está disponible para las siguientes plataformas:
ESPv2
ESPv2 es un proxy escalable de alto rendimiento basado en Envoy que se ejecuta delante de un backend de API OpenAPI o gRPC. Endpoints en ESPv2 admite la versión 2 de las especificaciones de OpenAPI y gRPC.
ESPv2 se integra con la infraestructura de servicios de Google para habilitar funciones de gestión de APIs a gran escala, como la autenticación, los informes de telemetría, las métricas y la seguridad.
La compatibilidad con ESPv2 está disponible en las siguientes plataformas:- Entorno estándar de App Engine
- Cloud Run Functions
- Cloud Run
- Knative serving
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
Service Control
Service Control aplica reglas de gestión de APIs en tiempo de ejecución, como la autenticación de claves, la monitorización y el registro. Service Control proporciona los siguientes métodos:
Comprobar: verifica la autenticación y las claves de API, e indica si se debe permitir una llamada.
Informe: notifica a los sistemas de registro para el almacenamiento de registros y la monitorización.
Service Management
Utiliza la especificación de OpenAPI para describir la superficie y el comportamiento de tu API en un archivo de texto denominado configuración de Endpoints. Para desplegar la configuración de Endpoints en Service Management, usa la CLI de gcloud, que configura las reglas de gestión de APIs. Aquí también se realizan otras tareas relacionadas con la configuración, como compartir tu API con otros desarrolladores, habilitar o inhabilitar la API en diferentes proyectos y generar claves de API.La CLI de gcloud
CLI de gcloud proporciona la CLI de Google Cloud que puedes usar para hacer llamadas a varios servicios de Google Cloud . Utilizas la CLI de Google Cloud para desplegar la configuración de Endpoints en Service Management.
Google Cloud consola
La consolaGoogle Cloud es la interfaz gráfica de usuario de Google Cloud. Endpoints usa la consola para exponer datos de monitorización y registro que se envían desde ESP o ESPv2 y que Service Control registra. También usa la consola para compartir APIs con otros desarrolladores y para que estos generen claves de API para llamar a la API.Google Cloud
Casos de implementación
Las opciones de implementación varían en función de si se usa ESP o ESPv2 como proxy de Endpoints. ESPv2 se puede implementar como proxy remoto, y tanto ESPv2 como ESP se pueden implementar en modo sidecar, tal como se explica en las siguientes secciones.
Modo proxy remoto
Si usas ESPv2, Endpoints se puede desplegar como proxy remoto. Este modo se usa para admitir aplicaciones que se ejecutan en plataformas sin servidor, como Cloud Run, Cloud Run functions y App Engine para entornos estándar.
En este modo, ESPv2 se despliega como una aplicación de Cloud Run. La aplicación está configurada para usar ESPv2 como backend remoto mediante el campo x-google-backend en la configuración del servicio OpenAPI. Cuando funciona como proxy remoto en este modo de implementación, un solo ESPv2 puede admitir varios back-ends remotos.
Modo Sidecar
ESP y ESPv2 admiten la implementación en un contenedor junto con cada instancia de tu backend. Esta topología local del servidor es ideal tanto para APIs orientadas a la Web como para microservicios. De esta forma, se evita el salto de red que suele asociarse a los proxies centralizados y se permite una gestión de APIs de alto rendimiento y escalable.
Normalmente, el balanceo de carga se aplica antes de que el tráfico llegue a ESP o ESPv2. En App Engine, el balanceo de carga se produce automáticamente. En Compute Engine, se consigue con Cloud Load Balancing. En las implementaciones de Kubernetes, puedes usar un proxy de entrada para el balanceo de carga. En Google Kubernetes Engine, puedes usar Cloud Load Balancing o un proxy de entrada para el balanceo de carga.
Al iniciarse, ESP o ESPv2 obtiene su configuración de servicio de Service Management. La configuración del servicio se genera a partir de la especificación de OpenAPI o de gRPC, el archivo YAML de configuración del servicio. Indica a ESP o ESPv2 la superficie de la API que se va a gestionar junto con las políticas, como los métodos que requieren autenticación y los que requieren claves de API.
Enrutamiento de solicitudes
Cuando se recibe una solicitud, ESP o ESPv2 crea un token de traza para Cloud Trace.
A continuación, ESP o ESPv2 compara la ruta de las solicitudes entrantes con la superficie de la API. Después de encontrar una ruta que coincida, ESP o ESPv2 realizan los pasos de autenticación del método especificado.
Si es necesario validar el JWT, ESP o ESPv2 validan la autenticación mediante la clave pública adecuada del firmante y validan el campo de audiencia del JWT. Si se requiere una clave de API, ESP o ESPv2 llama a la API Service Control para validar la clave.
Service Control busca la clave para validarla y comprueba que el proyecto asociado a la clave haya habilitado la API. Si la clave no es válida o el proyecto no ha habilitado la API, la llamada se rechaza y se registra a través de la API Service Control.
Si Service Control valida la clave correctamente, la solicitud, junto con todos los encabezados originales y un encabezado de validación de JWT (si procede), se reenvía al backend.
Cuando se recibe una respuesta del backend, ESP o ESPv2 devuelve la respuesta a la persona que ha llamado y envía la información de tiempo final a Trace. La API Service Control registra los puntos de llamada, que escribe métricas y registros en sus destinos correspondientes.
ESP o ESPv2 en Kubernetes
En el siguiente diagrama se muestra la arquitectura general en la que ESP se ejecuta como un contenedor sidecar delante del contenedor de la aplicación de servicio de la API, con la API my-api alojada en my-api.com y respaldada por un servicio de Kubernetes. La arquitectura sería la misma para una implementación de sidecar con ESPv2.
