Uso de puertas de enlace de API en microservicios

En una arquitectura de microservicios, un cliente podría interactuar con más de un servicio front-end. Dado este hecho, ¿cómo sabe un cliente a qué extremos llamar? ¿Qué ocurre cuando se introducen nuevos servicios o se refactorizan los servicios existentes? ¿Cómo gestionan los servicios la terminación de SSL, el TLS mutuo, la autenticación y otros aspectos? Una puerta de enlace de API puede ayudar a abordar estos desafíos.

Descargar un archivo de Visio de esta arquitectura.

¿Qué es una puerta de enlace de API?

Una puerta de enlace de API proporciona un punto de entrada centralizado para administrar interacciones entre clientes y servicios de aplicaciones. Actúa como proxy inverso y enruta las solicitudes de los clientes a los servicios adecuados. También puede realizar diversas tareas transversales, como autenticación, terminación SSL, TLS mutua y limitación de velocidad.

¿Por qué usar una puerta de enlace de API?

Una puerta de enlace de API simplifica la comunicación, mejora las interacciones del cliente y centraliza la administración de responsabilidades comunes de nivel de servicio. Actúa como intermediario y evita la exposición directa de los servicios de aplicación a los clientes. Sin una puerta de enlace de API, los clientes deben comunicarse directamente con servicios de aplicaciones individuales, lo que puede presentar los siguientes desafíos:

• código de cliente complejo: puede dar lugar a código de cliente complejo. Los clientes deben gestionar varios puntos de conexión y manejar los fallos con resiliencia.

• acoplamiento ajustado: crea un acoplamiento entre el cliente y el back-end. Los clientes deben comprender la descomposición de los servicios individuales, complicando el mantenimiento y la refactorización del servicio.

• mayor latencia: una sola operación puede requerir llamadas a varios servicios. El resultado puede ser varios recorridos de ida y vuelta de red entre el cliente y el servidor, lo que agrega una latencia significativa.

• control redundante de problemas: cada servicio orientado al público debe controlar problemas como la autenticación, SSL y la limitación de velocidad de cliente.

• limitaciones del protocolo: los servicios deben exponer un protocolo descriptivo para el cliente, como HTTP o WebSocket. Esta exposición limita opciones de protocolos de comunicación.

• superficie expuesta a ataques expandida: los puntos de conexión públicos aumentan la posible superficie expuesta a ataques y requieren protección.

Uso de una puerta de enlace de API

Una puerta de enlace de API se puede adaptar a los requisitos de la aplicación mediante patrones de diseño específicos. Estos patrones de diseño abordan la funcionalidad clave, como el enrutamiento, la agregación de solicitudes y los problemas transversales:

• enrutamiento de puerta de enlace. Puede usar una puerta de enlace de API como proxy inverso para enrutar las solicitudes de cliente a diferentes servicios de aplicación. La puerta de enlace de API usa enrutamiento de nivel 7 y proporciona un único punto de conexión para que los clientes los usen. Use el enrutamiento de un gateway de API cuando quiera desacoplar a los clientes de los servicios de aplicación.

• Agregación de puerta de enlace. Puede usar la puerta de enlace de API para agregar varias solicitudes de cliente en una sola solicitud. Use este patrón cuando una sola operación requiera llamadas a varios servicios de aplicación. En la agregación de API, el cliente envía una solicitud a la puerta de enlace de API. A continuación, la puerta de enlace de API enruta las solicitudes a los distintos servicios necesarios para las operaciones. Por último, la puerta de enlace de API agrega los resultados y los devuelve al cliente. La agregación ayuda a reducir la excesiva comunicación entre el cliente y los servicios de la aplicación.

• Descarga de la puerta de enlace. Puede usar una puerta de enlace de API para proporcionar funcionalidad transversal, por lo que los servicios individuales no tienen que proporcionarla. Puede ser útil consolidar la funcionalidad transversal en un solo lugar, en lugar de hacer que cada servicio sea responsable. Estos son ejemplos de funcionalidad que podría descargar en una puerta de enlace de API:

  • Terminación de SSL
  • TLS mutuo
  • Autenticación
  • Lista de direcciones IP permitidas o lista de bloqueados
  • Limitación de velocidad del cliente (regulación)
  • Lista de direcciones IP permitidas o lista de bloqueados
  • Cliente limitación
  • Registro y supervisión
  • Almacenamiento en caché de respuestas
  • Firewall de aplicaciones web
  • Compresión GZIP
  • Mantenimiento del contenido estático

Opciones de puerta de enlace de API

Estas son algunas opciones para implementar una puerta de enlace de API en la aplicación.

