Introducción a microservicios

Introducción a microservicios con Spring Cloud

Los microservicios representan un enfoque arquitectónico donde las aplicaciones se dividen en servicios pequeños, independientes y especializados que se comunican a través de la red. Esta aproximación contrasta con las aplicaciones monolíticas tradicionales, donde toda la funcionalidad reside en una sola unidad desplegable.

Spring Cloud surge como la respuesta natural para desarrolladores que ya dominan Spring Boot y necesitan construir arquitecturas distribuidas. Mientras que Spring Boot simplifica la creación de aplicaciones independientes, Spring Cloud amplía estas capacidades proporcionando las herramientas necesarias para gestionar la complejidad inherente de los sistemas distribuidos.

¿Qué es Spring Cloud?

Spring Cloud es un conjunto de frameworks y librerías que extiende Spring Boot para abordar los desafíos comunes en arquitecturas de microservicios. No es una tecnología única, sino un ecosistema integrado que proporciona soluciones para problemas recurrentes como la configuración distribuida, el descubrimiento de servicios, el enrutado y la tolerancia a fallos.

La filosofía de Spring Cloud se basa en patrones probados de la industria, empaquetados de manera que resulten familiares para desarrolladores de Spring Boot. Cada componente se diseña para integrarse de forma transparente con el resto del ecosistema, manteniendo la simplicidad característica de Spring.

Componentes principales del ecosistema

Spring Cloud organiza sus funcionalidades en módulos especializados, cada uno resolviendo aspectos específicos de las arquitecturas distribuidas:

• Spring Cloud Config centraliza la gestión de configuración, permitiendo que múltiples servicios obtengan su configuración desde un servidor centralizado. Esto elimina la necesidad de modificar y redesplegar servicios cuando cambian parámetros de configuración.
• Spring Cloud Netflix Eureka proporciona service discovery, permitiendo que los servicios se registren automáticamente y se descubran entre sí sin conocer ubicaciones físicas específicas.
• Spring Cloud Gateway actúa como punto de entrada único para todas las peticiones externas, manejando el enrutado, la autenticación y otras preocupaciones transversales antes de dirigir las solicitudes a los microservicios correspondientes.
• Spring Cloud OpenFeign simplifica la comunicación entre servicios mediante interfaces declarativas, eliminando el código repetitivo necesario para realizar llamadas HTTP entre microservicios.
• Spring Cloud LoadBalancer distribuye automáticamente las peticiones entre múltiples instancias de un servicio, mejorando la disponibilidad y rendimiento del sistema.
• Spring Cloud Stream facilita la comunicación asíncrona entre servicios mediante mensajería, desacoplando los productores de los consumidores de eventos.

Evolución desde Spring Boot tradicional

La transición de aplicaciones Spring Boot monolíticas a microservicios con Spring Cloud representa una evolución natural. Los conceptos fundamentales de Spring Boot se mantienen: autoconfiguración, starters, actuator y convenciones sobre configuración.

Sin embargo, Spring Cloud introduce nuevas consideraciones. Donde antes teníamos una base de datos compartida, ahora cada microservicio gestiona su propio almacén de datos. Donde antes las llamadas eran invocaciones locales, ahora son peticiones de red que pueden fallar.

// Antes: invocación local
@Service
public class OrderService {
    @Autowired
    private PaymentService paymentService;
    
    public Order processOrder(Order order) {
        // Llamada local, siempre disponible
        Payment payment = paymentService.processPayment(order.getAmount());
        return completeOrder(order, payment);
    }
}

// Después: comunicación distribuida
@Service
public class OrderService {
    @FeignClient("payment-service")
    private PaymentClient paymentClient;
    
    public Order processOrder(Order order) {
        // Llamada de red, puede fallar
        Payment payment = paymentClient.processPayment(order.getAmount());
        return completeOrder(order, payment);
    }
}

Beneficios de adoptar Spring Cloud

La adopción de Spring Cloud aporta ventajas significativas para equipos familiarizados con Spring Boot. La curva de aprendizaje se minimiza porque los patrones y anotaciones resultan familiares, mientras que la integración automática entre componentes reduce la configuración manual.

Los equipos pueden escalar independientemente diferentes partes de la aplicación según las necesidades del negocio. Un servicio de procesamiento de pagos puede ejecutarse en infraestructura más robusta que un servicio de notificaciones, optimizando costes y rendimiento.

