Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Patrón de enrutamiento por rutas
El enrutamiento por rutas es el mecanismo que consiste en agrupar varias o todas las API bajo el mismo nombre de host y utilizar un URI de solicitud para aislar los servicios; por ejemplo, api.example.com/service-a o api.example.com/service-b.
Caso de uso típico
La mayoría de los equipos optan por este método porque quieren una arquitectura sencilla: el desarrollador solo tiene que recordar una URL, como api.example.com, para poder interactuar con la API HTTP. La documentación de la API suele ser más fácil de digerir porque suele estar reunida en lugar de estar dividida en diferentes portales o archivos PDF.
El enrutamiento basado en rutas se considera un mecanismo sencillo para compartir una API HTTP. Sin embargo, implica una sobrecarga operativa, como la configuración, la autorización, las integraciones y la latencia adicional debido a los múltiples saltos. También requiere procesos maduros de administración de cambios para garantizar que una mala configuración no interrumpa todos los servicios.
Sí AWS, hay varias formas de compartir una API y enrutarla de manera efectiva al servicio correcto. En las siguientes secciones se analizan tres enfoques: proxy inverso del servicio HTTP, API Gateway y Amazon CloudFront. Ninguno de los enfoques sugeridos para unificar los servicios de API se basa en los servicios descendentes que se ejecutan en AWS. Los servicios podrían ejecutarse en cualquier lugar sin problemas o con cualquier tecnología, siempre que sean compatibles con HTTP.
Proxy inverso del servicio HTTP
Puede utilizar un servidor HTTP como NGINX
La siguiente configuración para NGINX asigna dinámicamente una solicitud HTTP de api.example.com/my-service/ a my-service.internal.api.example.com.
server { listen 80; location (^/[\w-]+)/(.*) { proxy_pass $scheme://$1.internal.api.example.com/$2; } }
El siguiente diagrama ilustra el método de proxy inverso del servicio HTTP.
Este enfoque puede ser suficiente para algunos casos de uso en los que no se utilizan configuraciones adicionales para empezar a procesar las solicitudes, lo que permite que la API descendente recopile métricas y registros.
Para prepararse para la producción operativa, querrá poder agregar observabilidad a todos los niveles de su pila, añadir configuraciones adicionales o agregar scripts para personalizar el punto de entrada de la API y permitir características más avanzadas, como la limitación de velocidad o los tokens de uso.
Ventajas
El objetivo final del método de proxy inverso del servicio HTTP es crear un enfoque escalable y administrable para unificar las API en un solo dominio, de forma que resulte coherente para cualquier consumidor de API. Este enfoque también permite a sus equipos de servicio implementar y administrar sus propias API, con una sobrecarga mínima después de la implementación. AWS los servicios gestionados de rastreo, como AWS X-Ray
Desventajas
La principal desventaja de este enfoque son las exhaustivas pruebas y la administración de los componentes de la infraestructura que se requieren, aunque esto podría no ser un problema si se cuenta con equipos de ingeniería de confiabilidad del sitio (SRE).
Este método supone un punto de inflexión en cuanto a los costos. En volúmenes bajos o medianos, es más caro que algunos de los otros métodos descritos en esta guía. En volúmenes altos, es muy rentable (alrededor de 100 000 transacciones por segundo o más).
API Gateway
El servicio Amazon API Gatewayapi.example.com y, a continuación, enviar las solicitudes por proxy al servicio anidado; por ejemplo, billing.internal.api.example.com.
Probablemente no quiera ser demasiado detallado y asignar todas las rutas de todos los servicios en la puerta de enlace de API principal o raíz. En su lugar, opte por rutas comodín, por ejemplo, /billing/*, para reenviar las solicitudes al servicio de facturación. Al no asignar todas las rutas de la puerta de enlace de la API raíz o principal, se obtiene una mayor flexibilidad con respecto a las API, ya que no es necesario actualizar la puerta de enlace de la API raíz con cada cambio de API.
Ventajas
Para controlar los flujos de trabajo más complejos, como el cambio de los atributos de las solicitudes, las API de REST exponen Apache Velocity Template Language (VTL) para poder modificar la solicitud y la respuesta. Las API de REST pueden ofrecer beneficios adicionales como los siguientes:
-
Autenticación N/Z con AWS Identity and Access Management (IAM), Amazon Cognito o autorizadores AWS Lambda
-
Tokens de uso para agrupar en buckets a los consumidores en diferentes niveles (consulte Limitar las solicitudes de la API para mejorar el rendimiento en la documentación de API Gateway)
Desventajas
Con volúmenes altos, el costo puede ser un problema para algunos usuarios.
CloudFront
Puedes usar la función de selección dinámica de origenapi.example.com.
Caso de uso típico
La lógica de enrutamiento forma parte del código de la función de Lambda@Edge, por lo que admite mecanismos de enrutamiento altamente personalizables, como las pruebas A/B, las versiones de valor controlado, la señalización de características y la reescritura de rutas. Esto se explica en el siguiente diagrama.
Ventajas
Si necesita almacenar en caché las respuestas de la API, este método es una buena forma de unificar un conjunto de servicios en un único punto de conexión. Es un método rentable para unificar las colecciones de API.
Además, CloudFront admite el cifrado a nivel de campo, así como la integración con las AWS WAF ACL básicas y las ACL básicas.
Desventajas
Este método admite un máximo de 250 orígenes (servicios) que se pueden unificar. Este límite es suficiente para la mayoría de las implementaciones, pero puede provocar problemas con una gran cantidad de API a medida que amplíe su cartera de servicios.
La actualización de las funciones de Lambda @Edge tarda actualmente unos minutos. CloudFront también tarda hasta 30 minutos en completar la propagación de los cambios a todos los puntos de presencia. En última instancia, esto bloquea las actualizaciones posteriores hasta que se completen.
