Comprensión del patrón API Gateway en microservicios: una guía sencilla

La transición de una aplicación única y monolítica a una arquitectura de microservicios resuelve muchos problemas. Permite a los equipos trabajar de forma independiente, implementar servicios por separado y escalar partes del sistema según sea necesario. Sin embargo, también introduce un nuevo desafío: ¿cómo interactúan los clientes con todos estos servicios independientes?

Si tiene diez, cincuenta o cientos de pequeños microservicios, ¿debería conectarse una aplicación móvil o una página web a cada uno de ellos directamente?

Aquí es donde entra en juego el Patrón de puerta de enlace API. En esta guía, desglosaremos qué es una puerta de enlace API, por qué la necesita y cómo simplifica su sistema de microservicios utilizando palabras simples y analogías del mundo real.

La analogía del mundo real: la recepcionista del hotel

Imagine que se está registrando en un gran hotel resort de lujo. El resort cuenta con muchos departamentos diferentes:

• Servicio de limpieza (para sábanas limpias)
• Room Service (para comida)
• Conserje (para reservar tours)
• Facturación (para pagar la factura)

Si desea una toalla limpia, no camine por el complejo tratando de encontrar el edificio de limpieza. Si quieres cenar, no llamas a la puerta de la cocina. En su lugar, llama a la recepcionista de la recepción.

La recepcionista escucha tu solicitud, determina qué departamento puede resolverla y te conecta o gestiona el asunto por ti.

En este escenario:

• Tú eres el Cliente (Aplicación Móvil o Navegador).
• La recepcionista es la API Gateway.
• Los departamentos (Housekeeping, Room Service, Facturación) son los Microservicios.

El problema: comunicación directa cliente-servicio

Antes de ver cómo funciona la puerta de enlace, veamos qué sucede si no usamos una.

Supongamos que su aplicación de comercio electrónico tiene tres microservicios separados:

1. Servicio de Usuario (administra perfiles)
2. Servicio de Producto (gestiona el catálogo)
3. Servicio de pedidos (gestiona el pago)

Sin una API Gateway, la aplicación cliente tiene que enviar solicitudes separadas directamente a la dirección individual de cada servicio (IP o URL):

Este enfoque de conexión directa genera varios dolores de cabeza importantes:

• Demasiados puntos finales: la aplicación cliente debe recordar tres URL independientes. Si divide un servicio o cambia su dirección, debe actualizar la aplicación cliente.
• Pesadilla de seguridad: cada microservicio debe implementar por separado la autenticación (verificación de tokens de inicio de sesión), certificados SSL y reglas de firewall.
• Sobrecarga de red: Es posible que el cliente necesite realizar tres solicitudes de red independientes a través de redes móviles lentas solo para cargar una sola página (por ejemplo, obtener perfil, obtener detalles del producto y obtener historial de pedidos).
• Diferencias de protocolo: Es posible que su aplicación cliente prefiera utilizar protocolos web estándar como HTTP/JSON, pero sus servicios internos pueden comunicarse más rápido utilizando protocolos especializados como gRPC o AMQP.

La solución: el patrón API Gateway

Una API Gateway es un servidor auxiliar que se encuentra entre las aplicaciones cliente y los microservicios internos. Actúa como el único punto de entrada para todas las solicitudes entrantes.

En lugar de llamar a tres servicios diferentes, el cliente realiza una llamada a API Gateway. Luego, la puerta de enlace reenvía la solicitud al servicio interno correcto, recopila los resultados y los envía de vuelta al cliente.

Responsabilidades clave de una puerta de enlace API

Una API Gateway hace mucho más que dirigir el tráfico. Se ocupa de las “preocupaciones transversales”, tareas para las que, de otro modo, cada microservicio tendría que escribir código:

1. Enrutamiento: la puerta de enlace toma una URL entrante (como /api/v1/orders) y la asigna a la dirección de servicio interna correcta.
2. Autenticación y autorización: la puerta de enlace valida tokens de seguridad (como JWT) en la puerta de entrada. Si la solicitud no es válida, se rechaza inmediatamente, lo que evita que sus microservicios desperdicien ciclos de CPU en solicitudes no autenticadas.
3. Limitación de velocidad: evita que bots maliciosos o clientes con errores envíen spam a su sistema al limitar la cantidad de solicitudes que un usuario puede realizar por minuto.
4. Equilibrio de carga: la puerta de enlace puede distribuir el tráfico entrante de manera uniforme entre varias instancias de un microservicio para evitar que un solo servidor se sobrecargue.
5. Traducción de protocolo: puede traducir solicitudes JSON del usuario en mensajes gRPC internos de alto rendimiento, lo que permite que los servicios se comuniquen entre sí en sus idiomas preferidos.

Una implementación simple: ejemplo de código

Para ver lo fácil que resulta el enrutamiento, veamos dos formas comunes de configurar una API Gateway.

1. Enrutamiento declarativo (Spring Cloud Gateway YAML)

En los sistemas Java empresariales, a menudo se configura el enrutamiento mediante un archivo de configuración simple. La puerta de enlace reenvía automáticamente solicitudes según estas reglas:

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. Enrutamiento programático (maqueta de puerta de enlace Node.js)

Si desea crear una puerta de enlace API liviana en Javascript usando Express, se ve así:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

Pros y contras del patrón API Gateway

Como cualquier decisión arquitectónica, el uso de API Gateway tiene sus ventajas y desventajas:

Conclusión

El patrón API Gateway es la piedra angular de la arquitectura de microservicios moderna. Al actuar como un punto de entrada único e inteligente, protege las aplicaciones cliente de la complejidad de las configuraciones de servicios internos. Simplifica el código del lado del cliente, centraliza la seguridad y maneja la gestión del tráfico de manera eficiente.

Si bien introduce un salto de red menor y debe configurarse con alta disponibilidad en producción, los beneficios de bases de código más limpias, seguras y manejables lo convierten en un patrón altamente recomendado para cualquier sistema distribuido en crecimiento.

Explore más conocimientos sobre desarrollo de software e ingeniería backend en el Blog de Ghaznix →