La resiliencia mejora considerablemente. Si un microservicio falla, el resto del sistema puede continuar funcionando, posiblemente con funcionalidad degradada pero sin colapso completo.

Consideraciones importantes

Spring Cloud no convierte automáticamente una aplicación en un sistema distribuido exitoso. Requiere cambios de mentalidad en aspectos como el manejo de errores, la consistencia de datos y el monitoreo.

La complejidad operacional aumenta: donde antes desplegabas una aplicación, ahora gestionas múltiples servicios con sus propias configuraciones, logs y métricas. Spring Cloud proporciona herramientas para abordar esta complejidad, pero no la elimina.

Es fundamental entender que cada llamada de red introduce latencia y posibles fallos. Spring Cloud incluye patrones como circuit breakers y retry logic, pero su correcta implementación requiere comprensión de estos conceptos.

En las siguientes lecciones exploraremos cada componente en detalle, construyendo progresivamente una arquitectura de microservicios completa y funcional.

Arquitectura monolítica vs microservicios

Las diferencias arquitectónicas entre monolitos y microservicios van más allá de la simple distribución del código. Representan filosofías fundamentalmente distintas sobre cómo organizar, desarrollar y mantener sistemas de software empresarial.

Características de la arquitectura monolítica

Una aplicación monolítica Spring Boot se construye como una unidad cohesiva donde todos los componentes del sistema residen en el mismo proceso y comparten recursos comunes. Esta aproximación presenta características bien definidas que han sido la norma durante décadas.

El despliegue unificado constituye la característica más visible de un monolito. Toda la funcionalidad se empaqueta en un único archivo JAR o WAR que contiene desde los controladores web hasta la lógica de negocio y los repositorios de datos. Cuando necesitas actualizar cualquier parte del sistema, debes redesplegar la aplicación completa.

// Estructura típica de un monolito Spring Boot
@SpringBootApplication
public class EcommerceApplication {
    public static void main(String[] args) {
        SpringApplication.run(EcommerceApplication.class, args);
    }
}

// Todos los servicios en el mismo contexto
@Service
public class OrderService {
    @Autowired
    private PaymentService paymentService;
    
    @Autowired
    private InventoryService inventoryService;
    
    // Comunicación directa entre componentes
}

La gestión de datos centralizada es otra característica definitoria. Típicamente, una aplicación monolítica utiliza una única base de datos compartida donde todas las entidades coexisten en el mismo esquema. Esta aproximación simplifica las transacciones y garantiza la consistencia ACID automáticamente.

Los recursos compartidos incluyen no solo la base de datos, sino también la memoria, los pools de conexiones, las caches y la configuración. Todos los módulos acceden a los mismos recursos del sistema operativo y JVM, lo que permite una comunicación extremadamente eficiente entre componentes.

Características de la arquitectura de microservicios

Los microservicios representan el polo opuesto arquitectónico, donde cada servicio es una aplicación Spring Boot independiente con su propio ciclo de vida, datos y responsabilidades específicas.

La independencia de despliegue permite que cada servicio se actualice sin afectar a otros. Un cambio en el servicio de pagos no requiere redesplegar el servicio de inventario, lo que acelera considerablemente los ciclos de desarrollo y reduce el riesgo de introducir errores en funcionalidades no relacionadas.

// Servicio de pagos independiente
@SpringBootApplication
public class PaymentServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(PaymentServiceApplication.class, args);
    }
}

// Servicio de pedidos independiente
@SpringBootApplication  
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

La descentralización de datos es fundamental en microservicios. Cada servicio gestiona su propio almacén de datos, optimizado para sus necesidades específicas. El servicio de catálogo puede usar MongoDB para documentos de productos, mientras que el servicio financiero utiliza PostgreSQL para transacciones que requieren ACID.

Comunicación y acoplamiento

La comunicación interna revela diferencias cruciales entre ambas arquitecturas. En un monolito, los componentes se comunican mediante invocaciones de métodos directas en memoria, con latencia mínima y garantías de disponibilidad.

// Monolito: comunicación en memoria
@Service
public class OrderService {
    @Autowired
    private PaymentService paymentService; // Inyección directa
    
