- Introducción
- Comunicación directa cliente-microservicios
- API Gateway intervención
- Ejemplo con balanceador de carga y características del patrón
- Problemas a evitar
Introducción
Cuando diseñas y creas aplicaciones grandes o complejas basadas en microservicios, con múltiples aplicaciones cliente, un buen enfoque a considerar puede ser una API Gateway. Este es un servicio que proporciona un punto de entrada único para ciertos grupos de microservicios. Es similar al Facade Pattern del diseño orientado a objetos, pero en este caso, es parte de un sistema distribuido. El API Gateway pattern también se conoce a veces como «back-end para frontend» (BFF) porque lo construyes mientras piensas en las necesidades de la aplicación cliente.
Comunicación directa cliente-microservicios
Entonces, si piensas en una arquitectura de microservicios, habrá numerosos clientes que hablarán a nuestros servicios. Y si no hay nada frente a estos servicios, cada cliente puede hablar con ellos de forma independiente. Estos clientes pueden ser clientes móviles, computadoras portátiles, computadoras de escritorio, etc. Incluso, un cliente puede ser otro microservicio. Veamos brevemente la complejidad de la arquitectura de Uber.
Como podemos ver, estamos viendo la arquitectura de «estrella muerta» de alta complejidad. La forma directa de comunicación con el servicio al cliente es casi imposible. E incluso si pensamos más, cada microservicio puede ejecutar múltiples nodos y esos nodos pueden cambiar en cualquier momento. Para ver esto mejor, veamos la siguiente figura que muestra la forma de comunicación directa client-service.
Es realmente un caos porque obligará a cada cliente a saber dónde está ese microservicio o qué nodo de eso está disponible. O incluso, ¿cómo mantiene un solo nodo de sobrecarga?
API Gateway intervención
Para resolver y simplificar los problemas de comunicación directa, es donde interviene el Patrón API Gateway. Básicamente es como si pusieras un policía que está a cargo de regular el tráfico en la encrucijada. Y ahora cada cliente y cada servicio deberían pasar por esa API Gateway. Realmente simplifica las cosas porque aísla completamente la implementación de los microservicios. Al cliente no le importa cómo se implementaron estos microservicios y sus nodos. Solo quiere un end-point para consumir. No le importa cuántos nodos haya implementado o cómo va el tráfico. Solo quiere enviar una solicitud y obtener una respuesta.
API Gateway ejemplo con balanceadores de carga (load balancers)
Lo que verá principalmente es el balanceador de carga detrás de la puerta de enlace API. Entonces la puerta de enlace va a hablar con un punto final del balanceador de carga que tiene la responsabilidad de distribuirlo. Cuando tenemos una gran API de monolitos, siempre podemos trabajar en el rendimiento y mejorarlo. Pero hay un límite y en algún momento está siendo afectado. Usando arquitectura de microservicios y el patrón de puerta de enlace API con equilibradores de carga aumenta la escalabilidad a un nivel superior. Vamos a ver un ejemplo visual de incluir varios equilibradores de carga para cada servicio y sus nodos.
Echemos un vistazo a una lista de las responsabilidades de Gateway y las características transversales.
- Routing / Dynamic Routing
- Caching
- Rate limiting
- Security
- Blue-Green deployments
- Monolith strangling
- Monitoring / Logging
- IP whitelisting / blacklisting
Sin embargo, estas son solo algunas de las responsabilidades de API Gateway pattern. Dependen en gran medida de los requisitos comerciales del proyecto y de la corporación a la que se está implementando. Pueden ser muy personalizados.
Implemente el API Gateway pattern para evitar problemas en los siguientes aspectos
- Problemas de seguridad – sin una puerta de enlace, todos los microservicios deben estar expuestos al «mundo externo». Cuanto más pequeña sea la superficie de ataque, más segura será sea tu aplicación.
- Cross-cutting concerns – cada microservicio publicado públicamente debe abordar inquietudes como la autorización, SSL, etc. En muchas situaciones, esas preocupaciones podrían manejarse en un solo nivel para que los microservicios internos se simplifiquen.
- Demasiados viajes de ida y vuelta – una sola página / pantalla en la aplicación cliente puede requerir varias llamadas a múltiples servicios. Eso puede resultar en múltiples viajes de ida y vuelta de red entre el cliente y el servidor, lo que agrega una latencia significativa. La agregación manejada en un nivel intermedio podría mejorar el rendimiento y la experiencia del usuario para la aplicación cliente.
- Coupling – sin el API Gateway pattern, las aplicaciones del cliente están acopladas a los microservicios internos. Las aplicaciones cliente necesitan saber cómo se descomponen las múltiples áreas de la aplicación en microservicios. Al evolucionar y refactorizando los microservicios internos, esas acciones impactan bastante en el mantenimiento porque causan cambios importantes a las aplicaciones cliente debido a la referencia directa a los microservicios internos de las aplicaciones cliente. Las aplicaciones cliente se deben actualizar, lo que dificulta la evolución de la solución.
Gracias por el aporte. Muy bien explicado!