• servidor proxy inverso. Nginx y HAProxy son ofertas de proxy inverso de código abierto. Admiten características como el equilibrio de carga, la terminación SSL y el enrutamiento de nivel 7. Tienen versiones gratuitas y ediciones de pago que proporcionan características adicionales y opciones de soporte técnico. Estos productos están maduros con conjuntos de características enriquecidos, alto rendimiento y extensibles.

• Gateway de entrada de la malla de servicios. Si ya utiliza una malla de servicios, la propia puerta de enlace de entrada de la malla puede servir como pasarela de API. Usarlo significa que el tráfico norte-sur entra de inmediato en el plano de datos de la malla y queda sujeto al mismo mTLS, la misma identidad de la carga de trabajo, la misma política de autorización y la misma telemetría que el tráfico este-oeste. Para AKS, el complemento de malla de servicios basado en Istio es la opción administrada compatible e incluye un gateway de entrada de Istio administrado. Linkerd y Consul son alternativas no administradas.

  Los gateways de entrada de la malla suelen tener capacidades más limitadas que los gateways de API dedicados en funciones como el firewall de aplicaciones web (WAF), la conversión de las API en productos, la transformación de solicitudes y el enrutamiento global, por lo que deben combinarse con Application Gateway, Front Door o API Management, o sustituirse por estos, cuando se requieran esas capacidades.

• Azure Application Gateway. Application Gateway es un servicio de equilibrio de carga administrado. Proporciona enrutamiento de nivel 7, terminación SSL y firewall de aplicaciones web (WAF).

• azure Front Door. Azure Front Door es una red de entrega de contenido (CDN). Usa puntos globales y locales de presencia (POP) para proporcionar acceso rápido, confiable y seguro al contenido web estático y dinámico de las aplicaciones globalmente.

• azure API Management. API Management es una solución administrada para publicar API en clientes externos e internos. Proporciona características para administrar las API orientadas al público, como la limitación de velocidad, las restricciones de IP y la autenticación mediante microsoft Entra ID u otros proveedores de identidades. API Management no realiza ningún equilibrio de carga, por lo que debe usarlo con un equilibrador de carga, como Azure Application Gateway o un proxy inverso. Para obtener más información, consulte API Management with Azure Application Gateway.

Elección de una tecnología de puerta de enlace de API

Al seleccionar una puerta de enlace de API, tenga en cuenta los siguientes factores:

• Cumplir todos los requisitos. Elija una puerta de enlace de API que admita las características necesarias. Todas las anteriores opciones de puerta de enlace de API admiten el enrutamiento de nivel 7. Pero su compatibilidad con otras características, como la autenticación, la limitación de velocidad y la terminación SSL, pueden variar. Evalúe si una sola puerta de enlace satisface sus necesidades o si son necesarias varias puertas de enlace.

• Prefiere ofertas integradas. Use soluciones integradas de entrada y puerta de enlace de API proporcionadas por la plataforma, como Azure Container Apps y AKS, siempre que cumplan los requisitos de seguridad y control. Use solo una puerta de enlace personalizada si las opciones integradas carecen de flexibilidad necesaria. Las soluciones personalizadas requieren un modelo de gobernanza, como GitOps, para administrar su ciclo de vida de forma eficaz.

• Elija el modelo de implementación adecuado. Use servicios administrados como Azure Application Gateway y Azure API Management para reducir la sobrecarga operativa. Si usa servidores proxy inversos de uso general o equilibradores de carga, impleméntelos de forma que se alinee con la arquitectura. Puede implementar puertas de enlace de API de propósito general en máquinas virtuales dedicadas o en un clúster de AKS en sus ofertas de Ingress Controller. Para aislar la puerta de enlace de API de la carga de trabajo, puede implementarlas fuera del clúster, pero esta implementación aumenta la complejidad de la administración.

• Administrar cambios. Al actualizar los servicios o agregar otros nuevos, es posible que tenga que actualizar las reglas de enrutamiento de la puerta de enlace. Implemente procesos o flujos de trabajo para administrar reglas de enrutamiento al agregar o modificar servicios, certificados SSL, listas de direcciones IP permitidas y configuraciones de seguridad. Utilice herramientas de infraestructura como código y de automatización para agilizar la administración de la puerta de enlace de API.

Pasos siguientes

En los artículos anteriores se exploraron las interfaces entre microservicios y entre microservicios y aplicaciones cliente. Estas interfaces tratan cada servicio como una unidad opaca independiente. Un principio fundamental de la arquitectura de microservicios es que los servicios nunca deben exponer detalles internos sobre cómo administran los datos. Este enfoque tiene implicaciones significativas para mantener la integridad y la coherencia de los datos, que es el tema del siguiente artículo.

Recursos relacionados

• API de diseño para microservicios
• Diseño de una arquitectura de microservicios
• Uso del análisis de dominio para modelar microservicios
• evaluación y preparación de microservicios