    public Order createOrder(OrderRequest request) {
        // Llamada local, sin latencia de red
        Payment payment = paymentService.processPayment(request.getAmount());
        return buildOrder(request, payment);
    }
}

Los microservicios requieren comunicación a través de la red, típicamente mediante APIs REST o mensajería asíncrona. Esta comunicación introduce latencia, posibles fallos y la necesidad de manejar estados parciales del sistema.

// Microservicio: comunicación por red
@Service
public class OrderService {
    @Autowired
    private PaymentServiceClient paymentClient; // Cliente HTTP
    
    public Order createOrder(OrderRequest request) {
        try {
            // Llamada de red, puede fallar
            Payment payment = paymentClient.processPayment(request.getAmount());
            return buildOrder(request, payment);
        } catch (FeignException e) {
            // Manejar fallos de red
            throw new PaymentServiceUnavailableException();
        }
    }
}

Escalabilidad y gestión de recursos

El escalado presenta comportamientos radicalmente diferentes. Un monolito escala verticalmente añadiendo más recursos (CPU, RAM) a la instancia, u horizontalmente duplicando la aplicación completa. Si solo el módulo de pagos necesita más capacidad, debes escalar todo el sistema.

Los microservicios permiten escalado granular. Puedes ejecutar múltiples instancias del servicio de pagos durante Black Friday mientras mantienes una sola instancia del servicio de informes, optimizando costes y recursos.

Complejidad operacional

La complejidad de desarrollo inicial favorece claramente a los monolitos. Con un único proyecto, una base de datos y un proceso de despliegue, los equipos pueden centrarse en la lógica de negocio sin preocuparse por la infraestructura distribuida.

Los microservicios introducen complejidad operacional desde el primer día. Necesitas gestionar múltiples proyectos, bases de datos, procesos de CI/CD, monitorización distribuida y orquestación de servicios. Sin embargo, esta complejidad inicial puede resultar en mayor agilidad a largo plazo.

Consideraciones sobre la consistencia

La consistencia de datos en monolitos se garantiza mediante transacciones ACID tradicionales. Puedes actualizar múltiples tablas en una sola transacción con garantías de atomicidad.

Los microservicios enfrentan el reto de la consistencia eventual. Las transacciones distribuidas son complejas y costosas, por lo que frecuentemente se opta por patrones como Saga o Event Sourcing para mantener coherencia entre servicios.

Cuándo elegir cada aproximación

Los monolitos son ideales para equipos pequeños, proyectos con requisitos estables, aplicaciones con alta cohesión funcional y cuando la simplicidad operacional es prioritaria. Si puedes gestionar tu aplicación con un equipo pequeño y los requisitos de escalabilidad son moderados, un monolito bien diseñado puede ser más efectivo.

Los microservicios brillan en organizaciones grandes con equipos autónomos, aplicaciones con dominios claramente separados, requisitos de escalabilidad heterogéneos y cuando la tolerancia a fallos es crítica. Si diferentes partes de tu aplicación tienen ciclos de vida, tecnologías o equipos distintos, los microservicios pueden proporcionar la flexibilidad necesaria.

La decisión no es binaria. Muchas organizaciones comienzan con un monolito bien estructurado y evolucionan hacia microservicios cuando la complejidad del dominio y del equipo lo justifica. Spring Cloud facilita esta transición proporcionando herramientas que funcionan tanto en arquitecturas híbridas como completamente distribuidas.

Starters de Spring Cloud

A la hora de crear un proyecto con Spring Cloud, ya sea desde start.spring.io o desde el propio IntelliJ IDEA Ultimate, podemos ver que la lista de starters es extensa y proporcionan diferentes capabilities:

La clave no está en seleccionar todo, si no en utilizar lo realmente necesario y poco a poco ir escalando según las necesidades.

Habitualmente un setup mínimo de microservicios suele incluir varias aplicaciones Spring Boot con starters de Spring Cloud:

• Una aplicación spring boot que actúe de Config Server
• Una aplicación spring boot que actúe de Eureka Server
• Una aplicación spring boot que actúe de Gateway
• Aplicaciones spring boot con la lógica de negocio, actuando como Eureka Discovery Clients, Config Clients y con clientes OpenFeign o WebClient.

A partir de ese setup mínimo se pueden agregar otros starters como Resilience4j y Cloud Stream.