nginx - bad - Puerta de enlace API frente a proxy inverso

nginx api gateway

Question

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

• Autenticación (Se puede hacer usando scripts nginx LUA);
• Seguridad de transporte. Es la tarea de proxy inverso;
• Balanceo de carga
• ....

Entonces, en base a esto, hay varias preguntas:

1. ¿Tiene sentido usar API gateway y Reverse proxy simultáneamente (como ejemplo request-> Api gateway-> reverse proxy (nginx) -> concrete mictoservice)? En que casos
2. ¿Cuáles son las otras diferencias que se pueden implementar usando la puerta de enlace API y no se pueden implementar mediante proxy inverso y viceversa?

Answer 1

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 la interfaz de usuario, 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 a menudo cambian. A sus preguntas:

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

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

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

Espero eso ayude.

Answer 2

Es más fácil pensar en ellos si te das 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 comprobación del estado. Un ejemplo sería algo así como una arquitectura sándwich WAF en el sentido de que su firewall de aplicación web / puerta de enlace API está encajonado por niveles de proxy inverso, uno para el propio WAF y el otro para los microservicios individuales con los que habla.

En cuanto a las diferencias, son muy similares. Es solo nomenclatura. A medida que toma una configuración básica de proxy inverso y comienza a atornillar más elementos como autenticación, limitación de velocidad, actualizaciones dinámicas de configuración y descubrimiento de servicios, es más probable que las personas llamen a eso una puerta de enlace API.