Endpoints es un sistema distribuido de administración de API compuesto por servicios, entornos de ejecución y herramientas, y proporciona administración, supervisión y autenticación.
Está conformado por los siguientes componentes:
Proxy de servicio extensible (ESP) o proxy de servicio extensible V2 (ESPv2): para incorporar la funcionalidad de Endpoints
Control de servicios: para aplicar las reglas de administración de API
Administración de servicios: para configurar las reglas de administración de API
Google Cloud CLI: para implementación y administración
Consola de Google Cloud: para el registro, la supervisión y el uso compartido
Arquitectura de Endpoints
Componentes de Endpoints
ESP
El ESP es un proxy basado en NGINX que se ejecuta frente al backend y que incorpora funcionalidades de Endpoints, como autenticación, supervisión y registro. El ESP recupera una configuración de servicio desde Service Management y la usa para validar solicitudes entrantes.
El ESP está diseñado para que puedas implementarlo en un entorno en contenedores y validar los JWT y los token de ID de Google. El ESP usa una variedad de técnicas, como almacenamiento en caché pesado y llamadas asíncronas, para mantener su ligereza y alto rendimiento.
La compatibilidad con el ESP está disponible para las siguientes plataformas:
ESPv2
El ESPv2 es un proxy escalable de alto rendimiento basado en Envoy que se ejecuta frente al backend de una API de OpenAPI o de gRPC. Endpoints en ESPv2 es compatible con la versión 2 de la especificación de OpenAPI y las especificaciones de gRPC.
El ESPv2 se integra en la infraestructura de servicio de Google para habilitar las funciones de administración de API a gran escala, incluida la autenticación, los informes de telemetría, las métricas y la seguridad.
La compatibilidad con ESPv2 está disponible para las siguientes plataformas:- Entorno estándar de App Engine
- Cloud Functions
- Cloud Run
- Cloud Run for Anthos
- Compute Engine
- Google Kubernetes Engine
- Kubernetes
Service Control
El Control de servicios aplica reglas de administración de API en el entorno de ejecución, como autenticación de clave, supervisión y registro. El Control de servicios proporciona los siguientes métodos:
Verificación: comprueba la autenticación y las claves de API, y también indica cuándo se debe permitir una llamada.
Informe: notifica a los sistemas de registro para el registro y la supervisión.
Service Management
Usas la especificación de OpenAPI para describir la superficie y el comportamiento de tu API en un archivo de texto al que se hace referencia como la configuración de Endpoints. Puedes implementar la configuración de Endpoints en Service Management mediante el uso de gcloud CLI, que configura las reglas de administración de API. Aquí también tienen lugar otras tareas relacionadas con la configuración, como compartir la API con otros desarrolladores, habilitar o inhabilitar la API en proyectos diferentes y generar claves de API.Gcloud CLI
La CLI de gcloud proporciona Google Cloud CLI, que puedes usar para realizar llamadas a varios servicios de Google Cloud. Usa Google Cloud CLI para implementar tu configuración de Endpoints en Service Management.
Consola de Google Cloud
La consola de Google Cloud es la interfaz gráfica de usuario de Google Cloud. Endpoints usa la consola de Google Cloud para exponer los datos de supervisión y registro que se envían desde el ESP o ESPv2 y que el Control de servicios registra y comparte las APIs con otros desarrolladores. También sirve para que estos generen claves de API a fin de llamar a la API.
Situaciones de implementación
Las opciones de implementación varían en función del uso del ESP o el ESPv2 como proxy de Endpoints. El ESPv2 se puede implementar como un proxy remoto, y el ESPv2 y el ESP se pueden implementar en modo de proxy de sidecar, como se explica en las siguientes secciones.
Modo de proxy remoto
Si usas el ESPv2, Endpoints se puede implementar como un proxy remoto. Este modo se usa con el fin de admitir aplicaciones que se ejecutan en plataformas sin servidores, como Cloud Run, Cloud Functions y App Engine, en entornos estándar.
En este modo, el ESPv2 se implementa como una aplicación de Cloud Run. La aplicación está configurada para usar el ESPv2 como un backend remoto mediante el uso del campo x-google-backend en la configuración de servicio de OpenAPI. Cuando funciona como un proxy remoto en este modo de implementación, un solo ESPv2 puede admitir varios backends remotos.
Modo de archivo adicional
El ESP y el ESPv2 admiten la implementación en un contenedor junto con cada instancia de tu backend. Esta topología de servidor local es ideal tanto para las API web como para los microservicios. También evita el salto de red que se suele asociar con los proxies centralizados y permite una administración de la API de alto rendimiento y sumamente escalable.
Por lo general, el balanceo de cargas se aplica antes de que el tráfico llegue al ESP o al ESPv2. En App Engine, el balanceo de cargas ocurre de forma automática. En Compute Engine, esto se lleva a cabo con Cloud Load Balancing. En implementaciones de Kubernetes, puedes usar un proxy de entrada para el balanceo de cargas. En Google Kubernetes Engine, puedes usar Cloud Load Balancing o un proxy de entrada con el mismo fin.
Durante el inicio, el ESP o el ESPv2 obtienen su configuración de servicio de la Administración de servicios. La configuración de servicios se genera desde la especificación de OpenAPI o desde gRPC, la configuración de servicio del archivo YAML. Le indica al ESP y al ESPv2 la superficie de la API que se administrará y también las políticas, como cuáles métodos requieren autenticación y cuáles necesitan claves de API.
Solicitar enrutamiento
Cuando se recibe una solicitud, el ESP o el ESPv2 crean un token de seguimiento para Cloud Trace.
Luego, el ESP o el ESPv2 hacen coincidir la ruta de las solicitudes entrantes con la superficie de la API. Después de encontrar una ruta que coincide, el ESP o el ESPv2 realizan cualquier paso de autenticación para el método especificado.
Si se requiere una validación de JWT, el ESP o el ESPv2 validan la autenticación mediante la clave pública adecuada para el firmante y valida el campo del público en el JWT. Si se requiere una clave de API, el ESP o el ESPv2 llaman a la API de Service Control para validar la clave.
El Control de servicios busca la clave para validarla y se asegura de que el proyecto asociado con la clave haya habilitado la API. Si la clave no es válida o el proyecto no habilitó la API, la llamada se rechaza y se registra a través de la API de Service Control.
Si Control de servicios valida la clave correctamente, la solicitud se reenvía al backend con todos los encabezados originales, y con un encabezado de validación de JWT si corresponde.
Cuando se recibe una respuesta del backend, el ESP o el ESPv2 le muestran la respuesta al emisor y envían la información final sobre el tiempo a Trace. Los puntos de llamada se registran mediante la API de Control de servicios, que escribe las métricas y los registros en sus destinos correspondientes.
ESP o ESPv2 en Kubernetes
En el diagrama siguiente, se muestra la arquitectura general en la que el ESP se ejecuta como un contenedor de archivo adicional delante del contenedor de la aplicación de servicio de la API, con la API de 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 proxy de sidecar con el ESPv2.
