, toma un asiento trasero, ¡hay un nuevo jugador en la ciudad! NGINX Para muchos desarrolladores, NGINX sería la opción principal para el proxy inverso. Sin embargo, en , nuestra plataforma API para integraciones bancarias, ¡pasamos a algo más emocionante! Decentro El desarrollo de API ha pasado de una arquitectura monolítica de una sola pila a la majestuosa arquitectura de microservicios. Esto requiere un servidor de puerta de enlace que debe administrar la redirección, el proxy y la seguridad en varias solicitudes. Esto significa que nuestro antiguo y fiel NGINX se ha vuelto un poco obsoleto. (¡Ni siquiera hablemos aquí del servidor Apache HTTP!) Incluso si ejecuta una aplicación monolítica, API Gateway sigue siendo una buena elección. Aparte del proxy, hay muchos otros beneficios. Las puertas de enlace API deberían brindarnos al desarrollador la capacidad de: Escala: A medida que crece, también debería hacerlo su aplicación Proporcione seguridad: aplicar SSL es solo arañar la superficie Tener una GUI: Esto haría la vida 10 veces más fácil Sea intuitivo: debe explicarse por sí mismo “ ” Pero, ¿qué hace? Tu puedes preguntar. Buena pregunta. Supongamos que tenemos una pila de API con varias API que abarcan un conjunto de microservicios. Veamos el diagrama: Aquí puede ver que API Gateway es el amo y el salvador de las instancias de aplicación que se ejecutan detrás de él. Envía las solicitudes a la instancia de la aplicación requerida (como un proxy inverso). Ahora su punto final puede ser independiente del microservicio al que atiende. Entonces, si desea tener múltiples puntos finales (por ejemplo, /docs, /documents, /documentation) conectados a la misma aplicación, puede hacerlo. ¡Solo haz un proxy inverso, nena! ¡Adiós, NGINX! Aquí en Decentro, solíamos trabajar con NGINX como nuestro servidor proxy inverso. Pero crecimos fuera de eso. Tuvimos que iniciar sesión en nuestra instancia para recargar NGINX a través de CLI y tuvimos que aprender a administrar configuraciones cuando usamos NGINX. No tenía manejo a nivel de consumidor para la gestión de API. Necesitábamos algo extra. Después de conectar nuestras cabezas para una lluvia de ideas rápida y cruzar los Is 'y Ts' en la lista de pros y contras, ¡encontramos el indicado! Dhumm... Dhumm... Dhumm... ¿Lo sentiste? ¡Aquí viene ! KONG Fuente: Github Como es evidente en la imagen de arriba, Kong ofrece muchas funciones listas para usar. Sin recopilación. Sin configuración de línea de comandos. Sin costo adicional. Kong viene con sus propias API de administración RESTful. Está construido sobre OpenResty (una extensión de NGINX) y LuaJIT. Estos proporcionan acceso a todo tipo de configuraciones que pueden estar disponibles. Hemos hecho otra adición además al agregar el panel de Konga para administrar Kong a través de una GUI. Estructura de puerta de enlace API de Kong La estructura de la API en Kong es bastante simple. Servicios: la representación lógica de su microservicio o aplicación monolítica Rutas: la representación lógica de puntos finales a los que se puede acceder dentro del servicio. Consumidores: los clientes que van a utilizar los servicios. Complementos: aquí es donde sucede la magia. Los complementos se pueden aplicar a cualquiera de las entidades mencionadas anteriormente. Así que hablemos de un ejemplo. Tenemos un microservicio que se encarga de enviar correos electrónicos. Declararemos un Servicio con el nombre “emails” (Bastante innovador... ¡sí!). Esto contendrá los detalles del servidor de la aplicación, para el que invertirá el proxy. Ahora hagamos Rutas para este servicio. Así que tenemos dos tipos de correos electrónicos para enviar. Transaccional – Enviado por la API Marketing: enviado por el departamento de marketing para informar a los clientes sobre las nuevas características de nuestro increíble producto. Ahora, colocaremos un complemento de autenticación de clave API encima del servicio de "correos electrónicos". Esto asegurará que ningún malhechor intente obtener acceso a nuestras API. Complementos de límite de velocidad También agregaremos un complemento de límite de velocidad (para limitar la cantidad de visitas a la API) en las diferentes rutas. Transaccional (600 por minuto): dado que esta API es activada por otros flujos, necesitamos un límite de tasa alto. Marketing (1 por minuto): dado que esto se activa manualmente, no necesitamos ir más allá de 1 por minuto Para mejorar aún más nuestra seguridad, permitiremos que solo ciertas direcciones IP puedan acceder a nuestra ruta de correo electrónico transaccional, ya que solo será activada por nuestros sistemas internos, y conocemos el rango de direcciones IP para nuestros sistemas internos. Lo configuraremos abierto al mundo (potencialmente inseguro) para los correos electrónicos de marketing, ya que las personas de marketing deberían poder acceder a él desde cualquier cafetería en la que deseen trabajar. Ahora queremos que solo los consumidores autorizados accedan a las API, por lo que configuraremos un consumidor y agregaremos las credenciales de autenticación de API para que las usen. Ahora nuestro servicio de correo electrónico está listo para atender a los consumidores. Podemos integrarlo en nuestro código y dárselo a los expertos en marketing para que lo usen manualmente. Envolviendo las cosas Como puede ver, usar Kong como API Gateway es simple y elimina la molestia de administrar las API. Kong proporciona muchas otras características como flujos ascendentes, administración de certificados, transformación de solicitudes y respuestas, ejecución de código sin servidor, registro y CORS, que son muy útiles cuando desea desarrollar API rápidamente. NGINX y otros servidores proxy inversos simplemente están fuera del agua por la facilidad de configuración y la destreza absoluta que KONG proporciona de forma inmediata. Descansamos nuestro caso, por lo tanto!
