Puerta de enlace API frente a proxy inverso

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?

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.

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.

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.