Puerta de enlace API frente a proxy inverso


108

Para lidiar con la arquitectura de microservicio, a menudo se usa junto con un proxy inverso (como nginx o apache httpd) y, para cuestiones transversales, se usa el patrón de puerta de enlace API de implementación . A veces, el proxy inverso hace el trabajo de puerta de enlace API.
Será bueno ver claras diferencias entre estos dos enfoques. Parece que el beneficio potencial del uso de la puerta de enlace API es invocar varios microservicios y agregar los resultados. Todas las demás responsabilidades de la puerta de enlace API se pueden implementar mediante el proxy inverso, como:

  • Autenticación (se puede hacer usando scripts nginx LUA);
  • Seguridad del transporte. Es en sí misma tarea de proxy inverso;
  • Balanceo de carga
  • ....

Entonces, en base a esto, hay varias preguntas:

  1. ¿Tiene sentido usar la puerta de enlace API y el proxy inverso simultáneamente (como solicitud de ejemplo-> puerta de enlace Api-> proxy inverso (nginx) -> mictoservicio concreto)? En que casos
  2. ¿Cuáles son las otras diferencias que se pueden implementar con la puerta de enlace API y que no se pueden implementar con el proxy inverso y viceversa?

Respuestas:


83

Es más fácil pensar en ellos si se da cuenta de que no son mutuamente excluyentes. Piense en una puerta de enlace API como una implementación de proxy inverso de tipo específico.

En lo que respecta a sus preguntas, no es raro ver que ambos se usan en conjunto, donde la puerta de enlace API se trata como un nivel de aplicación que se encuentra detrás de un proxy inverso para el equilibrio de carga y la verificación del estado. Un ejemplo sería algo así como una arquitectura de sándwich WAF en la que su Firewall de aplicaciones web / API Gateway está emparedado por niveles de proxy inverso, uno para el WAF en sí y el otro para los microservicios individuales con los que habla.

En cuanto a las diferencias, son muy similares. Es solo una nomenclatura. A medida que toma una configuración básica de proxy inverso y comienza a incorporar más piezas como autenticación, limitación de velocidad, actualizaciones de configuración dinámica y descubrimiento de servicios, es más probable que la gente lo llame puerta de enlace API.


corrígeme si me equivoco, pero puedo usar ambos en el mismo ecosistema. El uso de una puerta de enlace API es más para orquestar cambios dinámicos y constantes agregados al monitoreo del tablero y las restricciones de seguridad que usar un proxy inverso como nginx podría ser más efectivo para servir subdominios estáticos y fijos que brinden equilibrio de carga, por ejemplo.
aelkz

28

Creo que API Gateway es un proxy inverso que se puede configurar dinámicamente a través de API y potencialmente a través de UI, mientras que el proxy inverso tradicional (como Nginx, HAProxy o Apache) se configura a través de un archivo de configuración y debe reiniciarse cuando cambia la configuración. Por lo tanto, API Gateway debe usarse cuando las reglas de enrutamiento u otra configuración cambian con frecuencia. A tus preguntas:

  1. Tiene sentido siempre que cada componente de esta secuencia cumpla su propósito.
  2. Las diferencias no están en la lista de funciones, sino en la forma en que se aplican los cambios de configuración.

Además, API Gateway se proporciona a menudo en forma de SAAS, como Apigee o Tyk, por ejemplo.

Además, aquí está mi tutorial sobre cómo crear una puerta de enlace API simple con Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Espero eso ayude.


Gracias por las sugerencias de SAAS
Zenuka

4
¿Alguna posibilidad de que conozca un lugar alternativo para la información de lo que había en ese enlace de memz.co? Está muerto.
Nueva Alejandría

0

Las puertas de enlace API suelen funcionar como una construcción L7.

Las puertas de enlace API proporcionan una funcionalidad adicional en comparación con un proxy inverso simple. Si considera algunos de los portales que existen, pueden proporcionar:

  • Gestión completa del ciclo de vida de la API, incluida la documentación
  • un portal que se puede utilizar como fuente de información para varias aplicaciones de cliente y donde puede proporcionar gobernanza del cliente, limitación de tasas, etc.
  • enrutamiento a diferentes versiones de la API, incluidas las versiones canary / beta
  • detectar patrones de uso, registrar aplicaciones, recuperar credenciales de cliente, etc.

Sin embargo, con el advenimiento de las mallas de servicio como Istio, Consul gran parte de la funcionalidad de API Gateways será subsumida por mallas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.